100% found this document useful (1 vote)
2K views

Inmarsat C System Definition Manual - CD004 PDF

Uploaded by

borisgolodenko
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
100% found this document useful (1 vote)
2K views

Inmarsat C System Definition Manual - CD004 PDF

Uploaded by

borisgolodenko
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1644

Inmarsat Confidential C SDM

(Version Release CD004)

Inmarsat C System Definition Manual

Front Page

This document contains information that is confidential, proprietary and of significant


commercial value to Inmarsat Limited. This document has been issued pursuant to a
written Licence Agreement or Confidentiality Agreement (the “Governing Agreement”)
and all access to and (where permitted) use of the information contained herein is governed
strictly by the terms of same. All persons purporting to access or use the information must
be familiar with, and have agreed to, the terms of the Governing Agreement.

The contents of this SDM are as follows:

Volume 1: System Description

Volume 2: User Services

Volume 3: Earth Station Requirements

Volume 4: Packet Formats and Usage

Volume 5: System Definition Logic (SDL)

Additional Material: Recommended Test Procedures (RTPs)

© Inmarsat Limited 2004. All rights reserved. INMARSAT is a trade mark of the
International Mobile Satellite Organization. The Inmarsat LOGO is a trade mark of
Inmarsat (IP) Company Limited. Both trade marks are licensed to Inmarsat Limited.

Inmarsat C SDM, Front Page: Page 1


Inmarsat Confidential C SDM
(Version Release CD004)

Please be aware that the Inmarsat C SDM - Version Release CD004 is subject to a Change
Proposal / Change Notice procedure administered by Inmarsat Limited.

Enquiries relating to the System Definition Manual should be addressed to:

Hilary David
Design Authority
Product Management & Marketing

Inmarsat Limited
99 City Road
London, EC1Y1AX
United Kingdom

Phone No: +44 207 728 1463


Fax No: +44 207 728 1614
E-mail: [email protected]

Inmarsat C SDM, Front Page: Page 2


Inmarsat Confidential C SDM
(Version Release CD004)

Patents contained within this SDM are as follows:

Inmarsat IPR - Patents

The following technologies are the subject of patents (or applications therefore) owned by Inmarsat and you
have the right to use each of them for Inmarsat Purposes pursuant to the terms of the Licence:

1042870 (European Patent Office) Turbo Coding Delay Reduction (Granted)

97182509.2 (China, Peoples Republic of) Turbo Coding Delay Reduction (Pending)

2000-527033 (Japan) Turbo Coding Delay Reduction (Pending)

PCT / GB97 / 03551 (India) Turbo Coding Delay Reduction (Pending)

09 / 582164 (United States of America) Turbo Coding Delay Reduction (Pending)

2315795 (Canada) Turbo Coding Delay Reduction (Pending)

PCT / GB97 / 03551 (W.I.P.O) Turbo Coding Delay Reduction (Pending)

2335828 (United Kingdom) M4 Frame Format (Pending)

09 / 262064 (United States of America) M4 Frame Format (Pending)

9902637 (France) M4 Frame Format (Pending)

2263280 (Canada) M4 Frame Format (Pending)

19909576.0 (Germany) M4 Frame Format (Pending)

11-57383 (Japan) M4 Frame Format (Pending)

9822145.0 (United Kingdom) MAC Layer (Pending)

99307960.7 (European Patent Office) MAC Layer (Pending)

11-325921 (Japan) MAC Layer (Pending)

09 / 414948 (United States of America) MAC Layer - Divisional (Pending)

09 / 590588 (United States of America) MAC Layer - Divisional (Pending)

53554 / 99 (Australia) MAC Layer (Pending)

2285168 (Canada) MAC Layer (Pending)

981 / MAS / 99 (India) MAC Layer (Pending)

99125027.3 (China, Peoples Republic of) MAC Layer (Pending)

9905071-8 (Singapore) MAC Layer - Divisional (Pending)

Inmarsat C SDM, Front Page: Page 3


Inmarsat Confidential C SDM
(Version Release CD004)

200105447-7 (Singapore) MAC Layer - Divisional (Pending)

9905183.1 (United Kingdom) MAC Layer / MES Specific Sig. (Granted)

9905181.5 (United Kingdom) IPDS Resource Management (Pending)

99309029.9 (European Patent Office) IPDS Resource Management (Pending)

59431 / 99 (Australia) IPDS Resource Management (Pending)

1105 / MAS / 99 (India) IPDS Resource Management (Pending)

19995547 (Norway) IPDS Resource Management (Pending)

09 / 440468 (United States of America) IPDS Resource Management (Pending)

2289835 (Canada) IPDS Resource Management (Pending)

11-324239 (Japan) IPDS Resource Management (Pending)

9905182.3 (United Kingdom) IPDS Timing Correction (Pending)

99309030.7 (European Patent Office) IPDS Timing Correction (Pending)

09 / 439348 (United States of America) IPDS Timing Correction (Pending)

19995660 (Norway) IPDS Timing Correction (Pending)

2289838 (Canada) IPDS Timing Correction (Pending)

11-331545 (Japan) IPDS Timing Correction (Pending)

59430 / 99 (Japan) IPDS Timing Correction (Pending)

1104 / MAS / 99 (India) IPDS Timing Correction (Pending)

Controlled Third Party IPR - Patents

Some technologies set out in this SDM are the subject of patents (or applications therefore) owned by third
parties but in respect of which Inmarsat has a licence to use and to grant sub-licenses to others to use for
Inmarsat Purposes. It is necessary for you to apply directly to Inmarsat for a sub-licence should you wish to
use any of the following technologies:

Not Applicable

Inmarsat C SDM, Front Page: Page 4


Inmarsat Confidential C SDM
(Version Release CD004)

Uncontrolled Third Party Patents

Some technologies set out in this SDM are the subject of patents (or applications therefore) owned by third
parties and in respect of which Inmarsat has no right to grant sub-licenses to others to use. In all such cases,
the patent holders will grant a non-exclusive licence on either a royalty-free or royalty-bearing basis to such
other parties for use in relation to the Inmarsat system. It is necessary for you to apply directly to the following
patent holders for a licence in the event you wish to use any of the following technologies:

Not Applicable

Inmarsat C SDM, Front Page: Page 5


Inmarsat Confidential C SDM
(Version Release - CD004)

Inmarsat C SDM
Version Release Control Sheet

Date Issued:
Version Release Control Sheet: Version Release - CD004
Friday, 12 November 2004

Version Change
Description Status
Release Notice

Accepted up to and
including August 1997.
CD001 Up to and including CN126 Replacement pages
circulated in September
1997.

CN127 Enhanced Registration ISL Packet Format

CN128 Year 2000 Date Changes

CN130 Manufacturer EGC Closed Network Identity Accepted up to and


CD002 including August 1999.
CN131 Registration Update Request Replacement pages
circulated in May 2000.
CN132 Base Oriented and Mobile to Mobile Data Report

CN133 Automatic Pre-setting of LES ID for the Distress Alert

CN134 Low Transmit Power Inmarsat-C Land Mobile Terminals

Low Transmit Power Inmarsat-C Maritime Mobile Accepted up to and


CN135
Terminals including March 2001.
CD003 Version release CD003
circulated on the 15th
CN136 Low Power C SES with Emergency Calling Facility
March 2002.

CN137 Inmarsat C Covert / Security Alert

SDM Clarification on Non SOLAS with Distress Mobile


CN138
Earth Station and X.400 Changes Accepted up to and
including November
CN139 “From Mobile Message” Clear Packet Extension 2004. Version release
CD004 CD004 released and
Clarification of Distress Alerting & Covert / Security uploaded onto the
CN140
Alerting Connect website on the
12th November 2004.
CN141 Enhanced Data Reporting

CN142 Multi-Ocean Region Polling

Inmarsat C Version Release Control Sheet: Version Release - CD004 Page 1


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 1: Introduction

Contents

1 The Inmarsat-C Communications System ................................. 3


1.1 Services provided by the Inmarsat-C Network ..................................................3
1.2 User Services ....................................................................................................3

2 The Inmarsat-C System Definition Documentation .................... 4

3 System Overview ..................................................................... 4


Figure 1: Inmarsat-C Network Schematic ...............................................................5
3.1 Space Segment ................................................................................................5
3.2 Network Coordination Station ...........................................................................5
3.3 Land Earth Station ............................................................................................6
3.4 Mobile Earth Station ..........................................................................................6

4 Inmarsat-C Communication Channels ...................................... 6


4.1 Interstation Signalling Links ..............................................................................6
Figure 2: Interstation Signalling Links ....................................................................7
4.2 NCS Common Channel.....................................................................................7
4.3 TDM Channel ....................................................................................................7
4.4 Message Channel .............................................................................................7
4.5 Signalling Channel ............................................................................................7
4.6 LES Channel Management ...............................................................................8

5 Inmarsat-C Services ................................................................ 8


5.1 Store and Forward Data and Messaging...........................................................8
5.2 Distress Calls ....................................................................................................8
5.3 Enhanced Group Calls (EGC) ...........................................................................8
5.4 Data Reporting ..................................................................................................9
5.5 Polling ...............................................................................................................9
5.5.1 Individual Polling .......................................................................................... 10

Volume 1: System Description, Chapter 1: Introduction Page: 1


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

5.5.2 Group Polling ............................................................................................... 10


5.5.3 Area Polling.................................................................................................. 10

6 Time Reference ..................................................................... 10

Volume 1: System Description, Chapter 1: Introduction Page: 2


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 The Inmarsat-C Communications System


Inmarsat-C is a satellite communications system which facilitates data transfer between mobile earth
stations (MESs) and fixed Land Earth Stations (LESs) which are connected to terrestrial networks.
Data can also be transferred from mobile to mobile via an LES. Mobile stations can be located on
ships or on land based stations which can be mounted on vehicles or can be transportable.

1.1 Services provided by the Inmarsat-C Network


The system provides:

- store and forward communication in both directions

- distress calling (i.e distress alerts and distress priority messages) From-Mobile

- enhanced group calls To-Mobile, including SafetyNETSM

- data reporting From-Mobile

- polling To-Mobile

Some of the services supported by the Inmarsat-C system are mandatory; other services are optional
as indicated in the following table.

Service LES SES SES SES (non- SES (non- MES


(SOLAS (SOLAS SOLAS SOLAS (land-
with without with without based)
distress) distress) distress) distress)
S&F Mandatory Mandatory Mandatory Mandatory Mandatory Mandatory
Messaging

Distress Mandatory Mandatory N/A Mandatory N/A Not allowed


alerting

Land Optional N/A N/A N/A N/A Optional


Mobile
alerting

Data Optional Optional Optional Optional Optional Optional


reporting

Polling Optional Optional Optional Optional Optional Optional

EGC Mandatory Mandatory Optional Optional Optional Optional

For Store and forward messaging, the mandatory end to end service supported by all elements of the
network is Telex.

EGC (SafetyNET) capability is mandatory in maritime installations intended for use in the GMDSS
either included in the MES or as a stand-alone EGC receiver.

1.2 User Services


The Inmarsat-C communications system can be used for a variety of applications. To ensure
compatibility, Inmarsat defines requirements for the implementation of some of these services (see
Volume 2: User Services).

Volume 1: System Description, Chapter 1: Introduction Page: 3


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2 The Inmarsat-C System Definition Documentation


This volume defines the general requirements of the system. An overview of the system is given in
this chapter, with a more comprehensive technical description in Chapter 2. The system
characteristics are detailed in Chapter 3 while Chapters 4, 5, 6 and 7 introduce protocols used within
the Inmarsat-C network.

More detailed information about the requirements for the component parts of the system can be found
in the associated volumes:

Volume 1 System description

Volume 2 User services

Volume 3 Earth station requirements

Volume 4 Packet formats and usage

Volume 5 Inmarsat-C SDL

A glossary and list of abbreviations used in all the documents are given in Chapter 9 of this volume.

The equipment used in the system, particularly mobile earth stations, is provided by a variety of
manufacturers. Inmarsat requires that a common standard is strictly adhered to in order to ensure that
all such equipment is fully compatible. The documentation sets out to define the performance targets
which must be achieved, and the limits within which equipment must operate, to maintain the required
level of service.

3 System Overview
The Inmarsat-C system consists of the following major elements in an ocean region:

a. the space segment (including the Network Operations Centre);

b. the Network Coordination Station (NCS);

c. Land Earth Stations (LES); and

d. maritime mobiles, referred to as Ship Earth Stations (SES), and land-based Mobile Earth
Stations (MES).

Figure 1 (on the following page) shows these elements and the required data links.

Volume 1: System Description, Chapter 1: Introduction Page: 4


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: Inmarsat-C Network Schematic

NCS/NCS SIGNALLING LINK


NCS

NCS COMMON CHANNEL


INTERSTATION SIGNALLING LINKS

SIGNALLING
CHANNEL

SIGNALLING CHANNEL DTE

TELEX
NETWORK LES MESSAGE CHANNEL MES
(DCE)
DATA TDM CHANNEL
NETWORKS EGC

TERRESTRIAL NETWORKS

3.1 Space Segment


The space segment, which includes the satellites and their associated ground support facilities, is the
responsibility of Inmarsat. It utilises a number of satellites to provide almost complete global coverage
with the exception of the polar regions, which cannot be seen by geostationary satellites.

There are four ocean regions:

- Atlantic Ocean Region (West)

- Atlantic Ocean Region (East)

- Indian Ocean Region

- Pacific Ocean Region

Satellite utilisation is co-ordinated by the Inmarsat Network Operation Centre in London.

3.2 Network Coordination Station


Each ocean region is served by a Network Coordination Station which manages the allocation of
central resources such as traffic and signalling channels.

The NCS controls the access rights of mobile earth stations. Every MES that is active in an ocean
region is required to log in to the Network: a copy of the list of all registered MESs is held at each
LES. When an LES receives a call for an MES from a terrestrial subscriber, it checks that the MES is
present in its ocean region before forwarding it. The location of each MES is monitored so that if a call
is received for an MES which has moved on to another ocean region, the call can be redirected or
rejected.

The NCS transmits a common channel which is used to announce calls (addressed to mobile
stations) which are waiting at LESs, for broadcasting EGC messages, and at various stages for

Volume 1: System Description, Chapter 1: Introduction Page: 5


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

protocol signalling and other optional services. When an MES is not involved in message transfer it
automatically tunes to the NCS common channel. Associated with each NCS common channel is a
signalling channel on which the NCS receives information from MESs.

All the NCSs are connected to each other and also to the NOC.

3.3 Land Earth Station

Each LES serves as a gateway between the terrestrial networks and the MESs within the coverage
area of the satellite. It is also used for the transfer of calls from one mobile to another. All LESs shall
provide telex, maritime distress alerting, and EGC message handling facilities with appropriate
interfaces to the terrestrial network: other interfaces can be provided at the discretion of the LES
operator.

Each LES in a particular region is connected by an Interstation Signalling Link to that region's NCS.

LESs can operate some or all of their traffic channels in a demand assigned mode. If traffic and
satellite power considerations call for this mode of operation to be used, the NCS allocates temporary
LES TDM channels, signalling channels, and message channels on the basis of need.

3.4 Mobile Earth Station


Each MES consists of a Data Circuit Terminating Equipment (DCE) which acts as an interface to the
satellite network and a Data Terminal Equipment (DTE) such as a personal computer or intelligent
black box. The DTE may provide an interface at which information gathered by, for example, a
monitoring system or a position location device can be transferred to the DCE or it may allow the user
to enter information manually. Similarly, received information is processed by the DTE and can be
displayed or printed. Alternatively the data can be used by, for example, a control system.

In the From Mobile direction, the DTE assembles a complete message and then transfers it to the
DCE. In the receive direction, the DTE receives messages from the DCE.

4 Inmarsat-C Communication Channels


Several different types of channel are used in the Inmarsat-C system as shown in Figure 1. All
information is transferred in packets on the different channels; both fixed and variable length packets
are used. Each packet includes a checksum allowing Automatic Repeat Request (ARQ) error
correction to be implemented.

4.1 Interstation Signalling Links


Each LES communicates with the NCS in its ocean region via an Interstation Signalling Link (ISL).
The ISL is a satellite link which uses the LAP-B protocol for error detection and correction. The link is
used to transfer announcements and other signalling packets from the LES to the NCS
(Announcements are part of the start of a To Mobile call). The ISL also carries EGC messages from
the LES to the NCS for subsequent transmission on the NCS common channel. Network information
such as TDM channel assignments and call information is also transmitted on the ISL.

There are inter-regional signalling links between the NCSs. They allow the NCSs to exchange
information about MESs in their coverage areas.

The NCSs are also linked to the Inmarsat Network Operation Centre (NOC) in London.

Figure 2 (on the following page) shows the Interstation Signalling Links. (For clarity, only three ocean
regions are shown.)

Volume 1: System Description, Chapter 1: Introduction Page: 6


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 2: Interstation Signalling Links

NCS NCS

LES LES LES LES LES LES


NOC

LES-NCS ISL
NCS NCS-NCS ISL
NCS-NOC ISL

LES LES LES

4.2 NCS Common Channel


The NCS common channel is a Time Division Multiplex (TDM) channel with a frame length of 8.64
seconds. The channel carries network information, signalling information and EGC messages. It is
transmitted continuously by the NCS to all MESs in its region. MESs automatically tune to the NCS
common channel when they are idle. An NCS may transmit more than one common channel (for
example, when operating with spot beams).

4.3 TDM Channel


The LES TDM channel has the same frame structure as the NCS common channel. It carries all
signalling and message traffic from the LES to the MESs with which it is communicating; it is the
forward link for LES to MES communication.

4.4 Message Channel


The message channels operate in Time Division Multiple Access (TDMA) mode and are controlled by
the LES. Message channels are used by MESs to transfer messages to an LES. Each LES has one
or more message channels assigned to it by the NCS.

Allocation of a message channel to an MES is performed by the LES using assignment packets. Each
message channel may be used by several MESs simultaneously engaged in From-Mobile calls.

4.5 Signalling Channel


The signalling channels operate in hybrid slotted Aloha mode, where some of the capacity can be
reserved. Signalling channels are used by MESs to transmit signalling packets and short messages to
LESs and NCSs. Each LES has one or more signalling channels assigned to it.

All MESs use a signalling channel to the NCS for logging in and out of the ocean region. Its
characteristics are exactly the same as an LES's signalling channel.

Volume 1: System Description, Chapter 1: Introduction Page: 7


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.6 LES Channel Management


All LES channel assignments are made by the NCS in its region; the assignments can be permanent
or demand assigned.

5 Inmarsat-C Services
The Inmarsat-C system supports a range of services which are described here. All LESs provide store
and forward message transfer to and from the telex network, enhanced group calls, and distress
alerting; other services, however, are provided at the discretion of the LES operator.

5.1 Store and Forward Data and Messaging


The store and forward data and messaging service is a reliable method of sending data or text
messages between an MES and a terrestrial subscriber using the satellite link and a public or private
land network. It can also be used for Inmarsat-C mobile to Inmarsat-C mobile communication within
the Inmarsat-C network.

Messages originating from a Mobile Earth Station (MES) are transmitted in packets, via a satellite, to
a fixed Land Earth Station (LES). At the LES the packets are re-assembled before being sent on to
their destination. The LES transmits the information in the form nominated by the sender (telex, data
or electronic mail, for example). A similar procedure is used for communications being sent in the
opposite direction, with callers being able to call one or a group of MESs.

To protect the integrity of the message each packet is checked for errors. Where possible, errors are
corrected but otherwise a partial acknowledgement is returned, requiring retransmission of the
packets in error. Only messages which have been fully received error free are forwarded; the
originator is informed if the system is unable to deliver a message. This error correction is applied to
communications in both directions.

5.2 Distress Calls


In this SDM, "Distress Calls" is a generic term covering both distress alerts and distress priority
messages.. A distress alert is a data packet carried on a signalling channel. The addressed LES will
immediately confirm to the MES that the alert has been received. If automatic or manual position
updates are given to the MES, this initial distress alert will include its position and an indication that it
has been updated within the last 24 hours.

Distress priority messages are store and forward messages having distress priority and can be sent in
both directions, i.e. To-Mobile and From-Mobile.

These functions may only be implemented in maritime MESs. Land based MESs, are not permitted to
send maritime distress calls although they may, optionally, send land mobile alerts.

5.3 Enhanced Group Calls (EGC)


The Enhanced Group Call (EGC) service is a message broadcast service within the Inmarsat-C
communications system.

EGC messages are sent to LESs using terrestrial facilities such as telex, X.400 electronic mail, and so
on. The messages are processed at the LES and forwarded to the NCS. EGC messages for the entire
ocean region are queued and scheduled at the NCS for transmission on the NCS common channel.

Receiver addressing can be performed on the basis of:

- unique individual ID

Volume 1: System Description, Chapter 1: Introduction Page: 8


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

- group ID

- geographical area (circular or rectangular) defined by co-ordinates (absolute geographical


area address).

- pre-defined geographical area addressing (e.g. NAVAREA).

To receive geographically addressed messages, the MES must store information about its current
position. This can be obtained from a navigation system or can be entered into the terminal manually.

Two of the services provided are:

- FleetNETSM

- SafetyNETSM1

FleetNETSM is used to send commercial messages to individuals or groups of subscribers (for


example, individual companies communicating with their own MESs).

SafetyNETSM is used for broadcasting Maritime Safety Information (MSI) such as navigational
warnings, meteorological warnings, meteorological forecasts and other safety related information
(including Distress Alert Relays) from official sources.

EGC is also used for transmitting Inmarsat system messages.

5.4 Data Reporting


This service allows the MES to send data reports (position data, for example) and short messages. To
obtain position data the MES must be linked to a navigation system of some description (for example,
a terrestrial or ocean based radio navigation system or a conventional dead reckoning system) or co-
ordinates must be entered manually.

Two access methods are available:

- reserved access

- unreserved access

Reserved access is used for pre-assigned data reporting. The LES transfers the required information
to the MES by poll messages which include instructions on the starting time and duration of the
assignment, the type of report that should be transmitted, and the interval between reports. The MES
can, after initialisation, be programmed to make subsequent reports at specified time intervals without
further intervention. Up to four packets can be transmitted via the signalling channel.

For unreserved access, the transmission of the report is initiated by the MES. Only the slot for the first
packet of the sequence is selected randomly; access for subsequent packets uses a reservation
scheme to guarantee access. Up to three packets, containing at most 32 bytes, can be transmitted via
the signalling channel.

For data reporting there is an implied ARQ and acknowledgement. If the LES detects an error in a
slot, the slot state marker in the appropriate signalling channel descriptor packet is set in order to
indicate that no packet was successfully received. If this occurs the MES may retransmit the packet.

5.5 Polling
1 Further information on the International SafetyNET service is given in the "International
SafetyNET Manual", IMO-908, published by the International Maritime Organization.

Volume 1: System Description, Chapter 1: Introduction Page: 9


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Polling is used by the base station to initiate transmission of a data report or message. The poll
command tells the MES how and when to respond and can also include a coded text message or IA5
text of up to 256 characters (maximum packet length is 300 bytes). All polling packets can include
instructions for all the addressed MESs to respond with data reports that acknowledge the poll.

There are three types of polling:

- individual poll

- group poll

- area poll

5.5.1 Individual Polling


Individual polling means that an explicit poll command is sent to MESs on an individual basis.

The poll is originated by a terrestrial subscriber, usually a base station associated with the MESs that
are being polled. Using the terrestrial network, the base station sends the LES a list of the MESs
which are to be polled. An individual poll command is sent to each MES on the list; if the MES is
busy, the poll is queued until the MES is idle. On receipt of a polling command the MES responds in
accordance with the instructions it has been given.

5.5.2 Group Polling


With group polling, a single poll command is broadcast on the NCS common channel. MESs respond
only if they are idle and they receive the poll. The transmission of the poll command may be repeated
in order to obtain responses from MESs that did not respond the first time. (An MES which responded
to the first poll may or may not respond a second time depending on the individual design.)

5.5.3 Area Polling


Area polling is similar to group polling except that only MESs located in a specified geographical area
are addressed. This geographical area is defined by coordinates in the poll message.

6 Time Reference
Unless stated otherwise, all references to time in this manual should be taken to mean Universal
Coordinated Time (UTC) rather than local time.

Volume 1: System Description, Chapter 1: Introduction Page: 10


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 2: System Overview

Contents

1 Introduction ............................................................................ 3

2 Inmarsat Space Segment ......................................................... 3


2.1 Operation with First Generation Spacecraft ......................................................3
Table 1: Inmarsat satellite transponder characteristics (global coverage) ..............4

3 Inmarsat Network Coordination Station ................................... 4

4 Inmarsat Land Earth Station .................................................... 5


Figure 1: Inmarsat-C Land Earth Station Example Block Diagram .........................6

5 Inmarsat-C Mobile Earth Station .............................................. 6


Figure 2: Inmarsat-C Mobile Earth Station Example Block Diagram .......................7
5.1 Mobile Earth Station Supervisory Functions .....................................................7
5.1.1 Commissioning Testing ..................................................................................7

6 Types Of Channels Used In The Inmarsat-C System ................. 8


6.1 NCS Common Channel.....................................................................................8
6.2 LES TDM Channel ............................................................................................9
6.3 Message Channel .............................................................................................9
6.4 Signalling Channel ............................................................................................9
6.5 NCS – NCS Signalling Channel ...................................................................... 10
6.6 NCS – LES Signalling Links ............................................................................ 10
6.7 LES Channel Assignments ............................................................................. 10

7 Interfaces.............................................................................. 10
7.1 Mobile Earth Station Interface ......................................................................... 10
7.2 Land Earth Station Terrestrial Interfaces ........................................................ 10

8 Inmarsat-C Services .............................................................. 10


8.1 Store and Forward Message Transfer ............................................................ 11

Volume 1: System Description, Chapter 2: System Overview Page: 1


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

8.1.1 To Mobile Message Transfer ....................................................................... 11


8.1.2 From Mobile Message Transfer ................................................................... 11
8.1.3 Mobile to Mobile Message Transfer ............................................................. 12
8.2 Distress calls ................................................................................................... 12
8.2.1 Distress Alerting ........................................................................................... 12
8.2.2 Distress Priority Messaging.......................................................................... 13
8.3 Enhanced Group Calls .................................................................................... 13
8.4 Optional Services ............................................................................................ 13
8.4.1 Polling .......................................................................................................... 13
8.4.1.1 Individually Directed ............................................................................................................. 13

8.4.1.2 Group Directed ..................................................................................................................... 14

8.4.1.3 Area Directed ....................................................................................................................... 14

8.4.2 Data Reporting ............................................................................................. 14


8.5 Land Mobile Alerting ....................................................................................... 14

9 Overview Of Call Set Up Procedures ...................................... 14


9.1 MES Originated Calls ...................................................................................... 14
9.2 Terrestrial Originated Calls ............................................................................. 15
Figure 3: From-Mobile Call Procedure .................................................................. 16
Figure 4: To-Mobile Call Procedure ...................................................................... 17

10 LES Channel Management.................................................... 18

11 Spot Beam Operation ........................................................... 18

12 MES Ocean Region Registration .......................................... 18

Volume 1: System Description, Chapter 2: System Overview Page: 2


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
An outline description of the Inmarsat-C communication system can be found in Chapter 1 of this
volume. This chapter expands upon that description, giving more detailed technical information. For
detailed operating parameters of the system refer to Chapter 3.

2 Inmarsat Space Segment


Inmarsat's first generation space segment uses MARECS and INTELSAT-V MCS satellites.

In addition to first generation satellites, Inmarsat has deployed its second generation space segment
since 1990 (Inmarsat-2). Transponder characteristics for MARECS, INTELSAT-V MCS and the
second generation satellites are summarized in Table 1.

Prior to full deployment of operational and spare second generation satellites in all ocean regions, the
Inmarsat-C system will operate with a mix of satellite types and associated transponder
characteristics.

Inmarsat is also planning to launch a series of third generation satellites in the mid 1990s. These
satellites will include a spot beam capability and even greater transponder power and bandwidth.

2.1 Operation with First Generation Spacecraft


The return link budgets are limited by the available MES EIRP in both the first and second generation
satellites. The lower spacecraft transponder gain for first generation satellites means a reduction in
overall C/No of about 3 dB. A halving of all transmission speeds in the MES-to-LES direction will
compensate for this reduction. All formats and coding remain the same.

Volume 1: System Description, Chapter 2: System Overview Page: 3


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Table 1: Inmarsat satellite transponder characteristics (global coverage)

MARECS INTELSAT-V INMARSAT


MCS SECOND
GENERATION

DC Power (end of life) (W) 723 297 1200


Eclipse capability Full Full Full

C-to-L Repeater
Receive band (MHz) 6420–6425 6417.5–6425 6425–6441(1)
Transmit band (MHz) 1537.5–1542.5 1535–1542.5 1530–1546(1)
Receive G/T(2) (dB/K) –15 –12.1 –14
L-band EIRP(2) (dBW) 34.5 33.0 39
C-band antenna
Receive Polarization RHC(3) RHC RHC
L-band antenna
Transmit Polarization RHC RHC RHC
Capacity 60 35 125
(Standard-A voice channels) (80)5 (50)5 (250)5

L-to-C Repeater
Receive band (MHz) 1638.5–1644 1636.5–1644 1626.5–1647.5(1)
Transmit band (MHz) 4194.5–4200 4192.5–4200 3600–3621(1)
Receive G/T (dB/K) –11.2 –13.0 –12.5
C-band EIRP(2) (dBW) 16.5 20.0 24
L-band Antenna
Receive Polarization RHC RHC RHC
C-band Antenna
Transmit Polarization LHC(4) LHC LHC
Capacity 90 120 250
(Standard-A voice channels)

Notes:

(1) Includes 1 MHz at upper end for aeronautical communications

(2) Minimum value at edge of coverage

(3) Right Hand Circular Polarization

(4) Left Hand Circular Polarization

(5) Capacity with voice activated carrier suppression

3 Inmarsat Network Coordination Station


The functions of the Inmarsat-C NCS can be divided into four broad categories:

(a) communications functions;

(b) managing the resources in the system (channels) either automatically or on the basis of
operator intervention

Volume 1: System Description, Chapter 2: System Overview Page: 4


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(c) monitoring and resource management functions; and

(d) collection of call record information.

The communications functions consist of transmitting the NCS common channel, which carries
network information, signalling packets and EGC messages. The NCS receives the signalling channel
which carries signalling packets, distress alerts and, in some circumstances, data reports.

The NCS monitors the functioning of the network as well as controlling the channel allocations and
keeping a database for MES information.

The NCS receives call records from all LESs in its ocean region.

4 Inmarsat Land Earth Station


The primary function of an LES is to route messages between the satellite network and the terrestrial
networks. All LESs provide store and forward telex, distress alerting, distress priority message and
EGC message handling. LESs also serve as routing nodes for mobile-to-mobile calls.

Multiple LES TDM and MES signalling channels can be assigned to each LES. The LES transmits
information in each frame of its TDM channel, which identifies the messaging and signalling channels
that are operating and the particular slots that can be used for request messages.

All LESs can operate in the Demand Assigned mode whereby TDM channels and return channels are
allocated on a need basis by the NCS.

Figure 1 (on the following page) shows a block diagram of a typical Inmarsat-C LES.

Volume 1: System Description, Chapter 2: System Overview Page: 5


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: Inmarsat-C Land Earth Station Example Block Diagram

IF Interface

C band
Message Packets
Channel Processing

ACCESS CONTROL AND SIGNALLING SUB-SYSTEM


Control

C band Signalling Packets + slot status


Channel Processing Control

MESSAGE HANDLING SUB-SYSTEM


Timing
L band LES TDM Generator
Demodulator
- Reference Tuning

L band Interstation Signalling


Data
Link Demodulator

C band Interstation Signalling Data


Link Modulator

C band LES TDM Data


Modulator

Tuning and timing

Inmarsat-C
Test Terminal TERRESTRIAL
LINKS

5 Inmarsat-C Mobile Earth Station


The Inmarsat-C system has been specified so as to minimize the cost of the mobile terminal
equipment. Automated commissioning and performance verification procedures are used. The
antenna gain profile of the MES is such that a non-stabilized antenna can be used and error
correction coding has been specified in order to minimize the EIRP requirement from the MES.

Figure 2 (on the following page) shows a block diagram of a typical Inmarsat-C MES.

Volume 1: System Description, Chapter 2: System Overview Page: 6


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 2: Inmarsat-C Mobile Earth Station Example Block Diagram

DCE DTE

Scrambler,
1200 Sps Convolutional DTE
Bpsk Encoder
HPA
Modulator And Message
Interleaver And USER
Access Data I/O I/O
Control User
And Interface
Message Message
LO Synthesizer
Handling Storage
Processor And
Preparation
Functions
Deinterleaver,
1200 Bps Decoder
LNA Bpsk And OTHER
Demod Descrambler I/O
PORTS

Below is a summary of some of the primary characteristics of the Inmarsat-C MES:

(a) minimum G/T (5°) –23 dB/K;

(b) minimum EIRP (5°) 12 dBW;

(c) antenna gain pattern The antenna gain pattern is not directly specified but must be such
that, for maritime applications, the minimum EIRP and G/T are met
down to –15o elevation in order to accommodate ship motion.

5.1 Mobile Earth Station Supervisory Functions


The Inmarsat-C system incorporates facilities for checking the satisfactory operation of MESs. Each
MES must pass a full commissioning test before being allowed access to the network. An MES can
also be given a performance verification test at any time.
The tests are carried out by an LES under the control of the NCS.

5.1.1 Commissioning Testing


Commissioning testing consists of a series of performance checks on a newly installed MES. These
tests are designed to ensure that the MES complies with the technical requirements. Notification of a
successful commissioning test is forwarded to all ocean regions.
The commissioning procedures are such that the required tests are performed automatically once the
request for commissioning testing has been initiated by the MES operator.

5.1.2 Performance Verification Test (PVT)

The Performance Verification Test is a fully automatic test to check individual MESs with respect to
signal level and some access and control responses.

Volume 1: System Description, Chapter 2: System Overview Page: 7


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The NCS maintains a record of all Performance Verification Tests conducted in the ocean region.
Tests may be performed at the initiative of the NCS under the following circumstances:

(a) on request from an LES;

(b) as part of the commissioning tests; and

(c) as may be requested by the Inmarsat NOC NCC.

The NCS may instruct any LES within that ocean region to perform the test and report the outcome.
After completing the test, the LES will transmit the results of the test to the NCS and to the MES.

6 Types Of Channels Used In The Inmarsat-C System


The general characteristics applicable to all Inmarsat-C channels are:

(a) modulation BPSK 1200 symbols/second

(b) information rate 600 bits/s

(c) FEC coding: - forward: 1/2 rate convolutional encoding with interleaving;
- return: 1/2 rate convolutional encoding with interleaving for
the MES message channel.

(d) first generation satellite the return channel transmission rate is 300 bit/s for all
services

(e) operational bandwidth TX 1626.5 - 1646.5 MHz


RX 1530 - 1545 MHz
in 5 kHz steps

6.1 NCS Common Channel


This is a TDM channel which is transmitted continuously by the NCS. All MESs logged into a
particular ocean region must be tuned to the NCS common channel when not engaged in message
transfer. Functions provided by this channel include:

(a) To-Mobile message announcements;

(b) From-Mobile message confirmations;

(c) polling commands;

(d) timing reference for all MESs;

(e) EGC message transmission; and

(f) informing the mobiles on a regular basis of the state of the network, or whenever the state
changes.

The channel operates at 1,200 symbols per second with a fixed frame length of 8.64s, resulting in
exactly 10,000 frames per day. To minimise data errors due to interference, the information is half rate
convolutionally encoded and interleaved on a frame by frame basis: the data rate is therefore 600
bit/s.

All message and signalling information is conveyed in packets; 639 bytes per frame. The first packet
in any frame is a bulletin board which contains the current operational parameters of that particular

Volume 1: System Description, Chapter 2: System Overview Page: 8


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ocean region. The bulletin board is followed by a number of signalling channel descriptor packets
which are used to transfer information about MES usage of the associated signalling channel.

6.2 LES TDM Channel


Each LES transmits at some time at least one TDM channel. These channels have the same structure
as the NCS common channel and carry call set up signalling, To-Mobile messages,
acknowledgements and call clear down signalling. Full ARQ is provided to ensure error free reception
at the MES.

An LES may operate more than one TDM channel and each channel may be demand assigned (see
Section 4 and Section 10).

6.3 Message Channel


Message channels are used by MESs to transfer store and forward messages to an LES. A signalling
channel is used during the call set up phase of the transfer, but the message itself is sent on a
message channel assigned by the LES.

Access to the channel is allocated on a TDMA basis. The destination LES allocates a transmission
start time to each MES that is waiting to transmit. Once assigned a start time, the MES transmits all of
its message without interruption.

The information to be sent is formatted into packets, each containing 127 bytes, and placed into
frames. A frame may contain between one and five packets: the size is fixed for a particular
transmission. As in the NCS common channel, the information is scrambled, half rate convolutionally
encoded and interleaved. Before transmission, an acquisition preamble is added. The transmission
rate is 600 symbols per second for first generation satellites and 1,200 symbols per second for
second generation satellites. Full ARQ is provided to ensure that messages are received free of
errors.

Each LES has a number of MES message channels assigned to it by the NCS. The number of
channels that are assigned to an LES depends on the amount of traffic.

6.4 Signalling Channel


Signalling channels are used by MESs to transmit signalling packets to LESs and NCSs. Each LES
has one or more signalling channels assigned to it. There is a signalling channel associated with each
NCS common channel.

These channels operate in a combination of slotted ALOHA and reserved access mode. If more than
one MES transmits in the same slot, it results in a `collision' at the receiving LES or NCS. To minimise
the time elapsed before an MES becomes aware that its transmission was not successful, the
signalling channel descriptor packet transmitted in each frame on the TDM indicates the status of all
slots associated with that signalling channel (that is, reserved, unreserved, received, not received).

Slot timing is based on the TDM frame of 8.64s: each slot can carry a burst of 120 bits. For first
generation satellites, each time frame is divided into 14 slots and the transmission rate is 600 symbols
per second. Frames used with second generation satellites have 28 slots with a transmission rate of
1,200 symbols per second.

The burst packets used by the MESs to access the signalling channel do not have dedicated
acquisition preambles, thus maximising the channel capacity.

This channel can be used for the data reporting service, when a small amount of information can be
transmitted over the link. This is an efficient means of sending regular data reports without having to
use the MES message channel. No ARQ is provided in this mode, but the MES monitors the
signalling channel descriptor packets and will be informed of any errors.

Volume 1: System Description, Chapter 2: System Overview Page: 9


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

All MESs use a signalling channel to the NCS for logging in and out of the network. Its characteristics
are exactly the same as an LES – MES signalling channel.

6.5 NCS – NCS Signalling Channel


This is an inter-regional data connection between each of the NCSs which allows the NCSs to
exchange information concerning the MESs which are currently operational in their coverage area.

The links use automatic dial up voice band data channels over the PSTN and operate at 600 bits per
second using CCITT V.22 full duplex modems. CCITT X.25 link layer procedures are used for the
interchange of information.

6.6 NCS – LES Signalling Links


Every LES offering Inmarsat-C services has an interstation signalling link to the NCS. All initial stage
signalling from an LES passes over these links to the NCS for transmission via the NCS Common
Channel. The forwarding of the EGC messages to the NCS is also via this link. Distress Alerts
received at the NCS are forwarded over this link to the LES. The ISL is also used for passing network
information between the NCS and the LESs to allow the NCS to manage the channels on the network.

6.7 LES Channel Assignments


LES channel assignments are made by the NCS on request from the LES. This request can be made
at start up of the station or on traffic demand if the system is working in demand assignment mode
(see Section 4 and Section 10). Each assignment consists of the following channels:

(a) one TDM channel;

(b) one or more signalling channels; and

(c) one or more message channels.

7 Interfaces

7.1 Mobile Earth Station Interface


The MES is defined as a DCE and DTE combination. The protocols of the Inmarsat-C system are
implemented in the DCE part of the MES.

7.2 Land Earth Station Terrestrial Interfaces


Figure 1-1 in Chapter 1 indicates some of the terrestrial interfaces that could be supported by an LES
offering Inmarsat-C services. The particular interfaces provided at an LES are decided by the LES
operator.

The following services are, however, mandatory at the LES:

(a) store and forward telex;

(b) EGC message handling; and

(c) distress alert handling

8 Inmarsat-C Services

Volume 1: System Description, Chapter 2: System Overview Page: 10


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The main categories of services available in the Inmarsat-C system are:

(a) store and forward message transfer

(b) Distress calling; and

(c) Enhanced Group Calling.

Store and forward message transfer in the Inmarsat-C system involves the formatting of complete
messages at the LES or the MES before transmission over the satellite channel. The messages are
then transmitted to mobile or to ground when transmission resources are available.

Only store and forward message transfer to the telex network is specified as a mandatory service for
all LESs and MESs: all LESs must also support Distress calling and EGC. Maritime distress calling is
not allowed from land mobile MESs. Other services are optional.

8.1 Store and Forward Message Transfer

8.1.1 To Mobile Message Transfer


When an LES receives a message from the terrestrial network, it must first establish a connection with
the MES that is to receive the call. This takes place in three stages:

(a) ocean region registration check and acceptance of the message

(b) call announcement via the NCS common channel

(c) establishment of a logical channel.

The procedure is initiated when the LES receives a call from the terrestrial network. The LES checks
that the MES is authorised to receive calls and is logged into the ocean region. If all checks pass, the
message is accepted and stored. Otherwise the LES rejects the call, or may transfer it to the correct
ocean region if possible.
The LES requests the NCS to announce the call to the MES. The NCS sends the announcement
when the MES is idle (and, if operating in demand assign mode, when a TDM assignment is
available). The LES is notified when the call announcement has been sent.

The announcement tells the MES that a message is waiting, which LES is holding the message, and
the To-Mobile TDM frequency to which it should tune. The MES tunes and synchronizes to the TDM
channel and receives the LES bulletin board and signalling channel descriptor packets. The MES
replies with an assignment response, establishing the logical channel between itself and the LES.

The message is sent in packets. The packets include checksums which are examined by the MES to
detect transmission errors. The packets are also numbered sequentially so that any lost packets can
be identified.

When all the packets have been transferred, the LES requests acknowledgement and the MES
responds with a list of any packets that have been lost or received in error. These packets are
retransmitted and again the LES requests acknowledgement of their receipt. The process is repeated
until the MES has satisfactorily received all the message packets.

Unless there is another message waiting for the same MES, the LES clears the connection and the
MES retunes to the NCS common channel. If another call is waiting, a Logical Channel Assignment is
issued instead of a Clear and remains in effect until the call is cleared in the normal way.

8.1.2 From Mobile Message Transfer

Volume 1: System Description, Chapter 2: System Overview Page: 11


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

In permanently assigned mode, when an MES originates a call it first tunes to the TDM frequency for
the required LES. (The MES is supplied with this information when it logs into the ocean region).
Using the associated signalling channel, the MES requests an assignment.

If the LES is unable to respond immediately—in demand assigned mode, for example—it
acknowledges the assignment request and indicates that the call is pending. When a channel
becomes available, the LES requests to issue a call announcement similar to that used for To-Mobile
messages. On receiving the announcement, the MES tunes and synchronizes to the TDM given in
that packet.

The LES informs the NCS that communication has been established and the MES is placed on the
busy list. If the LES can accept the message it sends a logical channel assignment to the MES. No
specific response is required: the MES transmits its message to the LES on the message channel.

When transmission is complete, the LES sends an acknowledgement and packets with errors are
retransmitted, as for To-Mobile message transfer. Alternatively the LES may send the logical channel
assignment instead of the acknowledgement, requiring the MES to retransmit the entire message.
When all the packets have been satisfactorily received, the LES clears the connection and the MES
retunes to the NCS common channel.

8.1.3 Mobile to Mobile Message Transfer


Messages can be transferred from mobile to mobile via an LES. This can be considered as a From
Mobile call followed by a To-Mobile call.

8.2 Distress calls


(This is a maritime application only).

In the Inmarsat-C system, there are two distinct ways of processing distress communications: distress
alerting and distress priority messaging.
Throughout the Inmarsat-C communications system, distress calls received from MESs are always
given priority over other messages. All distress calls are routed to the associated Rescue
Coordination Centre.

8.2.1 Distress Alerting


In the Inmarsat-C system a Distress Alert is a data packet transmission. It is carried over the
signalling channel. The only action required from the SES operator is activation of the transmission by
pressing a protected push-button. Such buttons may be mounted at locations remote from the SES. If
an SES is already engaged in message transfer, activation of the distress alert mode will cause the
message to be abandoned and the distress alert to be transmitted.

In the Inmarsat-C system a distress alert contains the identity of the SES and supporting information
(e.g. course, speed, "nature of distress", etc.), Volume 3, Part 2, Chapter 5, Annex A; Section 8.2
refers.

If the LES is working with a permanent TDM the distress alert is sent directly to the LES. In demand
assigned mode, however, the distress alert is sent to the NCS which relays it to the LES. In either
case the MES receives an acknowledgement; the LES is responsible for forwarding the distress alert
to the RCC without delay or, if forwarding fails, taking appropriate action.

A MES which is not logged into an ocean region transmits its distress alert to the NCS. The distress
alert is forwarded to an LES in the same way as for demand assigned operation. The NCS enforces a
login for the MES: this ensures that subsequent distress priority messages may be handled between
an LES and an MES using the normal protocols. If the LES given in the distress alert is not valid for
the region, the distress alert will be handled by the NCS.

Volume 1: System Description, Chapter 2: System Overview Page: 12


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

8.2.2 Distress Priority Messaging


Distress priority messages are store and forward messages, carried over a message channel, having
distress priority. These messages can be sent in both direction; To-Mobile and From-Mobile. A From-
Mobile distress priority message is composed and sent from the keyboard by the SES operator, who
must select distress priority before initiating the transmission.

8.3 Enhanced Group Calls


The Enhanced Group Calls service allows a ground based information provider to broadcast
messages to a selected group of MESs or to MESs within a specified geographical area.

All LESs support the EGC service.

Some MESs will be able to receive SafetyNETSM (MSI) and/or FleetNETSM (commercial broadcast
traffic), transmitted as part of by the EGC service. SafetyNET1 reception is generally a mandatory
capability for maritime installations employed in GMDSS applications. A Class 2 MES having a single
receiver will be able to receive EGC messages only when idle. A Class 3 MES having a second
receiver will permit continuous reception of EGC messages. (See Volume 3: Earth Station
Requirements, Part 2, Chapter 2, Section 2.4 for full definitions of MES classes.)

To initiate an EGC message the information provider sends the message and addressing information
via a terrestrial network to an LES. There are four methods of addressing available:

(a) General broadcast addressing used for All-ships broadcasts and Inmarsat system messages;

(b) EGC Network ID (ENID) addressing for broadcasting messages to groups or fleets of vessels `
with a common ENID;

(c) Individual addressing for sending messages to single MESs, and

(d) Area addressing using circular, rectangular or pre-defined geographical addresses.

The LES prepares EGC packets for forwarding to the NCS via the inter-station signalling link. The
NCS then transmits the EGC message packets on the Common Channel.

8.4 Optional Services

8.4.1 Polling
Polling consists of a command that will cause an MES to respond in a pre-determined manner. This
response can take the form of a preset message transmission to the LES initiating the poll; position
reporting, for example. The system provides the capability for a terrestrial message originator to poll a
selected group of mobiles. The system supports three modes of polling, namely:

(a) individually directed;

(b) group directed; and

(c) area directed.

The poll command packet can contain data or text.

8.4.1.1 Individually Directed

1 Further information on the International SafetyNET service is given in the "International


SafetyNET Manual", IMO-908, published by the International Maritime Organization.

Volume 1: System Description, Chapter 2: System Overview Page: 13


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

This type of polling command is directed at a specific MES. This provides the greatest guarantee of a
response since the NCS will only transmit the polling command when the required MES is idle.

8.4.1.2 Group Directed

In this mode a polling command is transmitted to a group of mobiles using a pre-defined group
identity.

8.4.1.3 Area Directed

This mode is similar to the group directed mode except that the command contains a geographic
address from which responses are desired. The addressed MESs must also be member of the pre-
defined Group.

8.4.2 Data Reporting


A data report is a service whereby a small amount of data is automatically transmitted by a mobile.
The data reports may be transmitted at regular intervals scheduled by the user but require no
command over a forward channel. The following are examples of data reports:

(a) position reporting;

(b) meteorological observations; and

(c) equipment performance monitoring.

8.5 Land Mobile Alerting


This service is optional for LESs and for land mobiles. Although it uses a similar protocol, it is entirely
separate from the maritime distress alerting service and uses different signalling channels.

When an LES accommodating Land Mobile Alerts receives an alert, it examines the Inmarsat Mobile
Number to determine whether it is a from a maritime or a land-based MES. Alerts received from MESs
commissioned for land use are not routed to the RCC: the destination is pre-arranged by the service
provider.

9 Overview Of Call Set Up Procedures


This section relates to Store and Forward message transfer calls.

Message transfer in the system can be considered as three distinct processes:

(a) between the DTE and the DCE at the MES;

(b) between the MES and the LES (via the satellite);

(c) between the LES and the terrestrial network.

Each process can be thought of as a completely independent message transfer process. This allows
the satellite portion of the link to be completely defined as a memory-to-memory transfer between LES
and MES.

9.1 MES Originated Calls


Figure 3 (on the following page) is a sequence chart for an MES originated call to an LES with a
permanent TDM channel.

Volume 1: System Description, Chapter 2: System Overview Page: 14


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

To transfer an MES originated message, the MES must tune to the LES to which the message is to be
transferred. After synchronizing to the frame of the LES TDM channel, the MES transmits a request
message in a random access slot in an MES signalling channel. When the request is processed, the
LES commands the MES to tune to a particular MES message channel frequency and to transfer the
message. Message packets are checked by the LES for errors; any requiring retransmission are
advised in the LES's acknowledgement packet. Upon completion of transfer, the MES is released and
it re-tunes to the NCS common channel.

9.2 Terrestrial Originated Calls


Figure 4 is a sequence chart for a ground originated call from an LES operating a permanent TDM
channel.

The terrestrial subscriber places a call to the desired MES. The call is routed via the terrestrial
network to the appropriate LES. This LES must check for the availability of the required MES within
the ocean region. Each MES is required to register its presence in an ocean region by logging in. The
registration information is maintained at each LES and used as the basis of rejecting or accepting
ground originated calls. A call announcement is transmitted on the NCS common channel.

Volume 1: System Description, Chapter 2: System Overview Page: 15


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 3: From-Mobile Call Procedure

NETWORK LAND EARTH MOBILE


COORDINATION STATION EARTH
STATION STATION

Assume MES has completely formatted


message waiting for transmission
including delivery information and MES
listening to NCS Common Channel
NCS Common Channel

MES tunes to the LES TDM


and decodes its Bulletin Board.

TDM

Select a signalling channel number


from the Bulletin Board and tune
transmitter

REQUEST
Signalling Channel

Request burst received


MES BUSY
ISL
LOGICAL CHANNEL ASSIGNMENT
NCS updates database to
TDM
indicate that the MES is busy
Included in the Assignment is the
frequency for the Message
Channel (MC) for sending the
message - tune transmitter to MC.
MESSAGE
LES receives packets and notes those
in error. Acknowledgement includes any
packets to re-transmit.
ACKNOWLEDGEMENT
TDM
After LES has received all
packets without error
CLEAR
TDM
MES IDLE Re-tune receiver to the
ISL NCS Common Channel
NCS updates database
If MES requested confirmation, then
after delivery of message to the
terrestrial network
CONFIRMATION
ISL
NCS relays confirmation via the
Common Channel

CONFIRMATION

Volume 1: System Description, Chapter 2: System Overview Page: 16


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 4: To-Mobile Call Procedure

NETWORK LAND EARTH MOBILE


COORDINATION STATION EARTH
STATION STATION
Request to send Message
from Terrestrial Network. Assumed tuned to NCS
LES checks local MES List for Common Channel
validity of request

MES STATUS REQUEST


ISL
Check Mobile Status
MES STATUS
ISL

ANNOUNCEMENT
NCS Common Channel

The Announcement includes the logical


channel assignment. Find the frequency
for the LES TDM in the Announcement
packet and tune receiver. From the
Bulletin Board find a signalling channel
and tune transmitter

ASSIGNMENT RESPONSE
Signalling Channel
LES free to send message

Message Packets
TDM
MES BUSY Receive Packets and note
ISL those received in error
REQUEST FOR ACKNOWLEDGEMENT
TDM
Tell LES which packets to
re-transmit

ACKNOWLEDGEMENT
MES Signalling Channel

If packets to re-transmit, then


repeat message sequence, else
CLEAR
TDM
[60] seconds later
Tune Back to NCS Common
MES IDLE
ISL Channel
NCS updates database

Volume 1: System Description, Chapter 2: System Overview Page: 17


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

10 LES Channel Management


Under normal operating conditions the TDM channels, message channels and signalling channels are
permanently assigned. In order to conserve power in the satellite, however, demand assigned
operation of some or all channels can be employed. In this mode TDM channels and their associated
return channels are allocated by the NCS as and when they are needed.

On request, the NCS allocates channels to those LESs participating in the demand assignment
operation.

11 Spot Beam Operation


Generally, one global beam is used to cover an entire ocean region. However, in order to utilise
power efficiently, spot beam operation can be employed by some satellites. There may be several
spot beams in operation in a given ocean region, each with its own NCS common channel and
associated signalling channels.

The MES logs in at a particular spot, which enables the NCS or LES to route information to it.

12 MES Ocean Region Registration


Registration is required so that the availability of a particular MES in the called ocean region is known
before an LES accepts a ground-originated message for it.

The NCSs communicate via the NCS/NCS signalling channel to update their MES lists. When an NCS
is informed that an MES has logged in to another ocean region, that MES is recorded as unavailable.
All LESs are then advised which ocean region each MES is logged into.

Volume 1: System Description, Chapter 2: System Overview Page: 18


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 3: System Parameters

Contents

1 Introduction ............................................................................ 3

2 Channel Characteristics .......................................................... 3


2.1 Link Budgets .....................................................................................................3
2.2 Fading Characteristics ......................................................................................3
2.3 Frequency Offsets .............................................................................................4
2.4 Signal Processing System Characteristics ........................................................4
2.4.1 Signal Processing Features ...........................................................................4
2.4.2 Signal Processing Effects ..............................................................................4
Table 1: 'Worst Case' Forward Link Budget ............................................................5
Table 2: ‘Worst Case’ Return Link Budget ..............................................................6
Table 3: Random Loss Elements ............................................................................7
Forward Link ..............................................................................................................7
Return Link ................................................................................................................7
Table 4: System Frequency Error Budgets .............................................................8
Table 4-1: Frequency Error Budgets for Aero-C ................................................... 10
Table 4-2: Frequency Error Budgets for Aero-C ................................................... 11

3 System Performance Objectives ............................................ 11


3.1 Quality Objectives for Forward Links .............................................................. 12
Table 5: Forward Link Error Probabilities (Excluding Sync. Loss)......................... 12
Table 6: Forward Link Error Probabilities (Total Budget) ...................................... 12
3.2 Quality Objectives for MES Message Channel ............................................... 13
Table 7: MES Message Channel - 1200 Symbols/s .............................................. 13
Table 8: From-Mobile Message Channel - 600 Symbols/s ................................... 13
3.3 Quality Objectives for Signalling Channel ....................................................... 13
3.4 Undetected Error Probabilities ........................................................................ 14

Volume 1: System Description, Chapter 3: System Parameters Page: 1


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Table 9: Quality Objectives - C/M = 7 Db, C/No = 32.5 dBHz (First Generation),
C/No = 35.5 dBHz (Future Generations) ................................................. 14

4 Message Delivery Delay Objectives........................................ 14


4.1 Store And Forward Message Transfer ............................................................ 14
4.2 Distress Alert Performance Objectives ........................................................... 15
4.2.1 LES to Rescue Coordination Centre Connection Time ................................ 15

Volume 1: System Description, Chapter 3: System Parameters Page: 2


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
This Chapter provides additional performance information.

2 Channel Characteristics
The "channel" is considered here as all that which lies between information packets to be transmitted,
and those packets as received. Therefore, in addition to the effects of Gaussian noise and fading, the
effects of the signal processing implied by the channel structure also need to be considered. These
various channel impairments are detailed in the following sections.

2.1 Link Budgets


An Inmarsat-C link analysis differs from a typical satellite link analysis, because of the ARQ nature of
the system. In a typical system, there is a defined threshold level of C/No (at the receiver
demodulator) which defines a quality of service and is deemed a limit of acceptability; the percentage
of time in excess of this threshold is the availability. This would be inappropriate with Inmarsat-C
because variations in C/No do not affect the quality of the received message. In Inmarsat-C, C/No
level only affects the number of re-transmissions, and hence message delay and the system capacity.

Therefore, a distribution of C/No across the population of MESs may be allowed and this reflects the
practical situation. A small percentage of MESs in the coverage area will have lower C/No values, and
higher packet repeats by these MESs will be acceptable. In the link budgets shown in Tables 1 and 2,
a different acceptability level for 80% and 99% is given for this reason.

Although a higher performance is specified for the MES antenna at low elevation angles, the worst
case performance still occurs at 5° elevation angle. The worst case link budgets are:

(a) with MES and LES at 5° elevation;

(b) minimum values for G/T and EIRP; and

(c) worst case transponder loading (that is, fully loaded transponder and a channel having the
lowest Carrier/Intermodulation ratio).

In addition to this, the variables in the budgets such as polarization loss, wet radome, noise
degradation and precipitation loss, are combined by adding mean values and taking RMS values of
the deviations to produce 80% and 99% values. For reference, the values for the random losses are
given in Table 3.

2.2 Fading Characteristics


The characteristics of the channel are dominated by fading.

The multipath phenomenon is particularly prevalent in a maritime environment. This arises from the
reflection of transmitted or received signal off multiple points of the sea surface in the vicinity of the
vessel. Measurement programmes and theoretical computer simulations such as CCIR Report 762-1
have demonstrated that this fading can be modelled by Rician Fading theory. Qualitatively speaking
the fading can be modelled as the combination of two signals. One signal is the direct carrier. The
other is a replica but with slowly varying phase and amplitude characteristics according to a Rayleigh
distribution.

The channel model is characterized by the ratio of average power in the direct signal to average
power in the reflected signal and by the filter characteristic of the band limiting process. For the case
of an antenna pattern representative of Inmarsat-C at very low elevation angles (5°), the power ratio
has been measured as 7 dB and the filter characteristic may be expressed as:

Volume 1: System Description, Chapter 3: System Parameters Page: 3


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

F(f) = second order Butterworth with cut-off frequency (3dB) at 0.7Hz.


Multipath is less common on land, where interruption of the signal by structures (tall buildings or
bridges over roads, for example) is more of a problem.

2.3 Frequency Offsets


The satellite system will also be subject to residual frequency offsets, due to uncorrected Doppler
shifts and LES oscillator uncertainties. Table 4 shows the system frequency error budget for worst
case residual Doppler frequencies and uncertainties. All LESs and NCSs make use of the existing
Inmarsat-A AFC system.

2.4 Signal Processing System Characteristics


This section provides a summary of the signal processing elements used to attain acceptable
performance over the link. The error mechanisms inherent in this processing are then described since
they have an impact both on performance evaluation and testing.

2.4.1 Signal Processing Features


Because of the low gain MES antenna, both forward and return links are energy limited, as may be
seen from the link budgets. Half-rate convolutional encoding (constraint length k=7) is used to provide
Forward Error Correction which can provide in the region of 5 dB coding gain in an unfaded link (for
example, see CCIR Report 921).

A given bit of information passing through the encoder only has an effect on a group of 14
consecutive symbols, and since the fading bandwidth is very low, all 14 symbols would be equally
involved in a fade. To counter the above situation, encoded symbols are assembled into a block
before transmission. They are then transmitted in a different order to that in which they were
assembled. This process, called "interleaving", is specified in detail in other volumes of the Inmarsat-
C definition documentation. The effect of this process is to spread transmission of the 14 symbols
associated with a given data bit over a length of time which is large compared with a fade duration.

Therefore only some of the 14 symbols may be corrupted due to one typical fade, and the redundancy
built into the transmitted symbol stream allows reconstruction of the original data stream.

The above is true for the continuous mode forward TDM channels, and the quasi-continuous MES
message channel. For the burst mode MES signalling channel, interleaving is not applied because the
bursts are too short for it to have any useful effect.

Scrambling of data has been applied to all the channels. Although it is not necessary for energy
dispersal due to the low bit rate (CCIR Report 384-3), it is used in order to ensure adequate symbol
transitions for the demodulator clock recovery. Messages with a high pattern content (tabulations, for
example) can interact in the interleaver to produce much longer sequences without symbol transitions
than might be expected with random data.

Every packet transmitted on any of the Inmarsat-C channels contains a 16 bit checksum field.
Following de-interleaving, decoding and unscrambling operations, the receiver computes an expected
checksum for each packet. This is compared with the actual checksum received to verify that the
packet has been correctly received.

2.4.2 Signal Processing Effects


While a relatively short (k=7) constraint length has been selected to allow use of maximum likelihood
decoding techniques (such as the Viterbi algorithm), the MES manufacturer is free to select any
decoding method that meets the overall performance specifications.

It is in the nature of convolutional decoders to generate errors in burst, and different decoder
algorithms implementations can produce a wide variation of error burst characteristics.

Volume 1: System Description, Chapter 3: System Parameters Page: 4


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

As the system is basically a packet system with ARQ, the prime performance parameter is packet
error rate. Packet error rate in practice is highly dependant upon burst error rate but almost
independent of the number of bits in a burst. For this reason Bit-Error-Rate is not a useful metric.
As a baseline for defining performance limits, a Viterbi decoder has been assumed operating on three
bit soft decision sample.

Table 1: 'Worst Case' Forward Link Budget

Forward Link: 80% of time

1st GEN 2nd GEN


LES EIRP (dBW)
61.4 61.0
Path Loss (dB)
200.9 200.9
Absorption Loss (dB)
0.4 0.4
Satellite G/T (dB/K)
–15.0 –14.0
Mean Uplink C/No (dBHz)
73.7 74.3
Mean Satellite C/Io (dBHz)
55.8 55.8
Satellite mean EIRP (dBW)
21.4 21.0
Path Loss (dB)
188.5 188.5
Absorption Loss (dB)
0.4 0.4
MES G/T (dB/K)
–23.0 –23.0
Mean downlink C/No (dBHz)
38.1 37.7
Nominal Unfaded C/No (dBHz)
38.0 37.6
Interference Loss (dB)
0.5 0.5
Total RSS random loss (80%) (dB)
1.2 0.8
Overall C/No
36.3 36.3
(dBHz)
35.5 35.5
Required C/No (dBHz)
0.8 0.8
Margin (dB)

Forward Link: 99% of time

1st GEN 2nd GEN


LES EIRP (dBW) 61.4 61.0
Path Loss (dB) 200.9 200.9
Absorption Loss (dB) 0.4 0.4
Satellite G/T (dB/K) –15.0 –14.0
Mean Uplink C/No (dBHz) 73.7 74.3
Mean Satellite C/Io (dBHz) 55.8 55.8
Satellite mean EIRP (dBW) 21.4 21.0
Path Loss (dB) 188.5 188.5
Absorption Loss (dB) 0.4 0.4
MES G/T (dB/K) –23.0 –23.0
Mean downlink C/No (dBHz) 38.1 37.7
Nominal Unfaded C/No (dBHz) 38.0 37.6
Interference Loss (dB) 0.5 0.5
Total RSS random loss (99%) (dB) 2.2 1.6
Overall C/No 35.4 35.5
(dBHz) 34.5 34.5

Volume 1: System Description, Chapter 3: System Parameters Page: 5


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Required C/No (dBHz) 0.9 1.0


Margin (dB)

Table 2: ‘Worst Case’ Return Link Budget

Return Link: 80% of time

MCS MARECS 2nd GEN


MES EIRP (dBW)
12.0 12.0 12.0
Path Loss (dB)
189.0 189.0 189.0
Absorption Loss (dB)
0.4 0.4 0.4
Satellite G/T (dB/K)
–13.0 –11.0 –12.5
Mean Uplink C/No (dBHz)
38.2 40.2 38.7
Mean Satellite C/Io (dBHz)
49.0 49.0 45.8
Transponder Gain (dB)
150.9 150.9 158.0
Satellite mean EIRP (dBW)
–26.5 –26.5 –19.4
Path Loss (dB)
197.2 197.2 195.9
Absorption Loss (dB)
0.5 0.5 0.5
LES G/T (dB/K)
32.0 32.0 30.7
Mean downlink C/No (dBHz)
36.4 36.4 43.5
Nominal Unfaded C/No (dBHz)
34.1 34.7 36.8
Interference Loss (dB)
0.5 0.5 0.5
Total RSS random loss (80%) (dB)
1.0 1.0 0.6
Overall C/No
32.5 33.2 35.7
(dBHz)
32.5 32.5 35.5
Required C/No (dBHz)
+0.0 +0.7 +0.2
Margin (dB)

Return Link: 99% of time

MCS MARECS 2nd GEN

Volume 1: System Description, Chapter 3: System Parameters Page: 6


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

MES EIRP (dBW)


12.0 12.0 12.0
Path Loss (dB)
189.1 189.1 189.1
Absorption Loss (dB)
0.4 0.4 0.4
Satellite G/T (dB/K)
–13.0 –11.0 –12.5
Mean Uplink C/No (dBHz)
38.1 40.2 38.6
Mean Satellite C/Io (dBHz)
49.0 49.0 45.8
Transponder Gain (dB)
150.9 150.9 158.0
Satellite mean EIRP (dBW)
–26.5 –26.5 –19.4
Path Loss (dB)
197.2 197.2 195.9
Absorption Loss (dB)
0.5 0.5 0.5
LES G/T (dB/K)
32.0 32.0 30.7
Mean downlink C/No (dBHz)
36.4 36.4 43.5
Nominal Unfaded C/No (dBHz)
34.0 34.7 36.8
Interference Loss (dB)
0.5 0.5 0.5
Total RSS random loss (80%) (dB)
1.8 1.8 1.2
Overall C/No
31.7 32.4 35.1
(dBHz)
31.5 31.5 34.5
Required C/No (dBHz)
+0.2 +0.9 +0.6
Margin (dB)

Table 3: Random Loss Elements

First Generation Second Generation

Mean (dB) Sigma (dB) Mean (dB) Sigma (dB)

Forward Link
Ground-to-Satellite
LES EIRP Variations 0.00 0.42 0.00 0.42
Rainfall Loss 0.00 0.27 0.00 0.27
Polarisation Loss 0.23 0.07 0.07 0.03

Satellite-to-MES
Polarisation Loss 0.24 0.38 0.06 0.19
Wet Radome Loss 0.09 0.09 0.09 0.09
Noise Temperature
Degradation 0.09 0.09 0.09 0.09

Return Link
MES-to-Satellite
Polarisation Loss 0.24 0.38 0.06 0.19
Wet Radome Loss 0.09 0.09 0.09 0.09

Satellite-to-Ground
Polarisation Loss 0.23 0.07 0.07 0.03
Rainfall Loss 0.00 0.14 0.00 0.14
Noise Temperature
Degradation 0.00 0.32 0.00 0.32

Volume 1: System Description, Chapter 3: System Parameters Page: 7


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Cumulative Losses

Forward link First Generation Second Generation

80% availability 1.20 0.78


99% availability 2.15 1.60

Return link First Generation Second Generation

80% availability 1.01 0.57


99% availability 1.79 1.18

The frequency uncertainties shown in Table 4 are based on 5 degrees satellite orbital inclination and
worst case MES and LES locations.

Table 4: System Frequency Error Budgets

Uncertainty Comments and


Uncertainty Source
(Hz) References

Ground to MES (C to L ) 100 Worst case estimate


100 Inmarsat A LES TRD
1 LES modulator and up-converter error 100 Worst case estimate
2 AFC pilot (C-L) 516
3 AFC compensation 154 Maximum velocity (60 knots)
4 Residual satellite Doppler 50 Vol 3, Part 2, Sec 4.1 (e)
5 MES L-band Doppler (RX)
6 MES short term Doppler (RX)

Total Uncertainty at MES at L -Band 1020


568
7 Worst case (100%) 850
8 RSS
9 Design objective ( > 99% )

MES to Ground (L to C ) with TDM reference 816 (7) -(6) - (5)


318 correlated with (5)
10 Compounded forward link error 103 correlated with (6)
11 MES L- Band Doppler (TX) 150 Vol 3, Part 2, Sec 3.4.8
12 MES short term Doppler (TX) 420
13 MES TX frequency accuracy 100 Inmarsat-A TRD
14 Residual satellite Doppler 100 Worst case estimate
15 AFC pilot ( L-C )
16 AFC compensation

Total uncertainty at LES input to demodulator 2007


792
17 Worst case (100%) 1450
18 RSS

Volume 1: System Description, Chapter 3: System Parameters Page: 8


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

19 Design Objective ( > 99.9 % )

Volume 1: System Description, Chapter 3: System Parameters Page: 9


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Table 4-1: Frequency Error Budgets for Aero-C


(Transmission accuracy is based on TDM reference, AMES AFC is based on direct Doppler
calculations)

Uncertainty
Uncertainty Source Comments and References
(Hz)

LES to AMES (C to L)
1 LES modulator and up-converter error 100 Worst case estimate
2 AFC pilot (C-L) 100 Std A CES TRD
3 AFC compensation 100 Worst case estimate
4 Residual satellite Doppler 516
5 AMES AFC error (Rx) 250 Residual Doppler after AMES
AFC correction*, Vol 3, Part 2
Sec 4.1(e)
*Comment: This includes
all errors induced by the
frequency calculation
scheme at the AMES,
including satellite
parameters error,
Total Uncertainty at AMES at L band tracking error, etc.
6 Worst case (100%) 1066
7 RSS 599
8 Design objective (>99%) 895

AMES to LES (L to C) with TDM reference


(AMES AFC is based on direct Doppler calculations)
9 Combined forward link error (100%) 816 does not include 5
10 Combined forward link error (RSS) 544 does not include 5
11 AMES AFC error (Tx) 516 correlated with 5
12 AMES Tx frequency accuracy 150 Vol 3, Part 2, Sec 3.4.8

Total Tx frequency error received at the satellite


13 RSS 771 Include all error contributions
originated at the AMES
14 Design objective (>99%) 1145
15 Residual satellite Doppler 420
16 AFC pilot (L-C) 100 Std A TRD
17 AFC compensation 100 Worst case estimate

Total uncertainty at LES input to demodulator


18 Worst case (100%) 2102
19 RSS 884
20 Design objective (>99.5%) 1450 The offset corresponding to
99.9% is 1630 Hz.

Volume 1: System Description, Chapter 3: System Parameters Page: 10


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Table 4-2: Frequency Error Budgets for Aero-C


(Transmission accuracy is based on high accuracy frequency reference, AMES AFC is based on
direct Doppler calculations)

Uncertainty
Uncertainty Source Comments and References
(Hz)

LES to AMES (C to L)
1 LES modulator and up-converter error 100 Worst case estimate
2 AFC pilot (C-L) 100 Std A CES TRD
3 AFC compensation 100 Worst case estimate
4 Residual satellite Doppler 516
5 AMES AFC error (Rx) 250 Residual Doppler after AMES
AFC correction*, Vol 3, Part 2
Sec 4.1(e)
*Comment: This includes
all errors induced by the
frequency calculation
scheme at the AMES,
including satellite
parameters error,
Total Uncertainty at AMES at L band tracking error, etc.
6 Worst case (100%) 1066
7 RSS 599
8 Design objective (>99%) 895

AMES to LES (L to C) with no TDM reference


(AMES AFC is based on direct Doppler calculations)
9 AMES AFC error (Tx) 266 correlated with 5
10 AMES Tx frequency accuracy 720 A corresponding Ref. accuracy
of 4.3.10-7 (Vol 3, Part 2, Sec
3.4.8)

Total Tx frequency error received at the satellite


11 RSS 769 Include all error contributions
originated at the AMES
12 Design objective (>99%) 1144
13 Residual satellite Doppler 420
14 AFC pilot (L-C) 100 Std A TRD
15 AFC compensation 100 Worst case estimate

Total uncertainty at LES input to demodulator


16 Worst case (100%) 1600
17 RSS 886
18 Design objective (>99.5%) 1450 The offset corresponding to
99.9% is 1630 Hz.

3 System Performance Objectives


These objectives refer to the performance of the satellite channels after forward error correction
decoding and before the ARQ system. They are given as an indication of the system design criteria

Volume 1: System Description, Chapter 3: System Parameters Page: 11


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

and are not to be interpreted as technical performance requirements, which are detailed in other
volumes of the Inmarsat-C definition documentation.

3.1 Quality Objectives for Forward Links


Both the NCS common channel and each LES TDM have the same transmission parameters and
error characteristics.

"PEP(L)" is defined here as the Packet Error Probability of a packet consisting of L-bytes. The
following Table 5 gives the target performance expected for various C/No values over a real channel
with C/M = 7 dB without taking synchronization loss into account (that is, assuming that cycle slips do
not occur).

Table 5: Forward Link Error Probabilities (Excluding Sync. Loss)

C/No PEP (128) PEP (40) PEP (20) PEP (10) PEP (1)
dBHz

34.0 0.080 0.025 0.013 0.007 0.0012


34.5 0.040 0.013 0.007 0.003 0.0006
35.0 0.020 0.006 0.003 0.002 0.0003
35.5 0.012 0.004 0.002 0.001 0.0002
36.0 0.004 0.002 0.0008 0.0004 0.0001

Table 6: Forward Link Error Probabilities (Total Budget)

C/No PEP (128) PEP (40) PEP (20) PEP (10) PEP (1)
dBHz

34.0 0.080 0.027 0.016 0.009 0.0038


34.5 0.040 0.014 0.008 0.005 0.0019
35.0 0.020 0.007 0.004 0.002 0.0009
35.5 0.012 0.004 0.002 0.0014 0.0006
36.0 0.004 0.002 0.001 0.0005 0.0002

The packet error probabilities are calculated from the values in Table 5 +2xPEP(1) (in Table 5).

Table 5 does not include a budget for synchronisation slips which may cause a complete frame to be
lost. The probability of a complete frame loss is assumed to be no greater than 2 x PEP(1) in Table 5.
The overall target including the synchronisation loss then follows in Table 6.

From the link budget in Table 1:

C/No is greater than 35.5 dBHz for 80% of the time.

C/No is greater than 34.5 dBHz for 99% of the time.

Using these values in Table 5, PEPs for 80% and 99% of the time are obtained; these values are for
worst case links with C/M = 7dB.

Volume 1: System Description, Chapter 3: System Parameters Page: 12


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

For situations in which it is necessary to assume aggregate packet error probabilities for a population
of MESs, the values corresponding to C/No = 35 dB in Table 6 are recommended.

3.2 Quality Objectives for MES Message Channel


The MES message channel contains only message packets but the interleaver block size can vary
(see Figure 3.10). Block size is defined by parameter N and for N=4 the block size (and therefore
performance) will be as in Table 6 for PEP (128).

Table 7 shows how the performance is expected to decline with decreasing N. For first generation
operation, frame lengths are automatically doubled and, as shown in Table 8, there is little advantage
expected with N greater than 2.

Table 7: MES Message Channel - 1200 Symbols/s

C/No Probability of Packet Error


dBHz PEP (128); 1200 Symbols/s
N=0 N=1 N=2 N=3 N=4

34 0.080
34.5 0.040
35 0.020
35.5 0.030 0.020 0.015 0.013 0.012
36 0.020 0.008 0.006 0.005 0.004
36.5 0.010 0.004 0.003 0.003 0.003

Table 8: From-Mobile Message Channel - 600 Symbols/s

C/No Probability of Packet Error


dBHz PEP (128); 600 Symbols/s
N=0 N=1 N=2 N=3 N=4

31 0.080 0.080 0.080


31.5 0.040 0.040 0.040
32 0.020 0.020 0.020
32.5 0.020 0.013 0.012 0.012 0.012
33 0.008 0.005 0.004 0.004 0.004
33.5 0.004 0.003 0.003 0.003 0.003

The choice of N is selected by the LES when setting up the channel according to the required
message length and margins available for the particular link. For assessing overall traffic
performance, it is recommended that this is done using:

C/No = 35 dBHz, N = 4 for 600 bits/s

C/No = 32 dBHz, N = 2 for 300 bits/s

3.3 Quality Objectives for Signalling Channel

Volume 1: System Description, Chapter 3: System Parameters Page: 13


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

This channel works on a slotted ALOHA basis and access may be in reserved or unreserved mode.
There are four possible outcomes of a transmission:

(a) packet received correctly;

(b) packet not received correctly and collision/error reported;

(c) packet in collision with another and collision/error reported;

(d) packet in collision with another but the stronger packet is decoded satisfactorily and no
collision/error is reported. In this case both MESs transmitting could believe that their burst has
been correctly received.

The objectives are given in Table 9.

3.4 Undetected Error Probabilities


All packets use the same 16 bit sum-check.

If an error-burst occurs in the packet, the probability of the checksum working out correctly is taken to
be 2-16 = 0.000015.

To obtain delivered packet error probabilities, the error probability should be multiplied by the above
value.

Table 9: Quality Objectives - C/M = 7 Db, C/No = 32.5 dBHz (First Generation),
C/No = 35.5 dBHz (Future Generations)

First Generation Second Generation


(300 bit/s) (600 bit/s)

Packet Error Probability 0.10 0.05


Probability of Collision 0.15 0.20

Probability of a given collision


being undetected 0.01 0.01

4 Message Delivery Delay Objectives


These objectives refer to the performance of the Inmarsat-C system in transferring data to and from
an MES. These criteria do not include the performance of the MES/data terminal equipment (DTE)
link or the terrestrial connection.

4.1 Store And Forward Message Transfer


There are three stages involved in forwarding a message:

a) establishing the connection;

b) transferring the data;

c) clearing the connection.

Volume 1: System Description, Chapter 3: System Parameters Page: 14


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Stage a) involves the establishment of satellite resources between an LES and an MES, for which the
objective is to establish the connection in less than five minutes on average.

Stage b) is of variable duration, depending on the message length, the quality of the circuit, and LES
resources.

Stage c) only consists of a single signal to the MES.

4.2 Distress Alert Performance Objectives


Distress alerts have the highest priority access to the resources available. The time to establish the
end-to-end connection from MES to the rescue coordination centre is the primary consideration.

4.2.1 LES to Rescue Coordination Centre Connection Time


The LES shall attempt to forward a distress alert to the Rescue Coordination Centre, in accordance
with the Radio Regulations, Article 39, paragraph 3149 and Article N39, paragraph N 3129.

Volume 1: System Description, Chapter 3: System Parameters Page: 15


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Chapter 4: Protocols for the Message Services

Contents

1 Introduction ............................................................................ 6
1.1 References to Constants...................................................................................6

2 Control Concepts .................................................................... 6


2.1 Bulletin Boards ..................................................................................................7
2.2 Registration .......................................................................................................7
2.3 Binding ..............................................................................................................7
2.3.1 Logical Channels ...........................................................................................7
2.3.2 Message References .....................................................................................7
2.4 Spot Beam Operation .......................................................................................7
2.5 Addressing ........................................................................................................8
Figure 1: Inmarsat-C Channels ...............................................................................9
Figure 2: Inmarsat-C Channels & Signals ............................................................. 10

3 Channel Structure ................................................................. 11


3.1 Frame Structure .............................................................................................. 11
3.1.1 TDM Channels ............................................................................................. 11
Figure 3: Timing Relationships Between Channels ............................................... 12
Figure 4: TDM Frame Information Field ................................................................ 14
Figure 5: TDM Scambling Process ....................................................................... 15
Figure 6: Scrambling Generator ............................................................................ 16
Figure 7: Encoder ................................................................................................. 16
Figure 8: Interleave Matrix .................................................................................... 17
Figure 9: Forward Link Serial TDM Transmission ................................................. 18
3.1.2 Message Channel ........................................................................................ 19
3.1.3 Signalling Channel ....................................................................................... 19
3.1.4 NCS – LES and NCS – NCS Interstation Signalling Channels .................... 20
Figure 10: Message Channel Frame Information Field Format ............................. 21

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 1
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 11: Message Channel Serial Data Format ................................................. 22


Figure 12: Signalling Channel Frame Format ....................................................... 23
Figure 13: Signalling Packet Scrambling Process ................................................. 24
Figure 14: Signalling Channel Encoder Start & Finish States ............................... 25
3.2 Packet Structure ............................................................................................. 26
3.2.1 TDM Channels ............................................................................................. 26
3.2.2 Signalling Channel ....................................................................................... 26
3.2.3 Message Channel ........................................................................................ 26
3.2.4 NCS – LES and LES – NCS Interstation Signalling Links ............................ 26
3.2.5 NCS – NCS Channel.................................................................................... 26
3.2.6 Coding of Information Transmitted over the Satellite Link ............................ 26
3.2.6.1 Mandatory Store and Forward Telex and EGC ................................................................... 26

3.2.6.2 Other Optional Coding ......................................................................................................... 26

Figure 15: TDM and ISL Packet Structures .......................................................... 27

4 Channel Access .................................................................... 28


4.1 NCS Common Channel................................................................................... 28
4.2 TDM Channel .................................................................................................. 28
4.3 Signalling Channels ........................................................................................ 28
4.3.1 Multislots and Slot States ............................................................................. 29
4.3.2 Unreserved Access ...................................................................................... 29
4.3.3 Reserved Access ......................................................................................... 30
4.4 Message Channels ......................................................................................... 31
4.5 Interstation Signalling Links ............................................................................ 31
4.5.1 NCS – NCS Communication ........................................................................ 31
4.5.2 NCS – LES Communication ......................................................................... 31
Figure 16: Bulletin Board Propagation for 2-Frame Slots ...................................... 32
Figure 17: Bulletin Board Propagation for 3-Frame Slots ...................................... 33
Figure 18: TDM Bulletin Board and Signalling Channel Desriptor Formats........... 34

5 Procedures to Establish Connections .................................... 35


5.1 To-Mobile Message Transfer .......................................................................... 35

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 2
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

5.1.1 Terrestrial Message Acceptance .................................................................. 35


5.1.2 Announcement ............................................................................................. 35
5.1.3 Establishing the Logical Channel ................................................................. 35
5.1.4 Exception Handling for Logical Channel Establishment ............................... 36
5.2 From-Mobile Message Transfer ...................................................................... 36
5.2.1 Call Request ................................................................................................ 36
5.2.2 Establishing the Logical Channel ................................................................. 36
5.2.3 Exception Handling for Logical Channel Establishment ............................... 37
5.3 Mobile to Mobile Message Transfer ................................................................ 37
Figure 19: To-Mobile Message Transfer ............................................................... 38
Figure 20: From-Mobile Message Transfer, Sheet 1 of 2 ...................................... 39
Figure 20: From-Mobile Message Transfer, Sheet 2 of 2 ...................................... 40

6 Message Transfer Procedures ............................................... 41


6.1 To-Mobile Message Transfer .......................................................................... 41
6.2 From-Mobile Message Transfer ...................................................................... 41
6.3 Mobile-to-Mobile Message Transfer ................................................................ 42
6.4 Maritime Distress Alerting ............................................................................... 42
Figure 21: Example for From-Mobile Message Transfer, Sheet 1 of 2.................. 43
Figure 21: Example for From-Mobile Message Transfer, Sheet 2 of 2.................. 44

7 Procedures to Clear Connections .......................................... 45


7.1 Normal Clearing .............................................................................................. 45
7.1.1 Land Earth Station Clearing ......................................................................... 45
7.1.2 Mobile Earth Station Clearing ...................................................................... 45
7.2 Forced Clearing .............................................................................................. 45
7.2.1 Land Earth Station Forced Clearing ............................................................. 45
7.2.2 Mobile Earth Station Forced Clearing .......................................................... 45
7.3 Land Earth Station TDM Release ................................................................... 46

8 Procedures for Message Delivery Confirmation...................... 46


8.1 To-Mobile Messages ....................................................................................... 46

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 3
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

8.2 From-Mobile Messages................................................................................... 46

9 Procedures for Ocean Region Registration ............................ 47


9.1 Logging In ....................................................................................................... 47
9.2 Logging Out .................................................................................................... 47
9.3 Network Updates ............................................................................................ 47
9.4 Spot Beams .................................................................................................... 48
9.5 MES Database Synchronisation via Registration Update Request ................. 48

10 Procedures for Commissioning and Performance Verification


(PVT) ......................................................................................... 48
10.1 Commissioning ............................................................................................. 48
10.1.1 Commissioning Initiation ............................................................................ 49
10.1.2 Commissioning Tests ................................................................................. 49
10.1.3 Completion of Commissioning.................................................................... 49
10.2 Performance Verification Testing .................................................................. 49
10.2.1 Requesting Performance Verification Testing ............................................ 49
10.2.2 Performance Verification Initiation ............................................................. 49
10.2.3 Performance Tests ..................................................................................... 50
10.2.4 Performance Verification Completion ......................................................... 50
10.3 Distress Alert Testing .................................................................................... 50
10.4 Results Reporting ......................................................................................... 50

11 Procedures for MES Database Coordination ......................... 51


11.1 Coordination Between NCS and NCS ........................................................... 51
11.1.1 MES Status Change .................................................................................. 51
11.1.2 NCS Recovery ........................................................................................... 51
11.2 Coordination between LES and NCS ............................................................ 51
11.2.1 MES Status Change .................................................................................. 51
11.2.2 LES Recovery ............................................................................................ 52
11.3 Decommissioning .......................................................................................... 52

12 Management of LES channels .............................................. 52

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 4
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

12.1 Permanent TDM Channel Groups ................................................................. 52


12.2 Demand Assigned TDM Channel Groups ..................................................... 53

13 Enhanced Group Calls ......................................................... 53


Figure 22: Transmission of EGC Message Using Single Headers ........................ 55
Figure 23: Transmission of EGC Message Using Double Headers ...................... 56

14 Spot Beam Satellite Network Operation................................ 57


14.1 NCS .............................................................................................................. 57
14.1.1 NCS Capacity Expansion ........................................................................... 57
14.2 LES ............................................................................................................... 57
14.3 MES .............................................................................................................. 57

15 Restoration Mode Network Operation ................................... 58


15.1 Demand assigned ......................................................................................... 58
15.2 Spot beam operation ..................................................................................... 58

16 Management Of Multiple Permanent LES TDMs ..................... 58

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 5
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

1 Introduction
This chapter describes the Inmarsat-C access control and signalling system. It contains a control method
overview, a description of the channel structure, followed by a description of the procedures required to
send and receive messages.

Detailed formats for all packets used in the signalling system are given in Volume 4: Packet Formats and
Usage.

Volume 5: Inmarsat-C SDL contains Functional Specification and Description Language (a CCITT standard)
diagrams for the system protocols.

1.1 References to Constants


In this chapter a number of constants are referred to but not specified: this is because they are liable to
change in the light of operational experience. These values are specified below.

Because they are subject to alteration, it is recommended that they are implemented in such a way that
they can be changed readily.

Section 2.3.1 Re-use of logical channel number: last transmission of clear or forced
clear by LES + (55 mins (generation I satellite) or 45 mins (generation II)).

Section 2.3.2 Re-use of message reference number: last transmission of clear or


forced clear by LES + 24 hours.

Section 4.3.1 Boundary between 2-frame and 3-frame slots: this depends upon timing
within the LES and must be set by the LES manufacturer.

Section 4.3.2 Retransmission period: initially 1. Multiplied by 2 to a maximum of 64


when collision rate exceeds high threshold. If current value is X, is set to
MAX(1,X-1-INT(X/5)) when collision rate is less than low threshold.

Retransmission adjustment interval: 1 frame.

High Threshold: .15

Low threshold: .1

Collision rate: proportion of errored slots to available slots averaged over last 10
frames.

Section 7.3 Time for LES to initiate a To-Mobile message before its TDM becomes
clear: 25s.

2 Control Concepts
This section briefly introduces the control concepts used in the access control and signalling system. Figure
1 indicates the channels used by Inmarsat-C and Figure 2 shows the associated signals for both signalling
and message transfer. Each land earth station (LES) is able to transmit its own carrier — the LES TDM.
The network coordination station (NCS) also transmits a carrier — the NCS common channel. The NCS
common channel is the centralized resource of the system which carries both Inmarsat-C signalling and
Enhanced Group Call (EGC) messages.

A mobile earth station (MES) communicates with an LES and the NCS via signalling channels. For the
transmission of messages to an LES, an MES uses a message channel. The LESs communicate with the
NCS using dedicated Interstation Signalling links which are described in Volume 3: Earth Station
Requirements, which also describes the links which allow NCSs to communicate with each other.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 6
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

2.1 Bulletin Boards


An NCS common channel contains a bulletin board in every frame. This bulletin board contains the static
operational parameters of that NCS common channel.

Each TDM transmitted by an LES contains the same format bulletin board every frame. The bulletin board
contains the static operational parameters for services provided via that TDM.

2.2 Registration
Each MES is required to log in to an ocean region, thus registering the terminal in the system. This
procedure permits an LES to check for the presence of an MES in its operational ocean region before
accepting a message from a terrestrial caller. Because the NCS may be transmitting more than one
common channel (in the case of spot beam operation, for example) an MES's login is associated with a
specific common channel. In this way, the NCS is able to send signalling information on the NCS common
channel being used by a particular MES.

2.3 Binding
Message transfer in the Inmarsat-C system is subject to a binding procedure before information packets are
transferred. The binding procedure provides:

(a) confirmation of the availability of both ends of the link by means of acknowledgement signals;

(b) an indication of length of the message to be transferred in packets of defined sizes; and

(c) a logical channel number used for the transfer and a message reference.

2.3.1 Logical Channels


For message transfer, a logical channel for each separate connection is assigned by the LES. At any time,
only one logical channel may be associated with a particular LES – MES pair.

Logical channel numbers are used to reduce protocol overheads by providing a unique reference to an on-
going transfer. A logical channel number can be re-used when there is no danger that its re-use will
produce ambiguities (see Section 1.2 in this chapter).

2.3.2 Message References


A unique message reference is allocated to all From-Mobile, To-Mobile and EGC messages transferred
through the system. This identifier is allocated by the LES handling the transfer. It differs from the logical
channel number in that its uniqueness must persist until there is no chance that the message can be
referred to again (see Section 1.2 in this chapter).

2.4 Spot Beam Operation


On the introduction of zone or spot beam satellite operation, a separate NCS common channel carrier will
be transmitted in each of the zone or spot beams. For initial NCS common channel acquisition, the MES
must search through the NCS common channel frequencies until it can establish synchronization for the
selected ocean region. Thereafter, at regular intervals, the MES is required to undertake a search of NCS
common channels to find the one with the highest signal strength. If the NCS common channel found is not
the one currently being used, the MES automatically initiates a new login.

MESs monitor the bulletin board error rate of the received NCS common channel and may, when it exceeds
a threshold, scan NCS Common Channels as described above. This will allow the MES to move between
spot beam coverage areas and satellite coverage areas and keep a valid NCS common channel. When
changing spot beams or satellite coverage areas, MESs inform the NCS of their new common channel by
logging in.

Maritime Safety Information broadcast via the International SafetyNET Service is only carried on the
global beam. In addition the GMDSS requires continuity of the distress alerting function.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 7
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Consequently, automatic NCS scanning either as a result of high BBER or on a regular basis is
prohibited in all maritime MESs and maritime EGC receivers. Instead, when the BBER becomes
excessive, an alarm shall be raised and the operator shall be advised to initiate NCS scanning
manually.

2.5 Addressing
During the expected life of the Inmarsat-C system, various terrestrial services may be introduced each
having their own addressing schemes. To accommodate potential new services, a flexible method of
encoding addresses is adopted. In addition, a primary address is used; this is a subset of a destination
address and provides enough information for an LES to decide whether an incoming call is acceptable.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 8
FIG. 4-1 Inmarsat-C Channels

NCS COMMON CHANNEL LES TDM


Inmarsat Confidential

Continuous TDM TDM - can be demand assigned


-8.64s Frame, 1200 Symbols/s -8.64s Frame, 1200 Symbols/s
-Scrambled, Encoded, Interleaved. -Scrambled, Encoded, Interleaved.
-1 Bulletin Board/Frame -1 Bulletin Board/Frame
Figure 1: Inmarsat-C Channels

-Inm-C Signalling , EGC & polling -Inm-C Signalling & To-Mobile Messages

MES SIGNALLING CHANNEL MES MESSAGE CHANNEL

Slotted Aloha TDMA


-600 or 1200 Symbols/s -600 or 1200 Symbols/s
-Scrambled, encoded -Scrambled, encoded, interleaved
-Inm-C Signalling, Distress -From-Mobile Messages

Volume 1: System Description, Chapter 4: Protocols for the Message Services


Alerts, Data Reporting

Page: 9
(Version Release CD004, CN141)
C SDM
FIG 4-2 Inmarsat-C Channels & Signals

Note: Data Report,


This Figure does Distress,
not give an exhaustive Polling Status,
list of the Signals Commission & Test Request,
Registration,
Inmarsat Confidential

MES Status, MES Status Request,


Land Earth Station TDM Assignment, TDM Release Ack Network Coordination
Station
Interstation Signalling Channel
Confirmation,
Distress,
EGC,
Polling Request,
Acknowledgement, MES Status,
Acknowledgement Request, MES Status Request, Announcement,
Figure 2: Inmarsat-C Channels & Signals

Acknowledgement, Data Bulletin Board, TDM Release, Bulletin Board,


Announcement Response, Clear, Test Result Confirmation,
Assignment Response, Data Packets,
Distress Alert Ack,
Clear, Distress Alert Ack,
EGC,
Data Reporting, Distress Test Request,
Data Report, Login Ack,
Distress Alert, Forced Clear,
Distress Alert, Logout Ack,
Forced Clear, Logical Channel Assignment,
Initiate Call, Network Update,
Assignment Request, Message Status,
Login Request, Poll,
Request for Transfer Status, Request Status
Logout Request, Request Status

TDM Channel
Test Result
NCS Common Channel

Request for Message Status

Message Channel
Message Status Request
Signalling Channel

Signalling Channel
Test Request

Volume 1: System Description, Chapter 4: Protocols for the Message Services


Mobile Earth Station

Page: 10
(Version Release CD004, CN141)
C SDM
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3 Channel Structure
This section describes the structure of each channel including the mechanisms for scrambling, encoding
and interleaving.

Between certain channels there are pre-determined timing relationships. These are described where
appropriate and are illustrated in Figure 3.

The NCS common channel and LES TDM channels share a common overall structure. Where appropriate,
they will be described together under the heading 'TDM channels'.

Where data is convolutionally encoded, the term 'bit' is used for un-encoded data, and 'symbol' for encoded
data.

Each of the physical channels has a frame structure imposed. The frame structure is described in Section
3.1 which follows. Within the frame structure there is sometimes a packet structure, which is described in
Section 3.2. All channels enforce the size of frames and packets to be an integral number of bytes.

Bits within a byte are numbered from 1 (least significant) to 8 (most significant). Bits within a byte are
transmitted in sequence from bit 1 to bit 8. Fields of more than 1 byte are transmitted from the most
significant byte to the least significant.

3.1 Frame Structure


3.1.1 TDM Channels
The TDM channels are based on fixed-length frames of 10368 symbols transmitted at 1200 symbols/s
giving a frame time of 8.64s.

Each frame carries a 639 byte information field. The general structure of data within this field, and the way
that this is converted to the 10368 symbol frame is shown in Figures 4 to 9 and described in the following
paragraphs.

The information field contains packets which follow each other consecutively. A packet overlapping a frame
boundary is re-packaged into two 'continued' packets — one finishing the current frame and one in the
following frame.

The first packet in the information field is always the bulletin board packet. This packet is followed by one or
more signalling channel descriptor packets describing the signalling channels associated with the To-Mobile
TDM. The remainder of the TDM frame is available for message and signalling packets. This is illustrated in
Figure 4.

In the event of there being insufficient packets to fill the available space, the remaining bytes of the
information field are set to an idle value of all zero.

Figure 5 depicts the scrambling process. The 639 bytes of the information field (Figure 4) and a flush byte
are applied to the scrambler (used for flushing the convolutional encoder).

The block is considered as being split into 160 groups, each group consisting of four consecutive bytes.
Each group either has all its data bits inverted, or left unaltered depending on whether the output of the
scrambling sequence is 1 or 0 respectively. The sequence is the same for every 640 byte block. A few
values are given in Figure 5 to demonstrate the synchronization with the block. The sequence generator is
shown in Figure 6.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 11
FIG. 4-3 Timing Relationships Between Channels

TDM Frame
TDM Transmit
(8.64s or 10368 TDM symbols)
Inmarsat Confidential

Propagation Delay (~239-277 ms)


TDM Receive "T0 "

Time offset dependent Slot numbers shown below are for


on the number of MES For 1st Generation satellites -
1st Generation satellites
Signalling Channels T = 740 TDM Symbol Periods
(Volume 3: Earth Station T
Signalling For 2nd Generation satellites -
Requirements) 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Channel Transmit T = 370 TDM Symbol Periods
(MES Transmits in one slot only) "T "
k
10360 TDM Symbol Periods
Message
Channel Transmit 1 2 3 4
Figure 3: Timing Relationships Between Channels

(MES Transmits whole of message) Example start of message


transmission at Slot number 5

Nominal Propagation
Signalling Delay (236.67 mS)
Channel Reception "T1 "
(MES Transmits in one slot only)
1 2 3 4 5 6 7 8 9 10 11 12 13 14

Volume 1: System Description, Chapter 4: Protocols for the Message Services


10360 TDM Symbol Periods

Message 1 2 3 4
Channel Reception Example start of message
(MES Transmits whole of message) transmission at Slot number 5

Page: 12
TDM Transmit
(Version Release CD004, CN141)
C SDM

of 640 x 8 x 2 = 10240 symbols pass from the encoder to the interleave matrix. The start state of the
640. The bit stream is then passed through a half-rate convolutional encoder as shown in Figure 7. A total
The scrambled block data is converted to a serial bit-stream. Considering Figure 5, bits are serialized
starting at bit 1 through to bit 8 of byte 1, bit 1 to bit 8 of byte 2, and so on with the last bit being bit 8 of byte
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

encoder is identical to that shown for the signalling channel in Figure 14. In the last two states, the encoder
contains all zeros.

The interleave matrix is shown in Figure 8 and the first two columns are identical and permanently contain
two unique word patterns as shown.

The unique word pattern at this stage (prior to permuting) is:

(i = 0) 0111 1011 1010 1001


0110 1001 0001 0111
0011 0010 1110 1001
1011 1000 1000 1000 (i = 63)

Expressed in hexadecimal: 7BA9 6917 32E9 B888

The remaining 160 columns contain the 10240 symbols from the encoder starting at column number 2 and
continuing through the columns sequentially. In Figure 8, "F", "S" and "L" refer to the position of the first,
second, and last symbols from the encoder.

After assembly, the interleave block is transmitted on a row by row basis. The symbols in a row are
transmitted in ascending order of column positions; that is, the two identical unique word symbols are
transmitted first.

However, rows are not transmitted in a sequential order; they are transmitted according to a permuted
sequence as follows:

if the rows in the interleave block are numbered from i = 0 to i = 63 sequentially as shown and the
transmitted order is from j = 0 sequentially through to j = 63;

then i and j are related by either of two equivalent expressions:

i = (j * 39) modulo 64 (suitable at Transmitter);

or j = (i * 23) modulo 64 (suitable at Receiver).

This process is illustrated in Figure 9.

After permuting, the unique word sequence will become:

(j = 0) 0000 0111 1110 1010


1100 1101 1101 1010
0100 1110 0010 1111
0010 1000 1100 0010 (j = 63)

Expressed in hexadecimal: 07EA CDDA 4E2F 28C2

Since it is assumed that unique word detection will be performed prior to de-permuting, the above sequence
is recommended for synchronization at the receiver.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 13
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 4: TDM Frame Information Field

FIG. 4-4
TDM Frame Information Field

Bit No
8 7 6 5 4 3 2 1
1

Bulletin
Board
Packet

Signalling Channel
Descriptor Packet

Signalling Channel
Descriptor Packet

Continued Packet B
containing remainder of
an overlapping packet

Example packet
starting and
completing in this
information field

Idle
Idle

Spare Capacity filled with


"idle" characters

Idle 639

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 14
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5: TDM Scambling Process

FIG. 4-5
TDM Scrambling Process

Bit No
Byte Group Pseudo-random
8 7 6 5 4 3 2 1
Sequence
1
2
0 0
3
4
5
6
1 0
7
8
9

2 0

3 0
4 0
5 0
Information Field
6 0
+
7 1
1 Byte to flush
8 0
the convolutional
9 0
encoder
10 0
11 1

. .
. .
. .

153 1
154 0
155 0
156 1
157 1
158 1

637
638
159 0
639
Flush = 0 640

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 15
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 6: Scrambling Generator

Scrambling Generator

Output
LSB MSB

Initialise: Sets LSB to 1, remainder to 0


Clock shifts register one place right

Figure 7: Encoder

Encoder
G(1)=(1011011)
G(2)=(1111001)

G(1)
Output

Formatted Coded Symbols


data (to interleaver)
1 D D2 D3 D4 D5 D6

G(2)

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 16
FIG. 4-8 Interleave Matrix

Columns

0
1
2
161
Inmarsat Confidential

0 F row i=0

1 S row i=1
Figure 8: Interleave Matrix

i Columns 2 through 161 = symbols from encoder

Row
Unique Word

Unique Word
61
62
row i=63 L
63

Volume 1: System Description, Chapter 4: Protocols for the Message Services


Key:
F, S, L = Firt, second and
last symbol from encoder

Page: 17
(Version Release CD004, CN141)
C SDM
FIG. 4-9 Forward Link Serial TDM Transmission

64x162 Symbols @ 1200 Symbols/s


8.64 s
Inmarsat Confidential

j 0 1 2 62 63 0

row i=0 Row i=0


Previous Frame row i=39 row i=14 row i=50 row i=25
Next Frame

0 0 160 symbols from row i=14

2 UW symbols (0 for i=14)


Figure 9: Forward Link Serial TDM Transmission

Notes:
1. j is the order in which rows are transmitted

2. i is the order of rows in the interleave matrix

3. Transmission at symbol level occurs left to right

4. Frame start time reference is always leading edge first of first unique

Volume 1: System Description, Chapter 4: Protocols for the Message Services


word symbol of row i=j=0

5. Expressions j = (i x 23) modulo 64 or i = (j x 39) modulo 64 are equivalent

Page: 18
(Version Release CD004, CN141)
C SDM
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.1.2 Message Channel


The MES message channel is very similar to the TDM channel and in many cases reference will be made
to this channel. The essential differences are as follows:

- the message channel is quasi-continuous and therefore a preamble is added to aid acquisition;

- the frame length is variable between messages;

- the transmission rate is either 1200 symbols/sec or 600 symbols/sec and this is selected according
to the particular satellite transponder in use.

Parameter 'N' is used throughout this document to define the message block size which also determines
the transmission frame size in symbols according to:

Transmission frame length = 128 + 2048 x (N+1) symbols.

where N = 0 to 4.

Each frame transports (N+1) MES message packets which are 127 byte fixed length packets. Figure 10
shows how the (N+1) packets are arranged in a block prior to conversion into a frame of symbols for
transmission. Each packet has a zero byte added which provide 8 flush bits. The block length is therefore
(N+1) x 128 bytes and always ends in a flush byte.

The block is then scrambled, and if N=4, the process is exactly as in Figure 5. If N is less than 4, the
scrambling sequence terminates earlier than shown. After scrambling, the final flush byte must be reset to
zero if necessary.

The process of encoding and placing symbols in the interleave block is exactly as described in
Section 3.1.1 and Figures 7 and 8 for the TDM channels. This includes the content and placing of the
unique word. For values of N less than 4, the number of columns in the matrix will be less, and according to
the following:

No. of columns in interleave matrix = 34 + N * 32.

Rows are transmitted in a permuted order in the identical manner to the TDM and this is shown in Figure 11
which shows the overall serial transmission and format for a full message.

Empty packets or the empty part of the last frame should be filled with zero (null) bytes.

3.1.3 Signalling Channel


The signalling channel is based on the frame length of 8.64 seconds (that is, the TDM channel frame
length). Each frame is divided into 14 slots for first generation satellites, and 28 slots for second generation
satellites. The transmission rate for a burst within a slot is 600 symbols/s for first generation satellites and
1200 symbols/s for second generation satellites. This slot structure is shown in Figure 12.

The timing of an MES transmission in a slot is taken from the received To-Mobile TDM channel. The
requirements for MES transmission timing are given in Volume 3, Part 2.

Slots are accessed by an MES using a hybrid slotted ALOHA/reservation system. Slot bursts consist of a
unique word and data as shown in Figure 12. The unique word is the same as that for the TDM (after
permuting) and is shown in Section 3.1.1.

The way in which the 252 data symbols which follow the unique word are generated from a single signalling
channel packet is described in the following paragraphs.

Figure 13 shows a signalling packet which is always a fixed length of 15 bytes. Where the information
length is shorter than 15 bytes, the packet is padded-out to 15 bytes with all zeros.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 19
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Each packet is scrambled on a bit-by-bit basis according to the template shown in Figure 13. The sequence
in the template is derived from the scrambling generator in Figure 6. However, it is more straightforward to
define the scrambling in terms of a hexadecimal list as shown in Figure 13.

Serialisation of the scrambled packet is performed starting at bit 1/byte 1 to bit 8/byte 1 and through to bit
8/byte 15. This serial sequence is passed through the convolutional encoder of Figure 7 to generate the
symbol stream which follows the unique word. Six zero flush bits are added and therefore the encoder
start/finish status are as shown in Figure 14.

3.1.4 NCS – LES and NCS – NCS Interstation Signalling Channels


These signalling channels, the Interstation Signalling Links, use the link layer protocol of CCITT
Recommendation X.25.

There is a separate dedicated satellite channel between each LES and its associated NCS. Each is a 1200
bits/second channel with no scrambling, encoding or interleaving. The full specification is given in Volume
3: Earth Station Requirements.

Any NCS can communicate with any other NCS. The links are described in Volume 3: Earth Station
Requirements, Part 4.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 20
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 10: Message Channel Frame Information Field Format

FIG. 4-10 Message Channel


Frame Information Field Format

Bit No

8 7 6 5 4 3 2 1

Fixed Length 1
MES Message Packet
as Detailed in Message Packet
Volume 4 No. 1

127
0 128 End for N=0

Checksum
Message Packet
Byte
No. 2

0 256 End for N=1

Message Packet
No. 3

0 384 End for N=2

Message Packet
No. 4

0 512 End for N=3

Message Packet
No. 5

0 640 End for N=4

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 21
FIG. 4-11 Message Channel; Serial Data Format

Pre-amble 1st Frame Last Frame


Inmarsat Confidential

128 + 2048 x (N + 1)
Frame Length (s) = G x 600 j=62 j=63
Carrier Recovery Clock Recovery j=0 j=1

All '1's 0101....0101 Row i=0 Row i=39 Row i=50 Row i=25

128 64
Symbols Symbols
Figure 11: Message Channel Serial Data Format

0 0 (N + 1) x 32 row symbols

2 UW symbols
Note 1: Definitions of i,j as in Figure
3-9

Volume 1: System Description, Chapter 4: Protocols for the Message Services


Note 2: G=1 for 1st Generation
G=2 for 2nd Generation

Page: 22
(Version Release CD004, CN141)
C SDM
FIG. 4-12 Signalling Channel Frame Format
10368 TDM Symbol Periods

10360 TDM Symbol Periods


8 TDM Symbol Periods
( = 6.666 mS)
2 3 13 14
Inmarsat Confidential

1 ... K ... First Generation


600 Symbols per Second

UW Convolutionally Encoded Data


(64 Symbols) (252 Symbols)
632 TDM Symbol Periods

740 TDM Symbol Periods


Figure 12: Signalling Channel Frame Format

8640 ms
8633.3 ms
8 TDM Symbol Periods
( = 6.666 mS)
1 2 3 4 K 27 28

Second Generation
1200 Symbols per Second

Volume 1: System Description, Chapter 4: Protocols for the Message Services


UW Convolutionally Encoded Data
(64 Symbols) (252 Symbols)
316 TDM Symbol Periods

Page: 23
370 TDM Symbol Periods
(Version Release CD004, CN141)
C SDM
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 13: Signalling Packet Scrambling Process

FIG. 4-13 Signalling Packet


Scrambling Process

Scrambling Template
Bit No Bit No in Hexadecimal
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 List Form
1 1 0 0 0 0 0 0 0 1 80
2 0 0 1 1 1 0 0 0 2 38
3 3 D2
4 4 81
5 5 49
Signalling Packet 6 Scrambling Template 6 76
Byte

Byte
7 7 82
8 8 DA
9 9 9A
10 10 86
11 11 6F
12 12 AF
13 13 8B
14 14 B0
15 1 1 1 1 0 0 0 1 15 F1

Scrambling Process:
Perform EXCLUSIVE-OR function of Bytes 1-15 in
signalling packet using bytes 1-15 in Hexadecimal list
respectively.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 24
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 14: Signalling Channel Encoder Start & Finish States

FIG. 4-14 Signalling Channel


Encoder Start & Finish States

1) Start State

1 D D2 D6
F 0 0 0 0 0 0

State of convolutional encoder for


transmission of first two symbols after unique
word. F = First Bit = Byte 1, Bit 1 Signalling Packet

2) Finish State
2
1 D D D6
0 0 0 0 0 0 L

State of encoder for last two symbols


of burst
L = Last Byte
= Byte 15, Bit 8
Signalling Packet

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 25
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.2 Packet Structure


3.2.1 TDM Channels
A common set of packet formats is used for both the NCS common channel and the LES TDM channel so
that a common synchronization and decoding technique can be used for all packets on these channels.
This packet structure is defined in Volume 4 and illustrated in Figure 15 in this chapter.

The length of a packet is given explicitly to aid:

(a) synchronization procedures which can be made to be more independent of the higher level
information data within the packet; and

(b) future service enhancements requiring new packet types. They can be introduced at a later date
since the length can be deduced by the receiver even though further decoding cannot be performed.

3.2.2 Signalling Channel


There is only one format for signalling channel packets. This is given in Volume 4, Chapter 4, Section 1.

The total length of a packet is fixed at 120 bits by the frame and slot structure of the channel. Volume 4,
Chapter 4 gives details of the formats for each packet type.

3.2.3 Message Channel


There is only one format for message channel packets. This is given in Volume 4, Chapter 5. All packets
are the same length with the first packet of a message containing any necessary control information.

3.2.4 NCS – LES and LES – NCS Interstation Signalling Links


The packet formats for these channels are given in Volume 4, Chapter 6. One packet per frame is sent in
the information field.

3.2.5 NCS – NCS Channel


Individual packet descriptions are given in Volume 4, Chapter 7.

3.2.6 Coding of Information Transmitted over the Satellite Link


3.2.6.1 Mandatory Store and Forward Telex and EGC
SM
For the transfer of store and forward telex and EGC messages SafetyNET over the satellite channel,
LESs and MESs shall use International Alphabet number 5 (IA5). The version to be used shall be the
International Reference Version (IRV) defined in CCITT Red Book Recommendation T50. IA5 characters
shall be coded using odd parity.

3.2.6.2 Other Optional Coding

A presentation field is provided in the relevant call set-up packets, which allows for the options of character
coding in International Telex Alphabet 2 (ITA2) or for the transmission of data without any defined coding.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 26
FIG. 4-15 TDM and ISL Packet Structures

Bits
8 7 6 5 4 3 2 1
Inmarsat Confidential

Bits 1 1 Type
8 7 6 5 4 3 2 1
Bits Length
1 0 Type
8 7 6 5 4 3 2 1 Length
0 Type Length
Figure 15: TDM and ISL Packet Structures

Information Information Information

Checksum 1 Checksum 1 Checksum 1

2 2 2

Short Packet Structure Medium Packet Structure Large Packet Structure

Volume 1: System Description, Chapter 4: Protocols for the Message Services


Page: 27
(Version Release CD004, CN141)
C SDM
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

4 Channel Access
This section describes the method of accessing each channel and the types of information transfer
that are possible.

4.1 NCS Common Channel


This channel is permanently assigned to the NCS in an ocean region. Access to the channel is on a
priority basis, with a first-come-first-served system for packets of the same priority.

The three priority levels and the packets types associated with each level are:

(i) Inmarsat-C call announcement, polling, EGC distress priority messages, distress alert
acknowledgement;

(ii) Inmarsat-C signalling; and

(iii) other EGC messages.

An NCS may transmit more than one NCS common channel. Inmarsat-C Signalling traffic will be
shared between these channels. Where spot beams are operating, at least one NCS common
channel will be transmitted in each spot beam.

4.2 TDM Channel


This channel is assigned to an LES. Access to the channel is on a priority basis, with a first-come-
first-served system for packets at the same priority.

With the highest priority level given first, the priority levels are (see Vol.3, Pt 1, Chapter 3, for details):

(i) distress priority packets;

(ii) logical channel assignments;

(iii) other protocol packets; and

(iv) messages.

4.3 Signalling Channels


One or more of the return link frequencies associated with each TDM channel and with the NCS
common channel will be assigned as a signalling channel. It is organized so as to allow random
access operation. The access protocol employed is a hybrid of slotted ALOHA and explicit
reservations. Slotting and the reservation techniques are employed to enhance the throughput
capability of the channel.

Because the MESs cannot monitor their own transmission through the spacecraft, collision detection
is performed at the NCS or LES. The result of the MES transmission as seen by the NCS or LES is
returned to the MES on the TDM forming the basis of the re-transmission process.

Where the data in a transmission on the signalling channel is too large to fit into a single packet, a
succession of connected packets is sent; this is referred to as a packet sequence.

There are two types of access to the signalling channel: reserved and unreserved. These terms refer
to the way in which the MES gains access to the channel for the first packet in what may be a packet
sequence; access for subsequent packets is always guarantied. For reserved access the slot that is
to be used by the MES is pre-allocated by the LES or NCS. For unreserved access the slotted
ALOHA system is used.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 28
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

4.3.1 Multislots and Slot States


A particular slot within a frame is designated as being a '2-frame' slot or a '3-frame' slot. An MES
transmitting in a 2-frame slot may only transmit every two frames. Likewise, for a 3-frame slot, an
MES may only transmit every three frames. Referring to Figure 16 (2-frame slot timing) and Figure 17
(3-frame slot timing), it can be seen that propagation, decoding and processing delays enforce this
regime. The MES will observe the result of the previous packet before transmitting the next packet.

The boundary at which slots change from being 2-frame to being 3-frame is controlled by the NCS or
LES. The boundary may be moved during normal operation if required and is given in the bulletin
board of the associated TDM. (See Section 1.2 in this chapter.)

Since any particular MES is only using one in two or one in three frames, the slots in the same
position in the unused frames may be used by other MESs. This results in a structure where slots in
the same position in succeeding frames contain data from two or three MESs which are totally
independent from each other in the form K1, K2, K1, K2... (for a 2-frame slot) or K1, K2, K3, K1, K2,
K3... (for a 3-frame slot). Each independent slot position Ki is referred to below as a 'multislot'.

The signalling channel descriptor packet (Figure 18), transmitted in every frame on a TDM contains a
'slot state marker' for each signalling channel slot. This slot state marker contains two flags to
indicate:

(a) whether a transmission from an MES in the previous multislot had been detected and
successfully decoded, or not; and

(b) whether the current slot is reserved or unreserved.

4.3.2 Unreserved Access


To transmit data on the signalling channel in the unreserved mode, the MES will select one slot from
those slots marked unreserved in the successfully decoded signalling channel descriptor packets.
This selection will be made randomly and the data transmitted in the chosen slot. If the data being
transmitted is too long to fit into a single slot, a packet sequence is indicated by means of a
continuation marker. The frame chosen for the transmission of the first packet of the data determines
the multislot for this data burst.

If the LES detects an error in the slot, the slot state marker in the appropriate signalling channel
descriptor packet is set to indicate that no packet was successfully received.

Where the packet is successfully received, the marker will be changed to reflect this. If the
continuation marker was set in the packet, then the slot state marker will indicate that this slot is also
reserved allowing the MES to continue transmitting its packet sequence.

In the case of an error, the action taken depends upon whether the previous marker had been
'reserved' or not. In the reserved case, the MES will retransmit the same data in the next slot in the
same multislot. In the unreserved case, the MES must retransmit the packet in an available slot
randomly chosen in one of the next X frames. The parameter X, called the randomizing interval, is
contained in the bulletin board so that the LES can adapt the protocol to the traffic load. The
exceptions are for distress alerts and requests with distress priority, where the MES is able to re-
randomize and retransmit the same data immediately in the following frame.

If a desired signalling channel descriptor packet is received in error, the action taken by the MES will
depend upon whether it still has continuation packets to send. If it has no more packets to send, it
should assume that the last packet was correctly received. If it still has continuation packets to send,
its action will depend upon whether it has already seen a reserved marker for a previous continuation
packet. If it has already seen a previous 'reserved' marker, the MES should assume that the marker is
set for it and should transmit the next packet. If it has not seen a previous 'reserved' marker, it should
abandon the transmission and restart the randomising process.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 29
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

If an MES sees a 'reserved' or 'unreserved' marker where the other is expected, it must assume that
its transmission was hidden by a more powerful station and must restart the randomizing process.

Parameters are specified in Section 1.2 of this chapter.

4.3.3 Reserved Access


During the protocol exchanges, there are times when an LES will send a packet to an MES and
expect a response. In order to avoid the delays and uncertainty of unreserved access the LES will use
the reserved access mechanism to the signalling channel. To do this the ground-based station must
do two things: select an unused multislot and reserve it, and then inform the MES of the multislot
which is to be used.

A multislot must not currently be in use for transfer (that is, it is in the 'unreserved' state).

The unused multislot is set to the 'reserved' state in the bulletin board. This must be done at least one
multislot frame before the expected transmission by the MES in order to avoid collisions. The LES
then transmits its packet, which will include the following information:

(i) the frequency for the MES to transmit the response;

(ii) the least significant 8 bits of the absolute frame number in which the transmission is to occur
(the frame offset);

(iii) a flag indicating whether the frame for retransmission is between frames 0 through 4999 or
5000 through 9999;

(iv) the slot number k in which to transmit the response (numbered from 1 upwards).

The frame in which the MES transmits may be evaluated by:

MSB_of_Current_Frame_Number := Current_Frame_Number and 16#FF00#;

LSB_of_Current_Frame_Number := Current_Frame_Number and 16#00FF#;

if (MSB_of_Current_Frame_Number = 16#2700#) and (AM_PM_Bit = Zero) then

Transmit_Frame_Number := Frame_Offset;

elsif LSB_of_Current_Frame_Number < Frame_Offset then

Transmit_Frame_Number := MSB_of_Current_Frame_Number or Frame_Offset;

else Transmit_Frame_Number := (MSB_of_Current_Frame_Number + 16#0100#) or

Frame_Offset;

When the MES receives such a packet, it will use the frame delay and the 2-frame or 3-frame slot
indicator in the bulletin board to establish a multislot. It will wait for the indicated frame and check that
the slot marker is set to 'reserved'. It will then transmit its response.

Use of the continuation marker and recovery action are as for unreserved access (Section 4.3.2)
except that, if a desired signalling channel descriptor packet is received in error, the action taken by
the MES will depend upon whether it still has continuation packets to send. If it has no more packets
to send, it should assume that the last packet was correctly received. If it still has continuation packets
to send, the MES should assume that the marker is set for it and should transmit the next packet.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 30
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

4.4 Message Channels


Access to a message channel is controlled by the LES. When requesting a message transmission
from an MES, the LES will send a signalling packet indicating the frequency and slot number to use.
The slot number is defined in the same way as given for reserved access including the frame offset.

The MES will start transmitting the carrier on the indicated frequency at the appropriate slot time.

4.5 Interstation Signalling Links


The X.25 (1984) LAPB procedures for link access are used. This is fully described in Volume 3: Earth
Station Requirements.

4.5.1 NCS – NCS Communication


A wide area network is established by INMARSAT between NCSs and each NCS and the NOC.
Access to the network is described in Volume 3: Earth Station Requirements.

Communication between NCSs occurs whenever an MES changes its operational state at an NCS.
Changes of MES state are transmitted to the other NCSs to ensure MES database synchronisation.

The links to the NOC are used to transfer MES commissioning data to the NCSs.

4.5.2 NCS – LES Communication


Each LES establishes a permanent satellite Interstation Signalling Link (ISL) with the NCS in its ocean
region. The link details are given in Volume 3: Earth Station Requirements, Part 4, Section 4.2.

These links are used for:

• transfer of announcements and EGC messages from an LES to the NCS;

• signalling between each LES and the NCS to synchronise MES databases;

• the forwarding of distress alerts to LESs by the NCS; and

• the assignment of LES TDM channels.

Access to the channel is on a priority basis, with a first-come first-served system for packets at the
same priority. With the highest priority first, the priority levels are:

(i) distress alert, distress alert acknowledgement, assignment requests for distress priority
messages and SafetyNETSM EGC messages;

(ii) assignment request, MES status + announcement, TDM request, polling;

(iii) other packets except network record;

(iv) network record.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 31
FIG. 4-16 Bulletin Board Propagation for
2-Frame Slots

B 1 B 2 B 3 B 4 B
LES TX
Inmarsat Confidential

Propagation Frame
Delay B = Bulletin Board

B 1 B 2 B 3 B 4 B
MES RX

MES RX B 1 B 2 B 3
(after de-interleaving, decoding,
descrambling - bulletin board Frame Offset
available) (See Volume 3, Part 2, Section 6.2.1)

MES TX X 1 2 3

Propagation,
Decoding & Checking
Figure 16: Bulletin Board Propagation for 2-Frame Slots

Delay

LES RX 1 2 3
X
(After Decoding)

Volume 1: System Description, Chapter 4: Protocols for the Message Services


Note that Slot No. X in Frame 2 Slot State
can be used independently from Information
Slot X in Frame 1

LES TX (REF) B 1 B 2 B 3 B 4 B

Page: 32
(Version Release CD004, CN141)
C SDM
FIG. 4-17 Bulletin Board Propagation for
3-Frame Slots

B 1 B 2 B 3 B 4 B
LES TX
Inmarsat Confidential

Propagation Frame
Delay B = Bulletin Board

B 1 B 2 B 3 B 4 B
MES RX

MES RX B 1 B 2 B 3
(after de-interleaving, decoding,
descrambling - bulletin board
Frame Offset
available)
(See Volume 3, Part 2, Section 6.2.1)
MES TX 1 2 3
X

Propagation,
Decoding & Checking
Figure 17: Bulletin Board Propagation for 3-Frame Slots

Delay

LES RX 1 X 2 3
(After Decoding)

Volume 1: System Description, Chapter 4: Protocols for the Message Services


Note that Slot No. X in Frame 2 and Slot State
3 can be used independently of Information
Slot X in Frame 1.

LES TX (REF) B 1 B 2 B 3 B 4 B

Page: 33
(Version Release CD004, CN141)
C SDM
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 18: TDM Bulletin Board and Signalling Channel Desriptor Formats

FIG. 4-18
TDM Bulletin Board and
Signalling Channel Descriptor Formats

Bit No.
8 7 6 5 4 3 2 1
0 Type Length Packet Descriptor
Network Version

Frame Number

Sig Channels 2-F


Count E Spare
Channel Local Spare
Origin ID
Status

Services

Rnd Interval

Checksum

BULLETIN BOARD

0 Type Length 0 Type Length


A C D S L AE Spare A C D S L AE Spare
Satellite Frequency Satellite Frequency
Code Code
14 x 2 bit
Slot State
Markers
28 x 2 bit
Spare Slot State
Markers
Checksum

Checksum

SIGNALLING CHANNEL SIGNALLING CHANNEL


DESCRIPTOR PACKET DESCRIPTOR PACKET
- 1st GENERATION - 2nd GENERATION

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 34
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

5 Procedures to Establish Connections


This section describes the procedures which are employed in the Inmarsat-C system to establish
connections between an LES and an MES. The procedures differ according to the type of message transfer
involved and therefore separate procedures are described.

5.1 To-Mobile Message Transfer


The establishment of a connection to provide for a To-Mobile call occurs in three stages. The first is a
check at the network level for the presence of the MES in the ocean region before the acceptance of the
terrestrial message. The second is the call announcement to the MES via the NCS. And, the third is the
establishment of the logical channel. The normal procedure is illustrated in Figure 19.

5.1.1 Terrestrial Message Acceptance


The process is initiated when an LES receives a call from the terrestrial network to an Inmarsat-C MES.
The MES ITU number will be checked to see if the MES is authorized to receive calls. The active mobile list
in the LES will be scanned to check that the destination MES is logged into the ocean region.

If the Inmarsat Mobile Number is not in the LES database, the CN131-compliant LES may send a
registration update request to the NCS to get an update of the MES registration information before rejecting
the call request. The LES shall then update its MES database according to the registration packet sent by
the NCS. If the MES was not defined in the NCS database, no response would be sent by the NCS and the
LES should not repeat the request.

Following the initial service check, the LES either provides a proceed indication to the terrestrial circuit, or
produces an MES unavailable indication depending on the state of the MES. The LES then accepts or
rejects the incoming message from the originator and stores it if accepted.

5.1.2 Announcement
After the full message has been received, the LES requests the NCS to announce the call to the MES via
an MES status request + announcement. For To-Mobile store-and-forward message transfers, this signal
includes the logical channel assignment for the eventual message transfer.

On receiving the MES status request + announcement, the NCS initiates a search of the MES status list.
The status of an MES will be:

(a) not in the ocean region, or non-operational (can only occur if the NCS has not yet updated LES);

(b) in the ocean region and idle; or

(c) in the ocean region and busy.

On completion of the search, the NCS sends an MES status packet to the LES giving the status of the MES
(idle, busy or not in ocean region), and whether the NCS was able to initiate the call announcement.

The NCS will initiate the call announcement as soon as possible. However, there are cases where the call
announcement must be delayed: that is, when the MES is busy.

In this case, the call announcement will go into a queue of announcements, and be sent to the MES when it
becomes idle and the LES has a TDM assignment. The LES will be informed via an MES status when the
call announcement is made to the MES.

If the LES requires a TDM channel, the LES requests the TDM channel from the NCS before requesting
that a Call Announcement be made. The NCS responds with a TDM Request Response. If the Response is
positive the LES proceeds with a request to the NCS to make the Call Announcement.

The NCS will initiate the call announcement by means of an announcement on the NCS common channel.
The announcement includes the logical channel assignment given by the LES.

5.1.3 Establishing the Logical Channel

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 35
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Having received the announcement, the MES is aware that a message is waiting, which LES it is waiting at,
and the TDM frequency to which it should tune. The MES then tunes and synchronizes to the given TDM
channel. This enables the MES to receive the LES bulletin board and signalling channel descriptor
packet(s), which it uses to select a slot in one of the signalling channels to transmit an assignment
response to the LES. The response is transmitted in unreserved access mode, as described in
Section 4.3.2.

The reception by the LES of a valid assignment response from the MES indicates that the announcement
was successful and a logical channel is established between the LES and the MES.

The LES sends an MES status to the NCS indicating busy status.

5.1.4 Exception Handling for Logical Channel Establishment


All timeouts and recovery procedures are defined in the SDL diagrams in Volume 5: Inmarsat-C SDL.

5.2 From-Mobile Message Transfer


The establishment of a logical channel to be used for From-Mobile message transfer is undertaken in two
stages. The first is the call request stage where the MES indicates that it wishes to send a message to a
particular LES. In the second stage, the MES and LES establish the logical channel. These stages are
illustrated in Figure 20.

5.2.1 Call Request


Establishment of a logical channel is initiated by an MES when it has completely formatted a message
which includes delivery address information. To initiate the process, the MES tunes to the TDM frequency
for the required LES. This frequency is given in the network configuration (see Section 9, Ocean Region
Registration). After synchronizing with the TDM, the MES sends an assignment request on a signalling
channel associated with the TDM.

If the destination LES is transmitting a permanent TDM channel, then the given TDM frequency will be that
of that TDM. Therefore, the assignment request packet will be transmitted directly to the intended LES.

Alternatively, if the LES is operating in a demand assigned mode, the TDM frequency advised will be that of
the NCS common channel and the assignment request will be received by the NCS. In turn, the NCS will
forward the assignment request to the LES and place the MES on the busy list.

The LES will initiate an announcement sequence, as given in Section 5.1.2 for To-Mobile transfers. The
fields of the MES status request + announcement packet are set to reflect the From-Mobile direction. If the
LES does not have a TDM assignment, or needs a further one, it will issue a TDM Request to the NCS, and
send a Request Status (Pending) message to the MES via the NCS. The NCS forwards the request status
to the MES via the NCS common channel.

When a TDM channel becomes available, the LES requests the NCS to issue a Call Announcement.

If the LES is unable to accept the call immediately, it will send an MES request status to the NCS indicating
that the call is pending. The NCS forwards the request status to the MES via the NCS common channel.
When the LES is in a position to accept the call, it initiates an announcement sequence as described
above.

On receiving the announcement, the MES tunes and synchronizes to the TDM channel given in that packet.
The MES then sends an announcement response to the LES on a signalling channel associated with the
assigned TDM channel.

5.2.2 Establishing the Logical Channel


Upon receipt of a valid assignment request, (or an announcement response in the demand assigned case),
the LES informs the NCS via an MES status packet that it is in communication with the particular MES. This
information allows the NCS to place the MES on the busy list.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 36
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

If the assignment request is received from an MES which is not in the LES database, the CN131-compliant
LES may send a registration update request to the NCS to get an update of the MES registration
information. The LES shall then update its MES database according to the registration packet sent by the
NCS. If the MES was not defined in the NCS database, no response would be sent by the NCS and the
LES should not repeat the request

If the LES can accept the message, it sends a logical channel assignment to the MES.

No specific assignment response from the MES is required. The message transfer itself on the assigned
message channel indicates successful logical channel assignment receipt by the MES. Included in the
assignment is the frequency of the TDM channel to be used by the MES after transmitting its message on
the message channel. It may or may not be the same channel as that used in the initial assignment request
sequence.

If the LES does not serve the required destination or does not provide the required service, it will reply to
the MES's assignment request with a request status indicating the failed status.

If the LES is temporarily unable to service the request (for example, because of congestion) it sends a
request status indicating a pending response to the mobile. The MES will then retune to the NCS common
channel. When the LES becomes able to process the call, it will send an MES status request +
announcement to the NCS, the same as for a To-Mobile message but the direction parameter now
indicates a From-Mobile call. When the MES receives the announcement it will tune to the LES TDM and
retransmit an announcement response. This procedure allows higher priority messages to overtake lower
priority ones, and also reduces the amount of information that the LES has to retain regarding pending
messages.

The MES can cancel a pending From-Mobile call by sending a forced clear to the NCS using unreserved
access.

5.2.3 Exception Handling for Logical Channel Establishment


All timeouts and recovery procedures are defined in the SDL diagrams of Volume 5.

5.3 Mobile to Mobile Message Transfer


Messages can be transferred from mobile to mobile via an LES. This can be considered as a From-Mobile
call followed by a To-Mobile call.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 37
FIG 4-19 To-Mobile Message Transfer

LES NCS MES Notes:


1) Step 4 is omitted if the MES is idle at
Step 2
Inmarsat Confidential

1. <MES Status Request + Announcement> 2) Steps 7-10 are repeated until all message
packets have been correctly received.

2. <MES Status> [MES Tuned to NCS Common Channel]


3. <Announcement>
4. <MES Status (Announcing)> [MES Tunes to TDM channel]

[MES Tunes to Signalling Channel]


5. <Assignment Response> (Unreserved)
Figure 19: To-Mobile Message Transfer

[MES Tunes to TDM channel]


6. <MES Status (busy)>

7. <Message>

8. <Message>
9. <Acknowledgement Request>
[MES Tunes to Signalling Channel]
10. <Acknowledgement> (Reserved)
[MES Tunes to TDM channel]

11. <Clear>

Volume 1: System Description, Chapter 4: Protocols for the Message Services


12. <MES Status (Idle)> [MES Tunes to NCS Common Channel]

Page: 38
(Version Release CD004, CN141)
C SDM
FIG. 4-20 From-Mobile Message Transfer
Sheet 1 of 2

Notes:
CASE 1: LES NCS MES 1) Steps 4-6 are repeated until all message packets
LES can accept message have been correctly received.
Inmarsat Confidential

Immediately

[MES Tunes to LES TDM]

[MES Tunes to Signalling Channel]


1. <Assignment Request> (Unreserved)
[MES Tunes to LES TDM]

2. <MES Status (Busy)>

3. <Logical Assignment>

[MES Tunes to Message Channel]


4. <Message>
Figure 20: From-Mobile Message Transfer, Sheet 1 of 2

5. <Message>

6. <Acknowledgment>
or 7. <Clear> [MES Tunes to LES TDM]

Volume 1: System Description, Chapter 4: Protocols for the Message Services


[MES Tunes to NCS Common Channel]
8. <MES Status(Idle)>

Page: 39
(Version Release CD004, CN141)
C SDM
FIG 4-20 From-Mobile Message Transfer
Sheet 2 of 2

LES NCS MES


CASE 2:
LES cannot accept
Inmarsat Confidential

message immediately.

[MES Tunes to LES TDM]


1. <Assignment Request>

2. <MES Status (Busy)>

3. <Request Pending>

4. <MES Status(Idle)> [MES Tunes to NCS Common Channel]


Figure 20: From-Mobile Message Transfer, Sheet 2 of 2

5. <Announcement Request>

6. <Announcement>
7. <MES Status> [MES Tunes to LES TDM]

Volume 1: System Description, Chapter 4: Protocols for the Message Services


8. <Announcement Response>

9. Go to Fig 4-20
Sheet 1, Step 2

Page: 40
(Version Release CD004, CN141)
C SDM
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

6 Message Transfer Procedures


After the establishment of the logical connection, message transfer takes place. The technique for the
message transfer is the same for both forward and return channels. The procedures differ slightly in their
access control methods and are therefore described separately.

6.1 To-Mobile Message Transfer


The To-Mobile message transfer procedure starts with logical channel establishment as described in
Section 5.1. The receipt of the assignment response from the MES indicates that message transfer can
begin on the TDM channel. The messages are divided into packets so as to facilitate the use of ARQ and to
allow the transmission of signalling packets together with packets from on-going message transfers. Each
message packet contains the logical channel number and a sequence number within the message as well
as the message data.

After all of the packets have been transferred, the LES transmits a request for acknowledgement to the
MES which includes the slot to use for the acknowledgement. The LES reserves a random access slot in
the signalling channel descriptor packet as soon as possible for the MES to use for the acknowledgement.

The MES responds with an acknowledgement on the signalling channel. The acknowledgement packet
contains a list of any packets that were missed or received in error. Packets are protected by a checksum
which reveals transmission errors. Packets are also sequentially numbered to allow the identification of any
packets that may be lost.

Reception of the acknowledgement at the LES causes the LES to retransmit any packets received in error
followed by another request for acknowledgement. In the retransmission process, the MES knows how
many and which packets it has requested for retransmission. Thus receipt of a second request for
acknowledgement before recovering all requested packets will cause another retransmission request.

If the acknowledgement indicates that all packets have been received correctly, the LES may either indicate
that another To-Mobile message is ready by means of a logical channel assignment with the same logical
channel number, or will begin the call clearing process. The MES may regard the logical channel
assignment as an implicit clear for the last call.

In the case of another To-Mobile message, the MES responds to the logical channel assignment with an
assignment response using reserved access on the signalling channel.

All timeouts and recovery procedures are defined in the SDL diagrams given in Volume 5.

6.2 From-Mobile Message Transfer


From-Mobile message transfer begins with the reception of a logical channel assignment packet. Once the
logical channel is established, the MES transmits the agreed number of packets sequentially on the
assigned message channel and starting at the indicated slot time.

Upon completion of the agreed number of packets, the LES transmits an acknowledgement. If errors have
occurred, the acknowledgement indicates which frequency to use and which packets to retransmit.
Alternatively the LES may transmit the logical channel assignment in place of the acknowledgement. In this
case the MES will retransmit the entire message. This procedure is used to improve the throughput if a high
percentage of packets are received in error.

When all packets have been successfully received at the LES, it will initiate the call clearing procedure.

An example assignment request packet and associated message packet for the mandatory store-and-
forward telex service is given in Figure 21.

All timeouts and recovery procedures are defined in the SDL diagrams given in Volume 5.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 41
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

6.3 Mobile-to-Mobile Message Transfer


Messages can be transferred from mobile-to-mobile via an LES. This can be considered as a From-Mobile
call followed by a To-Mobile call.

6.4 Maritime Distress Alerting


The information to be transmitted by a maritime MES in the event of a distress alert, is either entered
automatically, or manually by the operator. Included in this information is the identity of the LES which is to
be the recipient of a distress alert.

For an MES which is logged into an ocean region, the distress alert is transmitted on a signalling channel
associated with the TDM channel given in the network configuration. Where the required LES is operating
with a permanent TDM, the distress alert is transmitted directly to the LES. The LES responds by sending a
distress alert acknowledgement on the TDM. In addition, the LES will repeat the distress alert packet for
logging purposes to the NCS. The NCS shall respond with a distress alert acknowledgement on receipt of
the distress alert.

If the LES is operating in the demand assigned mode, the TDM given in the network configuration for that
LES will be that of the NCS common channel. Therefore the distress alert is transmitted to the NCS. In this
case, the NCS will acknowledge by sending a distress alert acknowledgement to the MES on the NCS
common channel. The NCS will forward the distress alert to the addressed LES on the interstation
signalling link and the LES shall acknowledge receipt by sending a Distress Alert Acknowledgement to the
NCS. The NCS will log the distress in its database.

The distress alert will be retried a number of times. If the MES cannot synchronise with the desired LES or
fails to receive a distress alert acknowledgement, it will retry try to re-send the distress alert to the NCS in
the same ocean region as the LES. If the MES fails to receive a Distress Alert acknowledgement from the
NCS, the operator will be advised the MES will scan and attempt to synchronise to an NCS in another
ocean region. The MES will make a number of attempts to send the distress alert before abandoning the
call and informing the MES operator.

An MES which is not logged into a region will transmit its distress alert to the NCS as for the demand
assigned TDM case. The NCS forwards the alert as described above. In addition, the NCS will enforce a
login for the MES sending the distress alert. This ensures that subsequent search and rescue co-ordination
communications may be handled between an LES and an MES using the normal protocols.

If the MES is engaged in a message transfer, activation of the distress alert mode by the MES operator
shall result in the call being abandoned and the transmission of the distress alert.

All Distress Alerts shall be transmitted at Distress Priority. Distress calls are always routed to the associated
Rescue Coordination Centre (RCC)1 only.

1 LES operators receiving a distress message are obliged under the Radio Regulations, Article 39,
paragraph 3149 and Article N39, paragraph N 3129 to take the necessary action to advise the appropriate
authorities responsible for providing for the operation of rescue facilities, without delay.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 42
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 21: Example for From-Mobile Message Transfer, Sheet 1 of 2

FIG. 4-21 Example for From-Mobile


Message Transfer, Sheet 1 of 2

Bit No.
8 7 6 5 4 3 2 1

1 0 0 10H Store-and-Forward (message)


2
3 MES ID
4
5 LES ID
6 1 Number of message packets
7 0 0 4
Byte

8 '7' Telex Network Identification Code


9 '7' using IA5 (example is Solomon Islands)
10 '8'
11
12 Unused
(set to zero)
13
14
Checksum
15

Assignment Request

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 43
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 21: Example for From-Mobile Message Transfer, Sheet 2 of 2

FIG. 4-21 Example for From-Mobile


Message Transfer, Sheet 2 of 2
Bit No.
8 7 6 5 4 3 2 1

1
1
0 0 4
2

Byte
Logical Channel Number
Presentation Control 3
0
(IA5)
21 4
'7'
'7'
'8'
'4'
Address '6'
Line '2'
'5'
'0'
'0'
'0'
'+'
Start of Text 'STX'

'C'
'O'
'M'
Message 'E'
Input ''
'H'
'O'
'M'
'E'

Not used
(set to zero)

Checksum
127

Message Packet

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 44
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

7 Procedures to Clear Connections


Once the message transfer on the logical channel has been completed, the channel must be cleared and
the MES returned to the idle state. These procedures also involve the NCS.

7.1 Normal Clearing


7.1.1 Land Earth Station Clearing
When an LES wishes to clear a logical channel at the end of a message transfer, it transmits a clear packet.

Upon successful reception of the clear, the MES tunes back to the NCS common channel for which it is
registered.

After transmitting the clear, and after a timeout, the LES sends an MES status to the NCS indicating that
the MES has returned to the idle state. If at a later point the LES receives a request for transfer status from
the MES, it retransmits the clear and sends the NCS an MES status indicating that the MES is busy.

For From-Mobile transfers, the message reference number is contained in the clear packet and can be
used later for message confirmation purposes.

7.1.2 Mobile Earth Station Clearing


When an MES wishes to clear a logical channel, it transmits a clear on the signalling channel.

Upon receipt of this packet, the LES responds with a clear and the normal clearing procedure continues.
The message reference number may be used by the MES for confirmation purposes.

If the MES does not receive the clear within a specified timeout period it will retransmit the clear up to a
specified number of times before retuning to the NCS common channel.

For the mandatory services, the MES does not use its ability to initiate a logical channel clearing sequence
and it is always the LES which clears the channel. In exceptional circumstances, the MES can initiate a
forced clear sequence.

7.2 Forced Clearing


At any time during a connection either an MES or an LES may clear using the forced clear procedure. This
may occur, for example, if a serious protocol error or an unrecoverable hardware error is detected.

7.2.1 Land Earth Station Forced Clearing


The LES may send a forced clear on its TDM channel at any time that the MES may be listening.

On receipt of this packet the MES must stop its activity and retune to the NCS common channel.

7.2.2 Mobile Earth Station Forced Clearing


The MES sends an MES forced clear to the LES on the signalling channel using unreserved access.

On receipt of this packet the LES responds with a forced clear.

If the MES does not receive this packet within a specified timeout period, it will retransmit the MES forced
clear up to a specified number of times before retuning to the NCS common channel.

In demand assigned operation, an MES may abort a message transfer before being directed to the LES.
The assignment request will have been received by the NCS and transferred to the LES.

The MES may send an MES forced clear to the NCS before reception of the announcement. The NCS
sends the forced clear to the appropriate LES using the interstation signalling link. The LES acknowledges
by returning the packet to the NCS which, in turn, transmits a forced clear on the NCS common channel. In

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 45
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

addition, the LES sends an MES status to the NCS indicating that the MES is now idle. In this situation, a
logical channel has not been established and logical channel number zero should be used by the MES and
LES.

If the announcement has been received by the MES, it must tune to the given TDM channel and initiate the
forced clear procedures given at the beginning of this section.

7.3 Land Earth Station TDM Release


If an LES is operating with demand assigned TDMs, it is necessary for that LES to be able to release its
assignment to the pool of assignments held by the NCS. The assignment includes the TDM frequency
allocation plus the accompanying allocation of signalling and message channels.

When the LES has completed all message transfers that it has queued before and during its transmission of
a TDM, or when the reservation period has expired, it will release the assignment by sending a TDM
release packet to the NCS. The NCS will acknowledge the release of the TDM with a TDM release
acknowledgement. The LES will cease transmission of the TDM before or at the time of sending the TDM
release to the NCS. (See Section 1.2 in this chapter.)

Under abnormal conditions, it is also possible for the NCS to request an LES to release a TDM. The NCS
will send a TDM release request to the LES and when the TDM is released, the LES will respond with a
TDM release acknowledgement.

8 Procedures for Message Delivery Confirmation


The originator of a message may request confirmation of its delivery to the destination.

8.1 To-Mobile Messages


In the case of a To-Mobile message, if the terrestrial originator of the message has requested delivery
confirmation, the LES may do so at any time, following the final acknowledgement from the MES.

8.2 From-Mobile Messages


An MES may, in the initial control information used when setting up the message address parameters,
request delivery confirmation from the LES. The LES will send a delivery confirmation to the NCS after the
message has been delivered to the terrestrial destination or if it finds that it cannot deliver the message.
This confirmation will be forwarded to the MES via the NCS common channel, when the particular MES is
idle. If the NCS receives an indication that an MES has begun logical channel establishment within a
specified time after it has transmitted the confirmation, the confirmation will be retransmitted when the MES
returns to the idle state.

In addition, an MES may originate this procedure up to a specified time after receiving the clear from the
LES. It does so by sending a message status request to the appropriate LES using unreserved access on a
signalling channel.

The LES responds to this with a message status packet, which is sent via the NCS and forwarded to the
MES on the Common Channel.

In the case that the required LES is operating in the demand assigned mode, the MES will send the
message status request packet to the NCS using one of the associated signalling channels. The NCS
passes the message status request onto the LES which was indicated in the packet via the interstation link.

No recovery procedures are provided; if no response is received it is the MES's responsibility to request the
status again.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 46
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

9 Procedures for Ocean Region Registration


In order for the network to operate efficiently, it is necessary for mobiles operating within an ocean region to
be logged in.

A procedure for direct logging in to an ocean region by each MES is adopted. This allows immediate
updating of the LES's active mobile lists via the interstation signalling links.

9.1 Logging In
Initially an MES must synchronize with an NCS common channel. After establishing synchronization, the
MES transmits a login request using unreserved access to the NCS.

Included in the login information sent to the NCS is the network version number. This represents the
version of the network configuration known by the MES. The network configuration is a list of LESs with
their TDM frequencies and the services they offer for a particular ocean region. When an MES initially logs
in to another NCS (either a spot beam or another ocean region), it will not have any configuration
information. Therefore, the version number sent is zero, to indicate to the NCS that the MES requires the
ocean or spot beam region's network configuration.

The NCS replies to a login request with a login acknowledgement. In the case where the network version
number sent by the MES does not agree with the current network configuration version held at the NCS, the
login acknowledgement packet will include all the network configuration information.

A NCS common channel frequency is included in the login acknowledgement and may be used by the NCS
to force MESs to use an alternative NCS common channel. If the frequency given is different to that of the
NCS common channel just used in the login sequence, the MES will retune to the new NCS common
channel and resynchronize. The MES will then attempt to login using a signalling channel associated with
the new NCS common channel.

If the MES does not receive the login acknowledgement packet within a specific timeout period, it will
retransmit the login request.

The NCS will inform the LESs in its region of the login by sending a registration to each LES. The
registration packet contains a copy of the MES's entry in the NCS's mobile list. The LES uses the contents
of this packet to update its active mobiles list. The NCS will also inform the other NCSs by means of the
MES status update procedures as given in Section 11.1.

9.2 Logging Out


If an MES wishes to logout from an ocean region without logging in to another one, it may do so by sending
a logout request in the same way as the logging-in procedure. The NCS replies with a logout
acknowledgement on the NCS common channel.

The same timeouts and actions as for logging in apply except that the NCS will send a Registration to the
LESs in the region indicating that the MES is not in the ocean region. On receipt of this packet, the LES will
remove the MES from its active mobile list.

The current NCS parameter will be empty if the MES has explicitly logged out. However, if the MES has
logged in to a different region, the associated NCS will notify the other NCSs which will in turn send an MES
status giving the NCS identity for the new region to their LESs.

9.3 Network Updates


Each MES keeps a record of the network configuration given to it at log in time. This information includes
the LESs operating in the region together with their status and LES TDM frequency or frequencies. A
particular network configuration is identified by an accompanying version number.

The network configuration version number is repeated in each bulletin board on the NCS common channel.
When an MES is tuned to the NCS common channel, it will check that its internal record matches that given
in the bulletin board. In the event that the two numbers are not equal, and a Network Update is not received

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 47
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

within a pre-defined time, the MES will initiate a log-in sequence (see Volume 3: Earth Station
Requirements, Part 2, Chapter 2, Section 6.5.1).

Whenever there is a change to a region's network configuration, the NCS will change the associated
version number and broadcast a Network Update on the NCS common channel.

Any MES logged in and receiving this packet will update its internal record of the network configuration. The
NCS will repeat the broadcast at regular intervals.

9.4 Spot Beams


In a region with spot beams, an NCS common channel will be transmitted in each spot beam. An MES logs
in by transmitting a login request on a signalling channel associated with a particular spot. Therefore, the
NCS is able to determine which spot beam an MES is operating in.

Within a region, each beam will be given a unique reference number called the "Spot ID". The Spot ID will
be held by the NCS as part of an MES's record in the mobiles list. With this information, the NCS is able to
transmit on the correct NCS common channel for any given MES.

9.5 MES Database Synchronisation via Registration Update Request


CN131-compliant LESs will have the necessary facility for an LES operator to initiate registration update
requests to the NCS for MESs which are missing in the LES database. The NCS will response with either
enhanced (CN127-compliant LES) or standard registration packets.

10 Procedures for Commissioning and Performance Verification


(PVT)
The automatic commissioning and periodic performance verification testing of Inmarsat-C MESs are under
the control of the NCS. The tests themselves are performed by LESs. All MESs include the facility for
automatic testing by an LES over the satellite link. The purposes of automatic testing are to:

(a) monitor individual MES performance, and provide for the identification of malfunctioning MESs;

(b) monitor link performance; and

(c) perform commissioning tests.

A request for testing may be made by an MES at any time. This request is transmitted to the NCS by the
MES. Performance verification testing may be requested by an LES on identifying a malfunctioning MES, or
an MES operator may request PVT.

An MES which is classed as 'commissioning pending' will initiate the commissioning process by attempting
to log in to an ocean region. The associated NCS will interpret this log in request as a request for
commissioning.

All timeouts and recovery procedures are defined in the SDL diagrams given in Volume 5.

10.1 Commissioning
The actual commissioning procedures are given in a separate documentation set which is available from
Inmarsat.

Once a commissioning application has been processed by Inmarsat, two unique 24 bit Inmarsat-C MES
identities will have been associated with a nine decimal digit ITU identity allocated by the routing
organization. These identities will then be passed by the Inmarsat NOC to all Inmarsat-C NCSs along with
other relevant information. Each NCS will add the MES and its associated identities to its mobiles' list with a
'commissioning pending' status.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 48
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Each NCS will notify each LES in its region of the MES's entry by sending a registration packet with the
MES Status set to 'Not Commissioned'.

CN127-compliant LESs will receive an Enhanced Registration Packet which includes Inmarsat
Service Provider or Accounting Authority information to be used for billing purposes.

10.1.1 Commissioning Initiation


The MES operator, on being notified by the Inmarsat NOC that the MES has been placed on the mobiles'
list, may then initiate commissioning by transmitting a login request. After a successful log in sequence, the
NCS, on finding the MES's entry in its database, will instruct an LES to perform the commissioning test.
This is initiated by the NCS sending a commission request to the chosen LES.

10.1.2 Commissioning Tests


The selected LES will then conduct the commissioning tests fully automatically. The commissioning tests
consist of a performance verification test, described below in Section 10.2.3 and a distress alert test,
described in Section 10.3.

Each of the tests (performance tests and distress alert) will be attempted up to a maximum of three times.
If, at the third attempt, an MES is still failing, the LES will terminate the tests and the commissioning will be
considered unsuccessful.

10.1.3 Completion of Commissioning


The results of all tests will be reported to the NCS by the procedures in Section 10.3. If all tests are
successful (at least by the third attempt), then the NCS will change the status of the MES to a
commissioned state and automatically register the MES in the ocean region. The NCS will also inform the
other NCSs of the successful commissioning. Those NCSs further broadcast this information to the LESs in
their regions.

If any of the tests are still unsuccessful after the third attempt, the LES conducting the test informs the NCS
of the test results by means of a test result packet.

The failure will be noted by the NCS but further requests for commissioning are acknowledged and
accepted. If, after the third attempt, the MES still fails the commissioning tests, then further requests are not
acknowledged and all communication (other than distress priority) is barred.

10.2 Performance Verification Testing


The performance verification test allows an LES to automatically test an MES with respect to signal
strength, forward and return link packet delivery performance and certain access and control responses. In
addition, an MES's ability to perform a distress alert is verified.

10.2.1 Requesting Performance Verification Testing


Performance verification may be originated by either the MES, an LES or the NCS in the following manner:

(a) the MES requests a test by sending a test request to the NCS. On receipt of this packet the NCS will
check the validity of the request. If the request is valid, a request status will be sent on the NCS
common channel indicating that the test is pending. If the test request is invalid, a rejected status will
be returned with an appropriate status code;

(b) the LES originates a test by directly initiating the tests as described below; and

(c) for the NCS, no explicit actions are required to originate the tests.

10.2.2 Performance Verification Initiation


If the request is from an MES or the NCS itself, the NCS will choose an LES to undertake the tests. A test
request is sent to the chosen LES which will initiate an announcement sequence as given for To-Mobile

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 49
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

messages (Section 5.1.2). The parameters of the associated packets are set to indicate the fact that this is
a performance verification announcement.

10.2.3 Performance Tests


On receiving the announcement, the MES and LES follow the procedures for establishing a logical channel
(Section 5.1.3) for To-Mobile message transfer; the LES transfers a message as described in Section 6.1.
The test message may be any length as for a normal To-Mobile message transfer.

The LES will attempt to send the message a maximum of three times. If after the third attempt the To-
Mobile test message transfer procedure fails, then the LES will terminate the test procedure and record the
MES as having failed the test.

If, by the third attempt, the MES successfully receives the message, then the LES will send a clear packet
to the MES, but will not inform the NCS that the MES is idle. The MES will immediately proceed to initiate a
From-Mobile call to the LES as if the LES is transmitting a permanent TDM (Section 5.2). After establishing
the connection, the MES will transmit the complete test message that it just received from the LES
according to the procedures of Section 6.2.

The Additional Information field is set to one byte and contains an eight bit binary representation of the MES
received bulletin board error rate (BBER). The BBER is represented as a count of the last 100 received
bulletin board packets determined as failed and is continuously monitored and updated by the MES. This
error is detected by the checksum.

During the time in which the MES transmits the test message, the LES performs measurements of the
MES's average signal strength to determine if this parameter is within the prescribed limits.

As for the To-Mobile message transfer test, three attempts are made at delivering the message. If, after the
third attempt, the message is still received in error at the LES, the LES will record the MES as having failed
the test. The message received by the LES is checked against the message that it originally sent. If any
differences are found the Test Result should show the reason for failure as "Failure in From-Mobile". Upon
successful completion of the message transfer, the LES will transmit a distress alert test request (see
Section 10.3 which follows) prior to transmitting the test results.

10.2.4 Performance Verification Completion


The LES will terminate the test by sending a test result with a 24 bit 'test results' field. Receipt of the test
result is acknowledged by the MES. The information contained in the results field may be stored or
displayed at the MES so that the operator can be made aware of the performance of the MES. The LES will
then send a clear to complete testing.

10.3 Distress Alert Testing


To initiate a distress alert test, the LES will send a distress test request on its TDM channel. Upon receipt of
the distress test request packet the MES shall transmit the distress alert test packet automatically. The LES
will respond with a distress acknowledgement to indicate to the MES operator that the test was successful.

If no response is received from the MES within a specified timeout, the LES will retry by sending the
distress alert request a maximum of two more times.

10.4 Results Reporting


Following a test, the LES will report the results of the test to the MES by means of a test result (MES)
packet on the TDM channel.

The MES responds to this packet with a test result acknowledgement using reserved access on the given
signalling channel and slot as indicated in the test result packet.

The LES also transmits a test result to the NCS with the same parameters except that the MES identity
replaces the logical channel number and that there is no frequency/slot parameter.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 50
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

11 Procedures for MES Database Coordination


11.1 Coordination Between NCS and NCS
11.1.1 MES Status Change
When an MES changes its logged in or commissioned status, the NCS which processes this information will
record the time at which the status change is applied to the MES database. In addition, that NCS will inform
the other NCSs although this transaction need not take place immediately the change has occurred. It
should be noted that in the case of an MES changing its ocean region, there is a period of time during
which LESs in the ocean region from which the MES has moved will still accept messages and therefore
cannot be delivered to the MES.

The change information including the time of change is passed to the other NCSs in an MES status change.
The receiving NCS maintains the latest time contained in an MES status change for each of the other
NCSs.

An NCS receiving an MES status change updates the LESs in its region using a registration packet
indicating the status of the MES and the originating NCS. An LES receiving a registration must check the
NCS which the MES has logged into.

CN127-compliant LESs will receive an Enhanced Registration Packet which includes Inmarsat
Service Provider or Accounting Authority information to be used for billing purposes.
Each NCS keeps the current logged-in ocean region of all registered MESs.

11.1.2 NCS Recovery


When an NCS is restarted or an NCS – NCS link re-established following a failure, it is necessary to
coordinate the MES databases. This is achieved by each NCS requesting updating information from the
other NCSs by means of an update request. The update request sent to an NCS contains the time in the
last MES status change received from that particular NCS which resulted in a successful update of the
recovering NCS's MES database.

An NCS receiving an update request will reply with a block update. A block update comprises a block
update start followed by a succession of MES status change packets giving information concerning any
MESs that have changed state since the time given in the update request, and finally a block update end. It
is suggested that MESs that are believed to be logged into the requesting NCS be reported first.

If the sequence number contained in a received MES status change does not follow sequentially that
contained in the previous packet, the receiving NCS will send an update request.

11.2 Coordination between LES and NCS


11.2.1 MES Status Change
It is necessary for each LES to know the operational state of each MES in its region. These operational
states are:

• not commissioned;

• logged in or out; and

• barred.

When the NOC updates the NCS's database with new MESs awaiting commissioning, the NCS propagates
this information by sending a registration packet to each LES in its region. This packet contains sufficient
addressing information for the LES to operate the mandatory store-and-forward telex service. It also
contains the time at which the NCS updated its MES database with the same information.

CN127-compliant LESs will receive an Enhanced Registration Packet which includes Inmarsat
Service Provider or Accounting Authority information to be used for billing purposes.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 51
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

On the successful commissioning of the MES, the NCS will send a registration to each LES in its region
changing the MES's operational state to logged in. And, whenever an MES explicitly logs in or out, a
registration is sent to each LES containing the appropriate status.

Each LES stores the latest time appearing in a registration packet. In addition, for each MES, the LES shall
have associated the last time, as given in the registration packet, that the MES's operational state was
modified.

11.2.2 LES Recovery


When an LES is restarted, or after a failure of the interstation signalling link, the LES shall update its MES
database with whatever changes have occurred to MESs while it was not in contact with the NCS.

Once the interstation signalling link has been re-established, the LES requests updating information from
the NCS using an update request. The update request contains the time kept by the LES which indicates
the last registration received.

The NCS responds to an update request with a block update. A block update comprises a block update
start followed by a registration for each MES which has changed its operational state since the time given in
the update request. After all registration packets have been sent, the NCS finishes the block update by
sending a block update end.

11.3 Decommissioning
When an MES is to be decommissioned, the NCS will inform LESs in its region using a registration packet,
with status set to "Decommissioned". The NCS will also inform other NCSs using an MES Update packet.
The NCS will then remove the MES from its Mobile List.

CN127-compliant LESs will receive an Enhanced Registration Packet which includes Inmarsat
Service Provider or Accounting Authority information to be used for billing purposes.

12 Management of LES channels


Channels are allocated by the NCS to an LES for forward and return traffic to MES terminals. They are
allocated in groups including one forward channel (TDM) and a number of return channels. The LES can
use the return channels as signalling or message channels at its discretion.

Channel groups can be allocated for permanent use or on demand for a period of time. This is determined
by network management at the NCS. Power is a limited resource and the strategy is to allocate permanent
channels to LESs that are known to have a high level of traffic. Demand Assigned channels are held as a
shared resource for LESs that have a low level of traffic and as supplementary channels to permanent
channels.

At start-up, an LES will normally request its allocation of permanent groups. In the case that the LES is not
allocated any permanent groups or needs additional groups, (for example, when the Permanent groups
become congested) the LES may request Demand Assigned Channel groups. Note that channels are
always allocated in groups including one forward channel (TDM). This means that if additional return
capacity is needed, the LES must request a whole new group. If an additional TDM channel is not required,
a demand assigned group acquired earlier should be released as soon as possible.

12.1 Permanent TDM Channel Groups


An LES shall always radiate on channels allocated to it as permanent TDMs. In the event that it
wishes to stop transmission, it must release the permanent TDM. Configuration changes are made by
the Inmarsat Network Operation Centre. Such changes may involve manual intervention. In the case
of a permanent TDM being withdrawn, the LES should first indicate withdrawal of service by clearing
the In-service bit in the Status byte of the bulletin board. After a suitable interval, transmission should
cease on the TDM and the channel group be released to the NCS.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 52
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Each permanently assigned frequency (both TDM and return channel frequencies) is assigned for use by a
specific LES—there is no "pooling" of the permanently assigned frequencies such that a requesting LES will
get any available frequency in the pool.

12.2 Demand Assigned TDM Channel Groups


When LES TDM channels are operated in the Demand Assigned mode, the initiative for assigning TDM
channels comes from the LES. It is up to the LES to decide when, or indeed if, to request additional TDM
channels, and this action may be taken at any time on the basis of congestion or expectations of
congestion. The decision to request or return additional TDM channels can be independent of the
management of individual calls. The NCS will have maximum limits on such allocations and may allocate or
refuse requests from the LES. It will also set limits to the time that allocations may be held and make
demands for the return of channels, if the holding time is exceeded. There is no requirement to directly link
TDM requests to requests for service, and it is at the discretion of the LES to refuse service.

A demand assigned group is allocated for a period of time called the "Hold" Time. The LES may keep a
demand assigned group for the period of the Hold time provided that the level of traffic is sufficient. If the
level of traffic is insufficient, the Channel Group should be returned without waiting for the Hold timer to
expire. In the event that calls are still in progress when the Hold time expires, the LES may keep the TDM
group until the calls have completed, but should not use the group for any new calls. Note that a call is
regarded as in progress when the LES has received the appropriate response to the announcement or
assignment; that is, Announcement Response or Assignment Response.

The NCS may at any time request the return of a demand assigned group, even before the Hold time has
expired. Normally the NCS will request the TDM to be released after a short interval, called the "Grace"
period, after the Hold time has expired. In this case, the LES should terminate any calls in progress on the
channels of the group, by issuing an LES Forced Clear for each call and then discontinue transmission of
the TDM and release the channels to the NCS.

When an LES is operating in demand assigned mode and does not have a TDM available for a new call, it
will have to request a new TDM group from the NCS before it can proceed with the call. It will therefore
have to pend the call until the TDM group has been established. At the MES, the operation of establishing
connections, can therefore appear to be different when using demand assigned channels in that calls may
take longer to establish and it is more likely that new assignment requests will be pended.

Congestion can occur because of TDM or return channel congestion, TDM request pended by the NCS or
TDM hold time has expired.

The algorithm used by the NCS for Demand Assignment is described in Volume 3: Earth Station
Requirements, Part 3.

13 Enhanced Group Calls


Enhanced Group Calls are a means for authorised ground based Information Providers to broadcast
messages to a selected group of MESs, such as a fleet at sea, or to MESs within a particular geographical
area.

Two of the services provided are:


SM
FleetNET
SM1
SafetyNET
SM
FleetNET is used to send commercial messages to individuals or groups of subscribers (for example,
individual companies communicating with their own MESs).

1Further information on the International SafetyNET service is given in the "International SafetyNET
Manual", IMO-908, published by the International Maritime Organization.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 53
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

SM
SafetyNET is used for broadcasting Maritime Safety Information (MSI) such as navigational warnings,
meteorological warnings, meteorological forecasts and other safety related information (including Distress
Alert Relays) from official sources.

EGC is also used for transmitting Inmarsat system messages.

To send an EGC message the Information Provider uses an appropriate terrestrial service such as the
Telex or Packet Switched Network to gain access to the required Land Earth Station. CCITT Rec. F.127
describes the operational procedures. Having gained access to the LES, the Information Provider supplies
addressing information and the information to be broadcast.

Four methods of addressing EGC receivers are employed. These are:

i) General broadcast addressing used for All-mobiles broadcasts and INMARSAT system messages;

ii) EGC Network ID (ENID) addressing for broadcasting messages to groups or fleets of mobiles with a
SM
common ENID (FleetNET only);
SM
iii) Individual addressing for sending messages to single MESs, (FleetNET only) and
SM
iv) Area addressing using circular, rectangular or pre-defined geographical addresses, (SafetyNET
only).

The LES prepares EGC packets for forwarding to the NCS via the inter-station signalling link. The NCS
then transmits the EGC message packets on the common channel.

The message may consist of up to 32768 bytes of information and is therefore divided into blocks of a
maximum length of 256 bytes each, before being forwarded to the NCS in packets. Each packet, other than
the last, has a continuation marker set in the packet header. Either of two methods may be used:

- Single Header or

- Double Header

In the single header method, the block is sent in a single packet. In the double header method, the block is
further divided and sent in two packets, each of which has the same header. Whichever method is used,
the NCS acknowledges receipt of each complete block, with an EGC Acknowledgement packet. This
procedure is illustrated in the following figures:

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 54
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 22: Transmission of EGC Message Using Single Headers

FIG. 4-22 Transmission of EGC Message


Using Single Headers

LES NCS MES

Service Code
C P Repetition
Message Sequence
Number
Packet Sequence No.
Presentation
LES ID

Address
Information
ISL
CRC

Information

EGC Packet (Single Header)


Service Code
C P Repetition
Message Sequence No.
Message Sequence
Number
RS Spare
ISL Packet Sequence No.

EGC Acknowledgement Presentation


LES ID

Address
Information

CRC
CC

Information

EGC Packet (Single Header)

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 55
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 23: Transmission of EGC Message Using Double Headers

FIG. 4-23 Transmission of EGC Message


Using Double Headers
MES
LES NCS

Service Code
C P Repetition
Message Sequence
Number

Packet Sequence No.


Presentation ISL
LES ID

Address
Information

CRC

Information
16 Bytes

EGC, First Header

Service Code
C P Repetition
Message Sequence
Number
Packet Sequence No.
Presentation
LES ID ISL
Address
Information
Service Code
CRC C P Repetition
Message Sequence
Number

Information Packet Sequence No.


Presentation
LES ID

EGC, Second Header Address


Information

CRC
Message Sequence No.
Information
RS Spare
ISL 16 Bytes CC

EGC Acknowledgement

EGC, First Header

Service Code
C P Repetition
Message Sequence
Number
Packet Sequence No.
Presentation
LES ID

Address
Information
CC
CRC

Information

EGC, Second Header

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 56
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

14 Spot Beam Satellite Network Operation


Spot beam satellites allow more efficient use of the satellite resource by allowing power and/or bandwidth to
be concentrated in areas of greatest demand. Future generations of INMARSAT satellites are likely to
support multiple spot beams. INMARSAT-3 satellites, for example, will support a global beam and up to five
reconfigurable spot beams. Later satellite generations may support more. INMARSAT-C network operation
is compatible with spot beam satellites and the purpose of this section is to describe network operation in a
spot beam environment.

14.1 NCS
Each NCS operating with a satellite supporting spot beams will provide, as a minimum, a single global
beam common channel and one common channel per spot beam. These common channels will be
transmitted continuously.

The NCS will know from which beam (spot ID) the login for a particular MES originated and it will use this
information to route traffic correctly to that MES. The NCS will ensure that LESs are also informed of the
MES's current spot beam by means of the registration packet.

14.1.1 NCS Capacity Expansion


It is possible that common channel capacity expansion may be required in the global and/or spot beams at
some future time, in which case there might be two or more common channels in each spot. Expansion of
common channel capacity would be undertaken by Inmarsat as Inmarsat-C and EGC traffic requires it.

An MES can log in to any satellite beam using any common channel available within that beam. On logging
in the MES may be instructed to tune to one of the expansion common channels.
SM
Initially traffic would be split such that maritime MES and EGC SafetyNET traffic would be handled on one
SM
common channel and land mobile MES and EGC FleetNET traffic would be handled by an expansion
channel. Future system enhancements may allow EGC traffic to be routed to specific common channels
and spot beams at the NCS.

14.2 LES
Each LES is assigned permanent and/or demand assigned TDMs and return channels by the NCS. The
actual number of TDMs assigned to a particular LES may be more or less than the total number of satellite
beams available (global plus spots) depending on the traffic handled by that LES.

14.3 MES
When spot beam network operation is to be implemented in the INMARSAT-C system, INMARSAT will
publish details of the network including the NCS spot beam common channel numbers and IDs. This
information will be made available in a number of different ways, including broadcast by EGC. It will be the
responsibility of each MES operator to ensure that the NCS IDs and channel numbers are correctly entered
at the MES.

Once this information is entered, an MES may be forced manually to tune to a particular common channel
or alternatively it may be set up to automatically scan the NCS list at 24 hourly intervals, or when prompted
by an operator, or when reception of the current common channel deteriorates. After scanning, the MES will
tune to the common channel with the strongest signal level and log in. Common channels (and LES TDMs)
in spot beams may be radiated at a higher EIRP than those in the global beam. This will result in an
improved forward link margin and will also tend to attract MESs away from using the global beam.

Automatic NCS scanning is prohibited in all martime MESs and maritime EGC receive facilities

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 57
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

15 Restoration Mode Network Operation

15.1 Demand assigned


Any demand assigned TDMs shall cease to be transmitted after hold time expiry, if they are being
transmitted at the time of the NCS failure. Demand assigned TDMs not being transmitted at the time of the
failure shall not be transmitted until such time as they are assigned by the NCS, following recovery.

15.2 Spot beam operation


The Restoration mode of operation of the Inmarsat-C network when spot beams are used, is for further
study.

16 Management Of Multiple Permanent LES TDMs


In cases where traffic levels warrant the assignment of more than one permanent TDM to an LES, the
LES shall assign local IDs to the TDMs, starting at 0 for the primary TDM.

In order to manage traffic, the LES shall transmit an LES TDM descriptor packet on the primary TDM
at regular intervals. The TDM descriptor packet informs MESs of the availability of the other TDMs
associated with that LES and lists their satellite frequency codes. The packet should be transmitted at
regular and frequent intervals on the LES primary TDM. The interval between successive
transmissions, in frames, shall be LES operator settable. Typically this might be set to once every 6
frames.

MESs shall randomly select one of the available TDMs to use for non-priority mobile originated traffic
(with the exception of pre-assigned data reporting) at the start of each transaction.

Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 58
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Chapter 5: Protocol for the Data Reporting Service

Contents

1 Introduction ............................................................................ 2

2 Addressing ............................................................................. 2
Figure 1: Data Reporting MES Configurations ........................................................3

3 Data Transfer .......................................................................... 4

4 Enhanced Data Reporting ........................................................ 4


4.1 Addressing ........................................................................................................4
4.2 Data Transfer ....................................................................................................4

5 Programmed Unreserved Data Reporting ................................. 5

Volume 1: System Description, Chapter 5: Protocol for the Data Reporting Service Page: 1
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

1 Introduction
This chapter describes the protocol for the data reporting service using unreserved access. Refer to
chapter 7 for pre-assigned (reserved access) data reporting.

The Data Reporting service is intended for transferring small quantities of data from an MES to a pre-
determined terrestrial user. Data is transferred on a signalling channel using unreserved access. The
data may be deposited into a data reporting (DNID) file at the LES and this file retrieved by the
terrestrial user or forwarded by the LES operator. The service depends on local arrangements
between the terrestrial user and the LES owner.

Data Reports may be issued by the MES under the control of an operator or device attached to the
MES DCE, or the MES can be pre-programmed using a poll.

This chapter describes the protocol used for the service. Packet formats are given Volume 4.

2 Addressing
The general model of an MES has a DCE which, on one side implements the satellite side protocols
to communicate with the LES, and on the other side has addressable ports to communicate with
devices attached to the DCE. Each port is allocated a sub-address with sub-address zero being
reserved for the normal messaging DTE defined in Volume 3: Earth Station Requirements. A port in
this context could be a separate physical connection (a Configuration I DCE) or a logical connection
where, say, a PC is managing several sub-addresses (Configuration II DCE), or a combination of the
two. The DCE maintains a table which associates the various parameters required to undertake data
reporting. The two configurations are illustrated in Figure 1.

A short form of addressing is employed called "closed network addressing". A Data Reporting and
Polling Closed Network Identity (DNID) is allocated to the MES(s) which will be reporting to a
particular terrestrial user. DNIDs may be downloaded and deleted using the polling protocol (see
Chapter 6).

Volume 1: System Description, Chapter 5: Protocol for the Data Reporting Service Page: 2
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 1: Data Reporting MES Configurations

DCE Interface to Satellite


DNID LES ID Subaddress Member No.

Interface ports to DTEs with Sub-addresses


0 1 2 3 4 5

DTE

Configuration I MES

DCE Interface to Satellite


DNID LES ID Member No.

DTE-DCE Interface (default sub-address 0)


0
To attached
devices
DTE

Configuration II MES

Volume 1: System Description, Chapter 5: Protocol for the Data Reporting Service Page: 3
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3 Data Transfer
The data is transferred using a data report packet and subsequent continuation packets if necessary.
The MES uses the unreserved protocol to access the signalling channel to transfer the data report to
the LES (see Chapter 4, Section 4.3.2: Unreserved Access).

The first two bytes of the first packet's data field contains the assigned Data Reporting and Polling
Closed network identity (DNID), the next byte contains the destination LES identity (LES ID), and the
following byte contains a Member Number, which identifies the member of the Closed Network. The
content and format of the [Data] field portion of each data report will depend on the device attached to
the DCE part of the MES and the service being implemented. The data reporting protocol does not
address this issue and the DCE is simply seen as packing the data provided by an attached device
into the [Data] field.

The data reports will be transmitted on a signalling channel associated with the LES TDM in the
network update/long login acknowledgement packet.

If the destination LES is operating with a demand assigned TDM, the data report packets will be
transmitted to the NCS. The NCS will route each data report to the given LES using the interstation
signalling link to forward the packet(s) inside a signalling packet envelope (see Volume 4: Packet
Formats and Usage).

The limit on the amount of data which may be transferred by a given MES in a single data reporting
transaction is given in terms of the maximum number of continuation packets permitted. For
unreserved access data reporting this limit is two continuation packets, that is, three packets in all.

4 Enhanced Data Reporting


The Enhanced Data Reporting facility is fully compatible with Data Reporting but offers additional
capabilities and features:

i) Data report integrity is assured by the use of an internal checksum covering the overall data
report contents (all transmitted packets).

ii) The inclusion of the MES ID field ensures unambiguous identification of MESs.

iii) Enhanced Data Reporting provides an acknowledgement and status request facility to
ensure reliable transfer.

The enhanced data report includes a facility for providing addressing and control information in the
first packet. In order to provide compatibility with existing applications that may still require a 32 byte
payload capability, the enhanced data report may consist of four consecutive packets. This gives a
maximum payload capability of 40 bytes (37 if the DNID and member number are included in the
control information field).

4.1 Addressing
Enhanced Data Reporting includes a flexible addressing scheme to allow the use of alternative
addressing and routing mechanisms other than just via an assigned Data Reporting and Polling
Closed network identity (DNID). The control type and control length fields indicate the type of
address/control information and the control length field indicates how long the field is in bytes.

4.2 Data Transfer

Volume 1: System Description, Chapter 5: Protocol for the Data Reporting Service Page: 4
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

The data is transferred using an enhanced data report packet and subsequent continuation packets if
necessary. The MES uses the unreserved protocol to access the signalling channel to transfer the
data report to the LES (see Chapter 4, Section 4.3.2: Unreserved Access).

The first three bytes of the first packet contains the MES return ID), the next byte contains the
destination LES identity (LES ID). The content and format of the [Data] field portion of each data
report will depend on the device attached to the DCE part of the MES and the service being
implemented. The data reporting protocol does not address this issue and the DCE is simply seen as
packing the data provided by an attached device into the [Data] field.
The data reports will be transmitted on a signalling channel associated with the LES TDM in the
network update/long login acknowledgement packet.

The enhanced data reporting protocol is not supported with demand assigned LES TDMs.
The limit on the amount of data which may be transferred by a given MES in a single data reporting
transaction is given in terms of the maximum number of continuation packets permitted. For
unreserved access data reporting this limit is two continuation packets, that is, three packets in all.
However, for enhanced data reporting, three continuation packets are permitted making a total of four
packets in all. This allows a maximum of 40 bytes to be transferred in a single transaction (37 if the
DNID and member number are included).

The MES attempts to send the enhanced data report to the destination LES. If the attempt is
unsuccessful, the application may re-initiate the transmission. If the attempt was successful, a timer is
initialised awaiting reception of the acknowledgement, if one was requested. If the acknowledgement
is received within the timeout period, the status is set to ‘Success’ and the procedure exited. If the
timeout expires an enhanced data report status request is sent and the acknowledgement expected
once more. If the timeout expires again, the enhanced data report is re-transmitted. If the timeout
expires again the enhanced data report status request is sent once more. If this final attempt fails
(after sending the enhanced data report twice and the status request twice for MaxCC=4), the
procedure is exited with status ‘Fail’. In such cases the application is responsible for taking any
remedial action should it be necessary.

When an enhanced data report is successfully received by an LES, as determined from the data
report checksum, the LES sends the acknowledgement, comprising the forward MES ID, Sequence
number and length, if requested to do so. If an enhanced data report status request is received and
the associated enhanced data report was also previously received before the timeout occurred (as
determined from the sequence number and length fields) the LES (re-) sends the acknowledgement.
If an enhanced data report status request is received and the associated enhanced data report was
not previously received within the timeout period, no acknowledgement is issued and the LES will
await the repetition of the enhanced data report.

If the LES supports enhanced data reporting and there is no enhanced data reporting traffic, the LES
will issue an empty enhanced data reporting acknowledgement on each permanent TDM supporting
enhanced data reporting every T0 seconds (typically 6 frames).

5 Programmed Unreserved Data Reporting


MESs (DCEs) may be programmed to automatically transmit unreserved access data reports at
regular intervals. The programming of the MES maybe accomplished using the polling protocol and
specific, pre-defined commands (see Volume 4, Chapter 9).

The MES is programmed with the following parameters:

(a) data network identity (DNID);

(b) LES ID;

(c) member number;

Volume 1: System Description, Chapter 5: Protocol for the Data Reporting Service Page: 5
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

(d) Logical channel number;

(e) starting frame number, and

(f) reporting interval.

Actual data reporting is initiated by using a group poll.

Once initiated the MES remains tuned to the NCS Common Channel until the start frame. It also
remains tuned to the NCS until the randomised backoff has occurred before tuning to the LES TDM. It
then checks that the bulletin board origin ID corresponds to the programmed LES ID and transmits
the data report.

If the destination LES is operating demand assigned, the data report will be sent via the NCS. The
NCS will forward any data reports to the LES over the Interstation Signalling Link.

Data reporting may not interrupt a message transfer from the MES; that is, once an MES has received
a logical channel assignment giving the frame offset and start slot for a message transfer, a data
report may not interrupt the message transmission. Similarly, if a Class 2 MES which is not in the
EGC receive only mode is receiving an EGC message addressed to that MES, a data report may not
interrupt the EGC reception.

Volume 1: System Description, Chapter 5: Protocol for the Data Reporting Service Page: 6
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 6: Protocol for the Polling Service

Contents

1 Introduction ............................................................................ 2

2 Addressing ............................................................................. 2

3 Polling .................................................................................... 2
3.1 Individually Directed Polling ..............................................................................2
3.2 Group Directed Polling ......................................................................................3
3.3 Area Directed Polling ........................................................................................3
3.4 Poll Acknowledgement ......................................................................................4

Volume 1: System Description, Chapter 6: Protocol for the Polling Service Page: 1
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
The polling protocol allows a terrestrial user to initiate some action by an MES or a group of MES(s).
This action could be a transfer of data by the MES to the terrestrial user. Data transfer may be
undertaken using Data Reporting (Chapter 5), the Pre-assigned Data Reporting service (Chapter 7) or
normal From-Mobile message transfer.

Polling requests sent to MESs may contain text or data prepared by the terrestrial user. This allows,
for example, a group call facility with acknowledgement to be implemented.

Packet definitions are given in Volume 4; SDL appears in Volume 5.

2 Addressing
Closed network addressing is used with a Data Reporting and Polling closed network identity being
allocated to the MES(s) which are to respond to a poll from a given terrestrial user. In addition, a sub-
address is provided to allow activation of a specific device attached to an MES. The use of the sub-
addressing facility is a matter for the application.

3 Polling
Three types of polling are supported:

(a) 'individually directed' for polling on an MES by MES basis;

(b) 'group directed' for polling a group of MESs with the same closed network identity (defined by
the DNID/LES ID pair); and

(c) 'area directed' polling of a set of MESs with the same closed network identity (defined by the
DNID/LES ID pair) and lying within a given geographical area.

Due to the broadcast nature of a poll, means are provided to repeat a particular poll. To prevent
repeated polls being processed, each poll associated with a specific DNID and LES ID has a
sequence number which is incremented modulo 256 between successive polls. It should be noted
that:

- a poll will not be repeated after 24 hours;

- successive new polls will have sequence numbers incremented by one;

- polls with sequence numbers less than (current sequence number -128) modulo 256 will not be
repeated;

- poll acknowledgements are only re-sent (if requested) if the poll type was an individual poll or
the previous acknowledgement attempt was unsuccessful.

3.1 Individually Directed Polling


Individually directed polling refers to the process of sending an explicit polling command to one MES.

The MES(s) and the polling command originator will be pre-registered at the LESs. After the terrestrial
circuit is connected, the end user enters a list of MES identities to which he wishes the individually
directed polling commands to be sent. If necessary, the LES will establish a polling output (DNID) file
to which the polling responses will be written. For each MES in the user's list, an individual poll will be
sent to the NCS.

Volume 1: System Description, Chapter 6: Protocol for the Polling Service Page: 2
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Upon receipt of an individual poll, the NCS transmits an individual poll on the NCS common channel if
the MES is idle. The LES is informed that transmission of the poll has taken place by means of an
appropriately coded MES status packet.

If the MES is busy or the NCS is unable to handle any additional traffic at that time, the poll is queued
until the MES is again idle.

If the MES is indicated as not being present in the ocean region, the LES is informed by means of an
MES status packet. An indication of the MESs absence from the ocean region is placed in the polling
output file.

Each MES receiving an individual poll may respond using either the data reporting protocol or a From-
Mobile message transfer depending on the contents of the command and response fields. The
response field may be used to determine the response the MES will actually send, but the MES DCE
need not make use of this field (the response to the poll may originate from a device or DTE attached
to the DCE). With data reporting, the data report will be placed in the polling output file at the LES
(Chapter 5). If a From-Mobile message transfer is used, the destination address may either be the
data network identity given in the individual poll or a terrestrial end user address. In the first case, the
message would be placed in the polling output file.

3.2 Group Directed Polling


Whereas with individually directed polling, a polling command is sent to each individual MES and then
only when idle, with group directed polling a single polling command is broadcast on the NCS
common channel. MESs may only respond if they are idle, receive the polling command and are part
of the group defined by the data network identity (DNID) and LES ID pair (and sub-address in the
case of a Configuration I MES DCE).

After the terrestrial user has requested a group poll, the LES sends a group poll to the NCS.

No status checking is required, and the NCS will broadcast a group poll on the NCS common channel
with the same packet parameters as the group poll from the LES. The poll is confirmed to the LES by
the NCS sending a group poll status with the data network identity as the single parameter.

Upon receipt of the group poll, addressed MESs may initiate a response to the originating LES. A
randomizing interval is also given in the group poll packet which gives the number of frames over
which the MES must randomize its response, and/or poll acknowledgement if one was requested.
This parameter is provided to prevent overload of the random access system by the polling response
from a large group. The MES shall remain tuned to the NCS TDM until the randomised backoff has
occurred. If during the interval, a higher priority activity starts, the MES will hold the backoff count until
this activity has completed and only then resume the backoff count and respond.

Group polls also include a LES TDM field in the poll. The MES uses the LES TDM supplied in the poll
for the response (including the case where the response is a From-Mobile message transfer) and/or
acknowledgemet if either were requested. If the LES TDM field is set to FFFFH, then the LES is
operating demand assigned and the NCS Common Channel should be used. For each MES the
manner of responding follows that given for individually directed polling (Section 3.1).

3.3 Area Directed Polling


Area directed polling is functionally the same as group directed polling with the exception that only
those MESs with the same closed network identity defined by the DNID/LES ID pair and lying within a
defined area are addressed. A geographical address is included in the area poll as is the data
network identity.

Using an area poll status, the NCS confirms to the LES that it has broadcast the area poll.

Volume 1: System Description, Chapter 6: Protocol for the Polling Service Page: 3
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.4 Poll Acknowledgement


All polls have a one bit Acknowledgement sub-field. If this bit is set the MES is required to send a pre-
defined format data report acknowledging the receipt of the poll before taking any further action: that
is, before the poll is passed on by the DCE for action. The acknowledgement is a link level function
intended to convey to the LES/poll originator that a poll has been successfully received by the MES. It
does not necessarily mean that the MES is able to process or respond to the poll.

The following rules govern the handling of poll acknowledgements by the MES:

i) All Individual polls with any sequence number and recognised MES ID shall be acknowledged if
requested in the poll packet;

ii) All Group and Area polls with new sequence numbers and recognised DNIDs and LES IDs
shall be acknowledged if requested.

iii) For all repeated (same sequence number) Group and Area polls with recognised DNIDs and
LES IDs for which the previous acknowledgement (if requested) was unsuccessful, the MES
shall re-transmit the acknowledgement if one is requested.

Volume 1: System Description, Chapter 6: Protocol for the Polling Service Page: 4
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 7: Protocol for the Pre-Assigned Data


Reporting Service

Contents

1 Introduction ............................................................................ 2

2 Slot Logical Channel ............................................................... 2


2.1 Report Length ...................................................................................................2
2.2 Report Interval ..................................................................................................2
2.3 Assignment Duration .........................................................................................2

3 Slot Logical Channel Assignment ............................................ 2


3.1 Demand Assignment Mode ...............................................................................3

4 Data Reporting ........................................................................ 3

5 Clearing .................................................................................. 4

Volume 1: System Description, Chapter 7: Protocol for the Pre-Assigned Data Page: 1
Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
The pre-assigned data reporting service is intended for users who need to gather data from MESs on
a regular basis. With the ability to define a constant interval between transmissions from each MES,
pre-assigned (reserved access) TDMA operation of signalling channels can be used instead of the
normal unreserved Slotted-Aloha access scheme, thereby allowing more efficient use of the return
channel capacity. This is a closed user group service with the LES operator coordinating user
requirements and satellite channel resources.

An LES offering the Pre-assigned Data Reporting service must synchronise its TDM frame numbers
with UTC.

A users group of terminals are each pre-programmed, with the necessary parameters. This is
performed remotely using an Individual Poll by the LES operator. A Group poll command is
subsequently used to initiate data reporting.

This chapter describes the protocols for the service; the packet formats are described in Volume 4.

2 Slot Logical Channel


The From-Mobile connection between a particular MES and an LES is called a 'slot logical channel'. A
slot logical channel provides an MES with one or more reserved MES signalling channel slots on a
fixed interval basis.

A particular slot logical channel has a set of attributes associated with it which describe the
connection assigned to the user. These are defined in the following subsections.

2.1 Report Length


A report consists of 1 to 4 signalling channel packets which can contain up to 44 bytes of user data.
Thus a slot logical channel can provide a maximum of four consecutive multislots for each report.

2.2 Report Interval


The report interval is given in terms of frames. There are 10,000 frames in 24 hours with the duration
of each frame being 8.64 seconds. The interval between reports can be set to allow data reporting
from every 10 frames to reporting every 63,000 frames (a little over 6 days).

A minimum report interval of 100 frames shall apply to classes of MES which require the use of the
NCS common channel for message announcements or the EGC service.

An LES operating a pre-assigned data reporting service is not obliged to offer all possible report
intervals. For ease of slot management, the operator might restrict the intervals available to a set of
pre-determined values.

2.3 Assignment Duration


An assignment is valid for a duration given in terms of the number of data reports which may be
transmitted on the slot logical channel. The duration can be from one report to 63,000 reports.

3 Slot Logical Channel Assignment


The pre-programmed method described below is primarily designed for large user groups having a
fixed data reporting requirement. The MES must be logged in to the ocean region and must be
capable of data reporting and responding to polls as described.

Volume 1: System Description, Chapter 7: Protocol for the Pre-Assigned Data Page: 2
Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Slot logical channels may be pre-programmed into the MESs of a particular user by use of an
Individual Poll. The parameters to be pre-programmed are:

(a) data network identity (DNID);

(b) LES ID;

(c) member number;

(d) Logical channel number;

(e) starting frame number;

(f) slot number;

(g) number of packets per report;

(h) reporting interval; and

(i) assignment duration.

Actual data reporting is initiated by using a group poll.

The allocation of resources in terms of slot logical channels is undertaken by the LES operator. After
the assignments have been programmed into the MESs, a group poll is sent via the NCS common
channel to initiate data reporting. Since there is a probability that some MESs will not receive the
initial group poll, further group polls may be sent. An MES that has already seen the group poll will
ignore further initiating group polls (since these will have the same sequence number) until it has
completed its assignment. The group poll contains the TDM satellite frequency code and the
signalling channel satellite frequency code. In addition, the LES ensures that the slot state markers for
the slots concerned are marked 'reserved'.

On reception of the group poll, an MES will store the TDM and signalling channel given for the
duration of the assignment. The MES will then commence data reporting as described in the following
section.

An MES receiving an individual poll must assume that the Start Frame and Slot information refer to
the next occurrence of those Frame and Slot numbers (usually the same day). If the group poll does
not arrive until after the time (and day) of the Start Frame and Slot, the MES shall start, providing the
Slot Logical Channel Assignment has not expired. It must terminate data reporting after (Duration-1) *
Interval frames from the Start Frame. If it is desired to re-activate the MES, it is necessary to re-
program it using a new individual poll to perform the Slot Logical Channel Assignment.

3.1 Demand Assignment Mode


If the LES is operating with demand assigned TDMs, then the service may be run via the NCS. The
NCS will set the state of an agreed number of slots per frame to 'reserved'. It is the responsibility of
the LES operator to allocate the slot logical channels to its user groups. The NCS will forward any
data reports to the LES over the Interstation Signalling Link.

4 Data Reporting
On being enabled to start pre-assigned data reporting, the MES is free to transmit in its pre-assigned
slot from the allocated starting frame. Before the frame number on the NCS common channel
matches the allocated starting frame, the MES retunes to the given TDM and checks that the bulletin
board origin ID corresponds to the pre-programmed LES ID. If they do not match, then the data report
will be abandoned. When the programmed start frame number and the TDM frame number match and
if the associated slot state marker indicates that the slot is reserved, the MES will begin its data report

Volume 1: System Description, Chapter 7: Protocol for the Pre-Assigned Data Page: 3
Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

in the pre-defined slot using data report packets containing only data. Packet formats are given in
Volume 4.

The associated slot state marker on the TDM is used to feed back the result of the transmission in the
normal manner.

If any one packet of a multi-packet Pre-assigned Data Report is not received correctly or there is any
other problem with the Reserved status, SCD decode, Bulletin board decode, etc., the Data Report is
abandoned. Any remaining reserved slots are unused. The entire Data Report may be re-sent using
the unreserved access Data Reporting service if the multi-packet Pre-assigned Data Report consists
of three packets or less. Alternatively, at the next reporting interval, the MES may send the same data
or new data at its discretion.

Pre-assigned data reporting may not interrupt a message transfer from the MES; that is, once an MES
has received a logical channel assignment giving the frame offset and start slot for a message
transfer, a data report may not interrupt the message transmission. Similarly, if a Class 2 MES which
is not in the EGC receive only mode is receiving an EGC message addressed to that MES, a pre-
assigned data report may not interrupt the EGC reception.

5 Clearing
An MES with a preprogrammed slot logical channel cannot clear its channel.

The LES may clear a slot logical channel by sending an individual or group poll with the command
field indicating "stop reserved reporting". The MES terminates Data Reporting. If the DNID value is
zero, all MESs which are sending data reports to the LES using the pre-assigned protocol shall stop
sending data reports.

If the network enters restoration mode operation and the TDM radiating on the common channel
frequency indicates a joint NCS/LES TDM, all MESs shall terminate pre-assigned data reporting.

Volume 1: System Description, Chapter 7: Protocol for the Pre-Assigned Data Page: 4
Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 8: Land Mobile Alerting

Contents

1 Introduction ............................................................................ 2

2 Protocol .................................................................................. 2

3 Routing at the LES .................................................................. 2

Volume 1: System Description, Chapter 8: Land Mobile Alerting Page: 1


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
This supplement describes the optional Land Mobile Alerting function in the Inmarsat-C system. As it
is an optional service, its implementation at an Individual Inmarsat-C LES is at the discretion of that
particular LES operator. The end-to-end service arrangements, including the routing of the alert
message at the LES end for appropriate responses, will also naturally vary from service provider to
service provider. This optional service capability is envisaged as a chargeable service and no
parallels are to be drawn between this land mobile alerting function and the maritime distress alert.

Provision for Land Mobile Alerting is optional for LESs. For LMESs and LPESs, the capability to send
Land Mobile Alerts is also optional (see Volume 3, Part 2, Chapter 6 and 7, Section 8).

2 Protocol
Land Mobile Alerts are defined as using the distress alerting protocol, but with some differences
(detailed below), the purpose of which are to separate the Maritime Distress and Land Mobile Alert
functions.

For Land Mobile Alerts:

1) Alerts are only sent to LESs which have the 'LES services' field in the bulletin board set to
indicate Land Mobile Alerting is provided (see Volume 4, Chapter 2, Section 3.1.4.6). The LES
sends an acknowledgement in response to the Land Mobile Alert if the mobile is registered for
the Land Mobile Alerting service at that LES. The LES should not copy the Land Mobile Alert
packet to the NCS.

If the LES TDM channels are operating in Demand Assigned mode the Land Mobile Alert may
be sent to the NCS (subject to the normal protocol, that the NCS Services and Signalling
Channel Descriptor(s) indicate that Land Mobile Alerting is supported).

2) Alerts are only sent on signalling channels whose corresponding signalling channel descriptors
(SCDs) have their 'Land Mobile Alerting' bit set (see Volume 4, Chapter 2, Section 3.2.6), i.e.
Land Mobile Alert channels may use different frequencies from Maritime Distress Alert
channels.

3) The packet format is different from the Maritime Distress Alert packet format (see Volume 4,
Chapter 11).

3 Routing at the LES


LESs capable of accepting Land Mobile Alerts must determine whether the MES sending the alert is a
maritime or land-based terminal, by inspection of the Inmarsat Mobile Number (derived from the MES
ID ). If the Inmarsat Mobile Number is a maritime number, the alert should be routed to the MRCC in
the normal way. If the Mobile Number is that for a land-based MES, the alert should be routed to the
pre-determined destination. If no prior arrangement has been made with that LES, then the Land
Mobile Alert may be rejected, i.e the LES need not send an acknowledgement to the MES. (See
Volume 3, Part 1, Chapter 2, Section 8.8.1, for description of Inmarsat Mobile Numbers.)

Using the Inmarsat Mobile Number to determine if a terminal is maritime or land-based, allows alerts
received from all MESs commissioned for land use to be identified (and not sent to the MRCC),
irrespective of the original intended use of the equipment.

Volume 1: System Description, Chapter 8: Land Mobile Alerting Page: 2


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 9: Protocol for the Mobile to Mobile Data


Reporting with Indirect Acknowledgement

Contents

1 Scope ..................................................................................... 3

2 Introduction ............................................................................ 3

3 General Description ................................................................ 3


3.1 Outline process .................................................................................................3
3.2 Addressing ........................................................................................................3
3.3 Base Oriented Data Reporting .........................................................................4
Figure 1: Base-oriented Data Reporting and Polling ...............................................4
3.4 Mobile to Mobile Data Reporting ......................................................................5
Figure 2: Mobile-Mobile Data Reporting and Polling ...............................................5
3.5 Implementation Considerations .........................................................................6
3.5.1 LES ................................................................................................................6
3.5.2 MESs .............................................................................................................6

4 Packet Definitions ................................................................... 6


4.1 Packet formats for Base Oriented Data Reporting and Polling .........................6
4.1.1 Packet Format for Data Report from Mobiles .................................................6
4.1.2 Polling Packet Format to Base Station ...........................................................7
Figure 3: Non-Interpreted Data Report Format from a Mobile in a Mobile-Base
Data Reporting .........................................................................................7
Figure 4: Packet Format for a Poll to Base Station .................................................7
Figure 4: Packet Format for a Poll to Base Station .................................................8
4.1.3 Packet Format for Data Report from Base Station .........................................8
Figure 5: Data Report Format for Base-Mobile Transactions Using Individual Polling
9
Figure 6: Data Report Format for Base-Mobile Transaction Using Group Polling . 10
Figure 7: Data Report Format for Base-Mobile Transaction Using Area Polling ... 10

Volume 1: System Description, Chapter 9: Protocol for the Mobile to Mobile Data Page: 1
Reporting with Indirect Acknowledgement
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.1.4 Packet Format for Base to Mobile Poll ......................................................... 11


Figure 8: Packet Formats for Base-Mobile Polls ................................................... 11
4.2 Packet Format for Mobile to Mobile Data Reporting and Polling ..................... 12
4.2.1 Packet Format for Mobile to Mobile Data Reporting (Type 08H) .................. 12
Figure 9: Packet Formats For Base-Mobile Polls .................................................. 12
4.2.2 Packet Format for Mobile to Mobile Polls (Type 25H) .................................. 12
4.2.2 Packet Format for Mobile to Mobile Polls (Type 25H) .................................. 13
Figure 10: Packet Format (Type 25H) for Mobile-Mobile Polls.............................. 13
Appendix A: Flow-Chart for the Processing of Data Reports for Base to Mobile
and Mobile to Mobile at an LES ........................................................ 14

Volume 1: System Description, Chapter 9: Protocol for the Mobile to Mobile Data Page: 2
Reporting with Indirect Acknowledgement
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Scope
This chapter describes a new protocol for the provision of mobile to mobile data reporting with indirect
acknowledgement. Familiarity with standard data reporting and polling protocol is assumed.

2 Introduction
The current data reporting protocol is susceptible to collision problems which can result in false
acknowledgement being indicated to the sending mobiles. Unless additional mechanisms are
provided to accommodate this, it may impact on the quality of data reporting service delivered as the
traffic grows. The new protocol described in this note uses an indirect acknowledgement scheme to
overcome the false acknowledgement problem. The new protocol also allows an LES to receive from
a MES or Base Station, a data report and reformats it into an appropriate polling packet for sending
over the LES signalling and TDM channel respectively . In this way the delay of delivery via the NCS
can be avoided.

With this new protocol, two new polling packet types (24H and 25H) and one new data report packet
type (08H) are defined. The new polling packet type 24H is used by an LES to pack the data reports
received from a mobile and then to send it to a Base Station over the LES TDM. The data report type
08H and polling packet type 25H are used for mobile to mobile data reporting and polling over the
LES TDM.

3 General Description

3.1 Outline process


The communications process consists of two distinct operations via the Inmarsat-C system. Each
base to mobile or mobile to mobile transaction involves the transmission of a data report, consisting of
between one to three packets, to the LES, the re-formatting of the data into an appropriate polling
packet by the LES and the transmission of this polling packet to the destination MES.

The mechanisms for the transmission of polling packets to the destination MES can be achieved as
follows:

a) Base Oriented Data Reporting

- The poll packets to mobiles are sent via the NCS common channel TDM and those to
the Base Station via the LES TDM.

b) Mobile to Mobile Data Reporting

- The poll packets are sent via the LES TDM only.

3.2 Addressing
In order for the LES to differentiate the data reporting with indirect acknowledgement from the
standard data reporting, it is recommended that the following range of DNIDs and member numbers
shall be used :

DNIDs : from 15000 to 30000

Member Number : 001 - 250 for mobile terminals

251 - 255 for Base Station

Volume 1: System Description, Chapter 9: Protocol for the Mobile to Mobile Data Page: 3
Reporting with Indirect Acknowledgement
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

000 - This is reserved for group addressing for mobile to mobile reporting
and polling.

3.3 Base Oriented Data Reporting


The use of this type of data reporting is illustrated in Figure 1 and it generally consists of a Base
Station and a number of mobiles within a closed user group. A Base Station would normally be
installed at a fixed location and provide the functionality of a hub, collecting data about the condition of
a customer’s mobiles and presenting to an operator. Under this mode of communication, the Base
Station is required to stay tuned to the LES TDM all the time while the mobiles tune to the NCS TDM
when idle.

Figure 1: Base-oriented Data Reporting and Polling

ific
-spec
Base olls
P Sta
nd
ific Re ard D
-spec po
Base eports rts ata
R
Data
St
an
da
rd
Polls

Po
ts
or

lls
ep

dard
R

i
lls cif
a
at

Po spe

Base
D

Stan
-
se

Station
Ba

ISL
Closed User Group of
Mobiles
LES NCS

a) Mobile to Base Communication

The mobiles send the data reports to an LES via the signalling channel using the standard data report
format. Based on the information of DNID/LES/Member contained in the first data report packet , the
LES reformats the data report packets into a new poll packet type 24H ( see Section 4) and sends it
over its TDM within the next N_Ack frames ( N_Ack being the time-out parameter). The Base Station
will receive and process the poll according to the information presented in the DNID/LES ID/Member
Number fields.

As a mechanism for indirect acknowledgement, the mobile, after sending the data report, stays tuned
to the LES TDM to check the relevant poll and its content. If the correct poll packet has not been
delivered by the LES within a time-out of N_Ack frames, the mobile retransmits the data report and
waits for the same time-out. The mobile shall repeat this process until the correct poll is detected or
abort the transmission when the number of attempts has reached MaxCC times.

b) Base to Mobile Communication

The Base Station sends its data report via the LES signalling channel. In this case the LES shall be
able to examine and interpret the format of the data report packets and to reassemble them into either
a standard individual, group or area poll which will then be forwarded to the NCS for transmitting over
the common channel. An individual mobile or a group of mobiles will handle the relevant poll packets
according to the standard polling process.

Volume 1: System Description, Chapter 9: Protocol for the Mobile to Mobile Data Page: 4
Reporting with Indirect Acknowledgement
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The LES will also send a poll of packet type 24H with the content, except the sequence number field,
matching the data packets received from the Base Station (see Section 4 for further detail). If the
correct poll packet has not been delivered by the LES within a time-out of N_Ack frames, the Base
Station retransmits the data report and waits for the same time-out of N_Ack frames. The Base
Station shall repeat this process until the correct poll is detected or abort the transmission when the
number of attempts has reached MaxCC times

3.4 Mobile to Mobile Data Reporting


In this mode of data reporting, all the mobiles within a group are required to tune to the LES TDM as
depicted in Figure 2. The mobile sends a data report of type 08H over the signalling channel of the
LES. The LES will validate the DNID/LES ID of the data report and reformats it into a mobile to mobile
poll of packet type 25H.

Figure 2: Mobile-Mobile Data Reporting and Polling

Sp M
ec ob
ific ile
D a - Mo
ic

ta bil
ts cif

Re e
or e
ep Sp

po
M pe c
R le

ob if

r ts
S
ta obi

ile ic
Da -M

- M Po
ile

ob lls
Po ile
ob

ile
b
M

lls
ific o
ec le-M
Sp obi
M

LES
Closed User Group of
Mobiles

As the sending mobile stays tuned to the LES TDM, it shall be able to detect and validate the content
of the poll packet being transmitted by the LES as a mechanism for indirect confirmation of the
reception of the data report. The same retransmission mechanism as described for base oriented
communication is also deployed for this mode of data reporting.

A mobile within a closed user group will only accept the poll packets under the following conditions:

- the destination member matches its own member number, or

- it is a group addressed poll, i.e. destination member number being zero.

Volume 1: System Description, Chapter 9: Protocol for the Mobile to Mobile Data Page: 5
Reporting with Indirect Acknowledgement
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.5 Implementation Considerations

3.5.1 LES
a) Processing of Poll Packet Types 24H and 25H

In order for the indirect acknowledgement mechanism to work effectively without too many
retransmissions by the mobiles, the LES shall be able to send out the poll packets of type 24H and
25H as soon as possible without having to put them in the same queue with the normal to-mobile
message packets.

b) DNID/Member

Based on the DNID/Member information , the LES shall be able to construct the poll packets
accordingly and route them to the correct destination address. It shall also be possible for the LES to
disable this translation and routing feature when the mobiles or Base Stations are being down loaded
with the DNID/Member information during the configuration phase.

As an illustration of a possible implementation of the above mechanism at an LES, a flow-chart


outlining the main steps involved with the processing of data reports and the construction of relevant
polls is given in the Appendix A.

3.5.2 MESs
The MESs shall be configurable to work in one of the two modes as outlined above.

It is envisaged that during the power up after installation, an MES shall be in a standard MES mode. If
the necessary DNID and member information have not been pre-programmed, the MES may then log-
in to a particular ocean region and wait for the downloading of DNID/Member information. Once the
relevant information has been obtained, the MES can be configured to operate in Base-oriented or
Mobile-Mobile mode. For those MESs operating as a Base Station or in Mobile-Mobile mode, they will
retune to the desired LES TDM after the completion of configuration.

It shall also be possible to change the time-out parameter, i.e. N_Ack, for indirect acknowledgement
which is set to 10 frames as a minimum. This shall enable a system integrator or service provider to
fine tune the system to meet the loading profile of an LES TDM.

4 Packet Definitions
The following sections describe in some detail the packet formats used in both base oriented and the
mobile to mobile data reporting and polling with indirect acknowledgement as outlined in the Section
3.

4.1 Packet formats for Base Oriented Data Reporting and Polling
In this mode of communication, the data report packets from the mobiles are not interpreted by the
LES and they will be reformatted into a poll packet of type 24H for sending to the base terminal over
the LES TDM. However, the data reports from the base terminal will be interpreted by the LES to
construct the appropriate polls for sending over the NCS common channel to the mobiles.

4.1.1 Packet Format for Data Report from Mobiles


The data fields within the data reports which originate from the mobile terminals are the same as that
for standard data report packets as shown in Figure 3.

The definitions for standard data report packets are described in Volume 4, Chapter 8 of the SDM.

Volume 1: System Description, Chapter 9: Protocol for the Mobile to Mobile Data Page: 6
Reporting with Indirect Acknowledgement
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.1.2 Polling Packet Format to Base Station


The data report packets from mobile are reformatted by the LES into a new polling packet type 24H
which shall then be transmitted over the LES TDM.

The definitions of the polling packet type 24H are given in Figure 4.

Figure 3: Non-Interpreted Data Report Format from a Mobile in a Mobile-Base


Data Reporting

Bit No. Bit No.

8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
1 P
1 C
P C Type P Type
2 P 2
DNID
3 3

4 4
LES ID
5 5
Source Member No.
6 Data
6
Bytes Bytes
7 7
8
8 Data
9
9
10
10
11
11
12
12
13
13
14
14 CRC CRC
15
15
First or Second Continuation Packet
Standard Data Report Packet (Optional)

Volume 1: System Description, Chapter 9: Protocol for the Mobile to Mobile Data Page: 7
Reporting with Indirect Acknowledgement
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 4: Packet Format for a Poll to Base Station

Bit No.

8 7 6 5 4 3 2 1
1
1
P 0 Type = 24H
2
Length
3
DNID
4

5
LES ID
6
Source Member No.
Bytes 7
Sequence No.
8
Data

4.1.3 Packet Format for Data Report from Base Station


Although a data reports originating from the Base Station is of the same packet type as the standard
data report, its contains a description for the construction of the polling packets to the mobile
terminals. A CN-132 complaint LES shall be able to interpret this information and construct the
relevant poll packet accordingly.

The parameter describing the polling type for the delivery of the data report to the mobile is encoded
using the bits 5 and 6 of the 7th byte of the first data report packet. The interpretation of these two bits
is as follows :

Bit 6 5

0 0 Individual Poll
0 1 Group Poll
1 0 Area poll

a) Data Report for Individual Poll

The format of data report packets used to specify delivery of information from a base terminal to a
specific mobile is shown in Figure 5 below. The Inmarsat-C Mobile Number is used to identify the
destination mobile and the LES will have to translate this number to MES ID when constructing the
individual poll.

Volume 1: System Description, Chapter 9: Protocol for the Mobile to Mobile Data Page: 8
Reporting with Indirect Acknowledgement
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 5: Data Report Format for Base-Mobile Transactions Using Individual Polling

Bit No. Bit No.


8 7 6 5 4 3 2 1
8 7 6 5 4 3 2 1
1 1
P C Type P C Type
2 2
DNID
3 3
4 4
LES ID
5 5
Source Member No.
6 6 Data
Bytes Sub-address
Bytes
7 Resp 0 0 7
8 8
Command
9 9
10 Inmarsat-C 10
11 Mobile Number
11
12 12
13 Data 13
14 14
CRC CRC
15 15

Base-Mobile Data Report Packet First / Second Continuation Packet


for delivery using Individual Poll (Optional)

b) Data Report Format for Group Poll

The format of data report packets to specify the delivery of information from a base terminal to a
group of mobiles is shown in Figure 6.

c) Data Report Format for Area Poll

Figure 7 illustrates the format of data report packets for delivery of information from a base terminal to
a group of mobiles within a particular defined area. As there is not enough room in the first data report
packet to define the length of Area code, a CN132-compliant LES shall be able to infer the length
from the ‘Area Type’ (bit 3 and 2 of the 7th byte) field as outlined below:

Area type Length

00H 0 length i.e. no address field and all group member polled

01H 1 byte length

03H 4 byte length

04H 4 byte length

Volume 1: System Description, Chapter 9: Protocol for the Mobile to Mobile Data Page: 9
Reporting with Indirect Acknowledgement
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 6: Data Report Format for Base-Mobile Transaction Using Group Polling

Bit No.
Bit No.
8 7 6 5 4 3 2 1
8 7 6 5 4 3 2 1
1 1
P C Type P C Type
2 2
DNID
3 3
4 4
LES ID
5 5
Source Member No.
6 6 Data
Sub-address
Bytes Bytes
7 Resp 0 1 Spare 7
8 8
Command
9 9
10 10
11 11
12 12
Data
13 13
14 14
CRC CRC
15 15
Base-Mobile Data Report Packet First / Second Continuation Packet
for delivery using Group Poll (Optional)

Figure 7: Data Report Format for Base-Mobile Transaction Using Area Polling

Bit No. Bit No.


8 7 6 5 4 3 2 1
8 7 6 5 4 3 2 1
1
1 P PC Type P C Type
2
2
DNID
3 3

4 LES ID 4

5 Source Member No. 5

6 Sub-address 6 Data
Bytes Bytes
Resp 1 0 Type Spare 7
7
8 Command 8

9 9
10 Area * 10
11 11
12 12
Data 13
13
14 14
CRC CRC
15 15
Base-Mobile Data Report Packet for delivery using Group First / Second Continuation Packet
Poll (* from 0 to 4 bytes depending on the Area Type) (Optional)

Volume 1: System Description, Chapter 9: Protocol for the Mobile to Mobile Data Page: 10
Reporting with Indirect Acknowledgement
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.1.4 Packet Format for Base to Mobile Poll


Depending on the polling parameter specified in the data report, an LES will repackage the data
packets into an individual, a group or an area poll which will then be forwarded to the NCS for
transmission over the common channel. As shown in Figure 8, the formats for these three polling
packets are of same definitions as what have been defined in Volume 4, Chapter 9 of the SDM.

The poll packet of type 24H sent by the LES over its TDM as an indirect acknowledgement to the
Base Station of the reception of a data report is as shown in Figure 4. The data portion of the poll
packet contains the remaining information of the data report sent by the base terminal.

Figure 8: Packet Formats for Base-Mobile Polls

Bit No.
Bit No. Bit No.
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
1 1 Type = 22H 1 Type = 23H
1
P 0 Type =21H 1
P 0 1
P 0
2 Length 2 Length
2
Length
3 3
3 DNID MES ID
4 4
DNID
4 5 5
LES ID
5 6 6 LES ID
LES ID LES TDM
7 7 Sub-address
6
8 Sub-address 8
LES TDM DNID
7
9 Randomising Interval 9
8 Sub-address 10 10
Resp Spare Resp Spare

9 Randomising Interval 11 Command 11 Command


Resp Length
10 Type Sequence No.
12 12
Sequence No.
Area

Command
Data Data
Sequence No.

Data

Area Group Poll Individual Poll

Volume 1: System Description, Chapter 9: Protocol for the Mobile to Mobile Data Page: 11
Reporting with Indirect Acknowledgement
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.2 Packet Format for Mobile to Mobile Data Reporting and Polling
Under this mode of communication, the mobiles within a closed user group will stay tuned to the LES
at all time. They use a new data report packet format to send data reports over the LES signalling
channel and the LES will reformat the data reports to a new poll packet type for sending over its TDM.

4.2.1 Packet Format for Mobile to Mobile Data Reporting (Type 08H)
The packet format for data reports from mobile is shown in Figure 9 below. With the exception of
packet type and destination member number, the definitions for the rest of the data fields are the
same as that for the standard data report packets.

Figure 9: Packet Formats For Base-Mobile Polls

Bit No. Bit No.

8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
1 1
P C Type = 08H P C Type
2 2
DNID
3 3

4 4
LES ID
5 5
Source Member No.
6 6 Data
Destination Member No.
Bytes Bytes
7 7
8 8
Data
9 9

10 10
11 11
12 12
13 13
14 14
CRC CRC
15 15

Mobile-Mobile Data Report First / Second Continuation Packet


Package (Optional)

Volume 1: System Description, Chapter 9: Protocol for the Mobile to Mobile Data Page: 12
Reporting with Indirect Acknowledgement
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.2.2 Packet Format for Mobile to Mobile Polls (Type 25H)


The poll packet format for mobile to mobile transaction is shown in Figure 10.

Figure 10: Packet Format (Type 25H) for Mobile-Mobile Polls


P

Bit No.

8 7 6 5 4 3 2 1
1
1 0 Type = 25H25H
2
Length
3
DNID
4

5
LES ID
6
Source Member No.
Bytes 7 Destination Member No.

8
Sequence No.

Data

Volume 1: System Description, Chapter 9: Protocol for the Mobile to Mobile Data Page: 13
Reporting with Indirect Acknowledgement
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Appendix A: Flow-Chart for the Processing of Data Reports for Base to Mobile
and Mobile to Mobile at an LES

1
Idle

Data_report
Data Report
Packets from SES SIG

Validate
data field

Check
(no) Member
Result Number
OK?

(yes)
(no)
Valid Member
Number ?
Check DNID
against DNID List
(yes)
B B

(no) (no)
Base Station
Valid DNID ? member
Error Handling no. ?

(yes) (yes)

Individual poll,
(yes) Group Poll or
A
DNID for Construct Area Poll depending
standard data standard poll on the poll type
report embedded in the
data report from
Base Station
(no)

(no)
Mobile_Mobile
Data Report ? Send Poll to
NCS via
ISL
(yes)
Standard Data
Report
Processing Construct
Mobile_Mobile Construct
Poll "25H" Mobile_Base Poll
"24H"

Send Poll via


1 LES TDM

Accumulate
Statistics

Volume 1: System Description, Chapter 9: Protocol for the Mobile to Mobile Data Page: 14
Reporting with Indirect Acknowledgement
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 10: Glossary and Abbreviations

Contents

1 Introduction ............................................................................ 2

2 List of Terms Used .................................................................. 2

3 List of Abbreviations Used .................................................... 12

Volume 1: System Description, Chapter 10: Glossary and Abbreviations Page: 1


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
This chapter explains the terms and abbreviations used throughout the Inmarsat-C system definition
documentation.

2 List of Terms Used


ALERT

A general term for a maritime or Land Mobile alert.

ALOHA

A random access protocol for accessing a packet satellite network. Packets are offered randomly and,
in the event of a packet collision, are re-offered after a random time interval.

The scheme utilised in the Inmarsat-C system is a hybrid of slotted ALOHA, whereby time slots are
used and transmissions may only commence at the start of slots, and an explicit reservation
technique, with reserved slots being indicated on the LES bulletin board.
Automatic Request Repeat (ARQ)
An error control system for later transmission whereby the receiver is able to detect errors and to
request the transmitting end to retransmit the errored sequence or packet.

AXIAL RATIO

The ratio of the major and minor axes of a polarization ellipse.

BINDING

A procedure analogous to the initial signalling transfer in a circuit switched network.

In the Inmarsat-C system binding provides an indication of the availability of both ends of the link, a
connection reference number for all message packets associated with the call and information on the
length of the message to be transferred.

BLOCKAGE

The situation in which the transmission/reception line of sight path to a mobile is blocked. The
communication link is (temporarily) broken.

BLOCK SIZE

The number of coded data (modulation symbols) in an interleaved frame. In the From-Mobile
message channel, the interleaver block size (including 128 bits for the dual unique word) is variable in
steps of 2048 symbols from 2176 symbols to 10368 symbols. In the To-Mobile direction the
interleaver block size is fixed at 10368 symbols.

BULLETIN BOARD

The bulletin board is transmitted in each TDM frame and is always the first packet. It contains a
sequence of fields providing information on the static operational parameters of the NCS or LES
transmitting the TDM. The bulletin board also contains a field for the frame count (0 - 9999) giving a
timing reference to the MES.

BULLETIN BOARD ERROR RATE

The bulletin board error rate (BBER) is a measure of the number of bulletin board packets received in
error out of the last hundred received bulletin board packets. This count is continuously updated

Volume 1: System Description, Chapter 10: Glossary and Abbreviations Page: 2


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

frame by frame. The measurement is performed regardless of received channels (LES or NCS TDM)
and for every frame received whilst the receiver is synchronised to a TDM (valid UW).

BURST MODE

The mode of transmission employed exclusively on the signalling channel. Information is transmitted
in short duration bursts in which data is encoded but not interleaved.

BURST PACKET
A short message of 316 symbols consisting of an uncoded 64 bit unique word and 120 bit message
(convolutionally encoded to 252 symbols) used for signalling and data reporting on the signalling
channel.

CHANNEL DEFINITIONS

The channels used for signalling, control and data transmission in the Inmarsat-C system are:

TDM CHANNELS

Used for control and LES-to-MES message transfer.

MESSAGE CHANNELS

Used for the transmission of pre-formatted messages in the MES-to-LES direction.

SIGNALLING CHANNELS (LES)

Used for transmitting control, signalling and data reporting packets from the MES to the LES.

SIGNALLING CHANNELS (NCS)

Used instead of the MES signalling channel when LESs are operating in the demand assigned
mode. It also processes all MES login, logouts and distress alerts.

NCS COMMON CHANNEL

Used for call announcements, confirmations, polling commands and as a timing reference for
all MESs.

INTERSTATION SIGNALLING LINK

Used for the passing of network operational and status information and EGC messages
between LESs and the NCS.

NCS/NCS SIGNALLING CHANNEL

Used for the transmission and updating of MES registration lists between ocean regions.

CHANNEL MODEL

A mathematical model used to simulate the effects of fading due to multipath propagation on the
maritime satellite channel.

The actual model utilised in the Inmarsat-C system is a semi-empirical model which has been shown
to provide data in good agreement with measurements. This model is derived from the statistics of
multipath fading in the maritime satellite channel, which can be approximated by a Rician distribution.
The parameters defining this model have been selected to approximate measured data for low gain
antennas and worst case (in terms of multipath interference) sea states.

Volume 1: System Description, Chapter 10: Glossary and Abbreviations Page: 3


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

CHECKSUM

A 16 bit field at the end of a packet used to provide a check for the receiver that all the packet data
has been received error free.

CLOSED NETWORK

A private network available only to a group of registered users. Access from the public network being
barred to non-registered users.

CLOSED USER GROUP

Users of a communication service who have the facility to communicate with one another but access
is barred to and from all others.

COAST EARTH STATION

See Land Earth Station.

COLLISION

A situation which occurs when two or more burst packets are transmitted in the same signalling
channel slot. All such packets would be lost and would have to be re-offered.

COMMISSIONING

Approval by INMARSAT of a particular MES for use in the INMARSAT system after satisfactory
completion of tests which demonstrate that the design meets INMARSAT requirements.
Commissioning is usually granted to type approved models which have undergone modifications in
order to meet certain requirements for special applications (see Type Approval).

CONTINUATION BURST MODE

Used for From-Mobile polling responses, data reporting messages and half duplex transmissions,
where data is transmitted on the MES signalling channel. If the data requires more than one slot then
the LES will authorise continuation burst mode (reserved access) transmission by setting the
appropriate slot in the signalling channel descriptor packet (see Reserved Access).

CONVOLUTIONAL CODING

A method of encoding information bits for forward error correction.

DATA CIRCUIT TERMINATING EQUIPMENT (DCE)

Equipment located at either end of a data circuit providing all the functions necessary to establish,
maintain and terminate a connection. The equipment also carries out all signal conversion and coding
between the DTE and the link.

DATA CLOSED NETWORK IDENTITY (DNID)

A closed network identification number identifying a closed user group making use of Inmarsat-C
closed network addressing.

DATA REPORTING

A short data packet transmitted in burst mode on the signalling channel as a result of a polling
command or at the initiative of the MES (operator).

Volume 1: System Description, Chapter 10: Glossary and Abbreviations Page: 4


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

DATA TERMINAL EQUIPMENT (DTE)

Equipment at which a communication path begins or ends—for example, a keyboard and display or
teletype.

DEMAND ASSIGNMENT

A system by which the channels, from a common pool, are assigned as required by the NCS on a
demand basis, as opposed to the permanent assignment where the channel(s) are permanently
allocated to each LES.

DISTRESS ALERT

In the Inmarsat-C system, a packet transmitted to an LES or an NCS on a signalling channel by a


maritime MES in distress.

A distress alert provides information on a ship's identity, position, course, speed and the nature of
distress. A distress alert has the highest priority in the Inmarsat-C system.

DISTRESS CALL

This term is generic and covers both the Distress Alert and the Distress Priority Message.
Distress Priority Message

In the Inmarsat-C system, a store and forward message carried on a messaging channel having
Distress Priority. Used for distress communications between maritime MESs and RCCs.

EGC CLOSED NETWORK IDENTITY (ENID)

A closed network identification number identifying a closed user group making use of the EGC
FleetNETSM group calling capability.

EGC SERVICE CODE

A service type code used for EGC messages to indicate the type of services and the addressing
method employed (for example area, group or individual addressing).

EXTERNALLY MOUNTED EQUIPMENT

Equipment not mounted within a cabin. Equipment exposed to the elements.

FLEETNETSM

An EGC service for the transmission of commercial messages and data to individuals or groups of
subscribers.

FORWARD LINK

The To-Mobile (LES-MES) link.

FRAME

A reference period transmitted in the To-Mobile direction by all LESs and NCSs; the period is equal to
one To-Mobile interleaver block size (10368 symbols), or a period of 8.640 seconds.

FROM-MOBILE

A call set up by the Mobile Earth Station operator to transfer a message from the MES via an LES.

Volume 1: System Description, Chapter 10: Glossary and Abbreviations Page: 5


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

GLOBAL MARITIME DISTRESS AND SAFETY SYSTEM

The Global Maritime Distress and Safety System (GMDSS) is a radiocommunications system based
on satellite and terrestrial technology, designed to improve communications relating to distress and
safety of life at sea. It was adopted by the International Maritime Organisation in 1988, in the form of
Amendments to the International Convention for the Safety Of Life At Sea (SOLAS), 1974.

INTERNALLY MOUNTED EQUIPMENT

Equipment mounted within a cabin or otherwise protected from the elements.

INTERLEAVING

This is the process of spreading coded data in the time domain. It has the effect of converting the
bursts of errors that would result from a fade into more or less randomly distributed errors which can
be corrected by the convolutional decoder.

LAND EARTH STATION (LES)

Also Coast Earth Station (CES). An LES/CES provides the gateway between the Inmarsat-C mobile
network and the terrestrial networks. All calls, including mobile-to-mobile calls, are made through an
LES.

LAND MOBILE ALERT

An alerting facility for land mobile users.

LOGICAL CHANNEL

For the connection oriented services (message transfer and half duplex) a logical channel for each
separate connection is assigned by the LES. At any time, only one logical channel may be associated
with a particular LES/MES pair.

MARITIME SAFETY INFORMATION

A broadcast service of navigational warnings, meteorological warnings, meteorological forecasts and


other safety related information provided by official Registered Information Providers. It is transmitted
in the SafetyNETSM service via EGC.

MESSAGE CHANNEL

A return link (From-Mobile) channel used for message transfer.

MESSAGE PACKET

A self-contained segment of a message consisting of packet number, data fields and a checksum.

MOBILE EARTH STATION (MES)

The term mobile earth station refers to the Inmarsat-C mobile user terminal consisting of a DCE and
DTE, whether maritime or land based.

MES IDENTITY (ID)

To each MES, a unique pair of 24 bit codes will be allocated. One code shall be used in the To-Mobile
direction and the other in the From-Mobile direction; there will not necessarily be a logical relationship
between the two codes.

Volume 1: System Description, Chapter 10: Glossary and Abbreviations Page: 6


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

MES NUMBER

A nine decimal digit code. It will be assigned to the MES by Administrative Organizations and used by
a terrestrial subscriber or another mobile operator to address the MES.

MES STATUS

The operational status of an MES in an ocean region; i.e., idle, busy, not present in ocean region, or
present but non-operational.

MULTIPATH FADING

The fading phenomenon associated with the interference between a direct path wave and one or
more reflected path waves.

In the case of Inmarsat-C the direct wave is from the satellite and the reflected waves are due to
scattering of the satellite signal from the sea and other surfaces (see Channel Model).

MULTISLOT

Each signalling channel slot position within a frame may be regarded as two or three mutually
independent information channels. Each of these channels is referred to as a multislot (2-frame or 3-
frame).

NETWORK COORDINATION STATION (NCS)

The network coordination station provides network management functions in each satellite ocean
region. NCSs also transmit EGC messages on the NCS common channel.

NONVOLATILE MEMORY

Memory which can retain stored data in the absence of applied primary power.

OMNIDIRECTIONAL ANTENNA

An antenna having a non-directional pattern in a given plane, usually the horizontal (azimuth) plane.

OPEN NETWORK

Public network.

ORIGINATOR

The party initiating communications.

PACKET

A self contained component of a message, comprising address, control and data signals, that can be
transferred as an entity within a data network.

PACKET SWITCHED

A method of message transmission in which each complete message is assembled into one or more
packets that can be sent through the network, collected and then reassembled into the original
message at the destination. The individual packets need not even be sent by the same route. The
communication channels are only occupied during the transmission of a packet.

Volume 1: System Description, Chapter 10: Glossary and Abbreviations Page: 7


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

PARITY CHECK

A check performed on a given number of binary digits to determine if the total number of binary ones
(or zeros) is odd or even.

PERFORMANCE VERIFICATION TEST (PVT)

An automatic test performed by an LES to verify that an MES is functioning correctly and that the
quality of the link is adequate for reliable communication.

PERMANENT ASSIGNMENT

An LES TDM that is transmitted continuously within the system.

POLLING

A Inmarsat-C satellite service whereby selected groups of MESs are interrogated. The selected MESs
respond in a predetermined manner, either with a data reporting message or by initiating a From-
Mobile message transfer.

Polling may be either individually directed, group direct or area directed.

PRE-ASSIGNED DATA REPORTING

A form of data reporting in which data reports are sent on a signalling channel in a frame and slot
previously assigned to the mobile for that transmission. This protocol makes use of reserved access
of signalling and allows a much higher throughput on the signalling channel than that achievable
using unreserved access data reporting.

PRESENTATION CODE

A code transferred between MES and LES to indicate to the receiver (either MES or LES) the
presentation or formatting of the data contained in the message.

PROTOCOL

The rules for communication system operation which must be followed if communication is to be
possible. The complete interaction of all possible series of messages across an interface.

RADOME

A cover used to protect an antenna from exposure to the elements without degrading its electrical
performance.

RANDOM ACCESS

TDMA slot selection by a mobile is made at random during unreserved access. See also Signalling
Channel and ALOHA.

RANDOMIZATION INTERVAL

In order to prevent an overload of the signalling channel in the event of a large group of MESs being
addressed by a polling command, the LES transmits a randomization interval (the value of which will
be proportional to the anticipated MES population being addressed). This randomization interval is an
interval over which the MES must respond. MESs will use an internal random number generator to
select a time delay, not exceeding the randomization interval, before responding to the polling
command.

Volume 1: System Description, Chapter 10: Glossary and Abbreviations Page: 8


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

RESERVED ACCESS

Access to a signalling channel by a mobile whereby the frame and slot for transmission have been
reserved for that mobile by the LES.

RESTORATION MODE

Mode of network operation used in an ocean region during a failure of the NCS. During that period, a
pre-designated LES will transmit a carrier on the NCS Common Channel frequency with a frame
similar to the NCS Common TDM indicating that the network is in Restoration Mode.

RETURN LINK

The From-Mobile (MES-LES) link.

RIGHT HAND CIRCULAR POLARIZATION

An elliptically or circularly polarized wave in which the electric field intensity vector, observed in any
fixed plane, normal to the direction of the propagation whilst looking in (i.e., not against) the direction
of propagation rotates with time in a right hand or clockwise direction (CCIR Recommendation 573,
1.6.1).

SAFETYNETSM

An EGC service for the dissemination of marine safety information such as weather, navigation
warnings and emergency messages to EGC receivers and INMARSAT MESs equipped with an EGC
capability.

SCRAMBLER

A coding device used to avoid potentially harmful repetitive data sequences. In a phase modulated
system such repetitive sequences could produce a zero phase shift over a comparatively long period,
resulting in a loss in synchronization between the transmitter and receiver.

SHIP EARTH STATION (SES)

A maritime MES. See Mobile Earth Station (MES).

SHORT CODE

A form of abbreviated addressing for sending messages to predefined destinations such as may be
required for medical assistance, for example. Such codes are special access codes and are generally
two digits (see CCITT F.126).

SIGNALLING CHANNEL

Random access TDMA channel (slotted Aloha) used for signalling and data reporting in the From-
Mobile direction.

SIGNALLING CHANNEL DESCRIPTOR PACKET

Following the Bulletin board packet in each TDM frame there is a signalling channel descriptor packet
for each signalling channel associated with that TDM. These packets provide feedback information to
MESs regarding the states of the slots of that signalling channel.

SIGNALLING PACKET

A burst packet on the signalling channel.

Volume 1: System Description, Chapter 10: Glossary and Abbreviations Page: 9


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

SPECIAL ACCESS CODE

A destination address code used for special services as may be provided by an LES operator. Short
codes, which may be two-digit F.126 codes, are examples of special access codes. Special access
codes may be up to six digits in length.

STORE AND FORWARD UNIT (SFU)

Computer equipment with associated storage that accepts messages from telex or data subscribers
for subsequent delivery to specified telex address or addresses. Conversational mode operation is not
provided.

SYMBOL

A single element of a coded data bit. In the Inmarsat-C system rate 1/2 convolutional encoding is
employed. This results in two modulation symbols being supplied to the BPSK modulator for every
data bit supplied to the encoder. Therefore the carrier is modulated at twice the data rate.

SYSTEM MESSAGE (EGC)

An EGC message type defined for supporting system operations. System messages are transmitted
only by LES operators, NCS operators, and the Inmarsat NOC.

TEST SIMULATORS

Specialised test equipment required for type approval of new MES models.

CHANNEL NOISE SIMULATOR

Used to superimpose Gaussian white noise onto the wanted channel; it is needed for all the
tests involving the performance of the MES demodulator and decoder.

INTERFERENCE SIMULATOR

Used to simulate various types of interfering carrier and is inserted in the receive path of the
MES under test.

LES/NCS SIMULATOR

Simulates the basic message processing, access and control and signalling functions of an
LES and an NCS, enabling thorough testing of the access and control functions of the MES to
be conducted. It may also be used in the Performance Verification of LES.

MES SIMULATOR

This may consist of an MES modified for external control and providing additional capabilities to
permit the validation of the performance of LES/NCS Simulators developed by MES
manufacturers for use in their type approval activities.

MULTIPATH SIMULATOR

Simulates the time variable multipath characteristics of a satellite maritime channel and is
inserted in the receive path of the MES under test.

TIME DIVISION MULTIPLEX (TDM)

A carrier transmitted by an LES or NCS on which data and signalling packets are sent. The data and
signalling packets are transmitted sequentially and may be for a number of different mobiles.

Volume 1: System Description, Chapter 10: Glossary and Abbreviations Page: 10


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

TO-MOBILE

A call set up by a terrestrial subscriber to transfer a message from the terrestrial network to a Mobile
Earth Station via an LES.

TYPE ACCEPTANCE

The process of acceptance of MES models by National Licensing Authorities.

TYPE APPROVAL

Approval by INMARSAT of an MES model as a design suitable for use in the INMARSAT system after
satisfactory completion of tests which demonstrate that the design meets INMARSAT requirements.

UNIQUE WORD

In the Inmarsat-C system, an uncoded 64 bit pseudo random sequence expressed in hexadecimal as:

07EA / CDDA / 4E2F / 28C2

with the first bit of the first digit transmitted first. This unique word is the same on all To-Mobile and
From-Mobile channels except that on the LES and NCS TDMs and the MES message channel the
unique word is 128 bits and consists of two of the 64 bit unique words described above transmitted
one after the other.

UNRESERVED ACCESS

Random selection of a signalling channel slot by an MES which has not been previously reserved by
the LES.

VITERBI DECODER

A decoder for convolutionally encoded data based on the Viterbi maximum likelihood decoding
algorithm.

Volume 1: System Description, Chapter 10: Glossary and Abbreviations Page: 11


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3 List of Abbreviations Used


A
ACK..........................................................................................................Acknowledgement
ACSE .........................................................................Access Control Signalling Equipment
ADE................................................................................................Above Decks Equipment
AFC ........................................................................................ Automatic Frequency Control
AGC .................................................................................................Automatic Gain Control
AMES ... ...........................................................................Aeronautical Mobile Earth Station
AMVER .......................................................................Automatic Mutual Assistance Vessel
AOR(E)...................................................................................... Atlantic Ocean Region East
AOR(W)....................................................................................Atlantic Ocean Region West
ARQ ........................................................................................... Automatic Request Repeat
ASCII................................................ American Standard Code for Information Interchange
AUSREP ......................................................................... Australian Ship Reporting System

B
BB ...................................................................................................................Bulletin Board
BBER ............................................................................................ Bulletin Board Error Rate
BCD................................................................................................... Binary Coded Decimal
BDE................................................................................................ Below Decks Equipment
BEP ........................................................................................................ Bit Error Probability
BER................................................................................................................. Bit Error Rate
BPSK .......................................................................................... Binary Phase Shift Keying
BTR .......................................................................................................Bit Timing Recovery

C
CBR....................................................................................Carrier and Bit Timing Recovery
CCIR...............................Comite Consultatif International des Radiocommunications (ITU)
CCITT.............................. Comite Consultatif International Telegraphique et Telephonique
CDR.................................................................................................... ....... Call Data Report
CFF................................................................................................... .... . Coded File Format
C/I .................................................................................. Carrier to Interference Power Ratio
C/Io.....................................................Carrier to Interference Power Spectral Density Ratio
C/M .....................................................................................Carrier to Multipath Power Ratio
CMC ..............................................................................................Common Messaging Call
CISPR ............................ Comite International Special des Perturbations Radioelectriques
C/No ...................................................................... Carrier to Noise Power Spectral Density
CPU................................................................................................. Central Processing Unit
CR ..............................................................................................................Carrier Recovery
CRC.............................................................................................Cyclic Redundancy Check
CRS....................................................................................................... Coast Radio Station
CSDN ................................................................................... Circuit Switched Data Network
CSI ..........................................................................................Chinese Standard Telegraph
CSU.................................................................................................. Channel Simulator Unit
CUG ....................................................................................................... Closed User Group

D
DAG.................................................................................................... Distress Alert Generator
dB............................................................................................................................ Decibels
dBc...................................................................................Decibels relative to a carrier level
dBHz ......................................................................................Decibels relative to one Hertz
dBi....................................... Antenna gain in decibels relative to an isotropic antenna gain
dB/K ................................................ Decibels relative to reciprocal Temperature (in Kelvin)
DCE..............................................................................Data Circuit Terminating Equipment
DM ............................................................................................................ Distress Message
DNID...................................................................Inmarsat-C Data (closed) Network Identity
DTE .............................................................................................. Data Terminal Equipment

Volume 1: System Description, Chapter 10: Glossary and Abbreviations Page: 12


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

E
Eb/No ..................................................... Bit energy to Noise Power Spectral Density Ratio
EDI ........................................................................................... Electronic Data Interchange
EGC.....................................................................................................Enhanced Group Call
EIA .................................................................................... Electronic Industries Association
EIRP ...................................................................... Equivalent Isotropically Radiated Power
EMC ...................................................................................... Electromagnetic Compatibility
EME...................................................................................... Externally Mounted Equipment
EMI ..........................................................................................Electromagnetic Interference
ENID..................................................................................... EGC (closed) Network Identity
EPIRB ...........................................................Emergency Position Indicating Radio Beacon
Es/No ............................................. Symbol Energy to Noise Power Spectral Density Ratio
ETSI ..................................................... European Telecommunications Standards Institute
E/W........................................................................................................................East/West

F
FDX ..................................................................................................................... Full Duplex
FEC ............................................................................................... Forward Error Correction
FRLP ......................................................................................Forward and Return Link Pair

G
GCI ............................................................................................. Graphic Character Internal
GES..................................................................................................... Ground Earth Station
GMDSS .......................................................... Global Maritime Distress and Safety System
GRT.................................................................................................. Gross Registered Tons
G/T ................................................................................... Gain to Noise Temperature Ratio

H
HDX.....................................................................................................................Half Duplex
HPA..................................................................................................... High Power Amplifier

I
IA5 ............................................................................................ International Alphabet No. 5
ID ................................................................................................................................Identity
IEC .....................................................................International Electrotechnical Commission
IEEE ............................................................ Institute of Electrical and Electronic Engineers
IFRB ................................................................. International Frequency Registration Board
IHO ................................................................................... International Hydrographic Office
IME ........................................................................................ Internally Mounted Equipment
IMN ............................................................................................ INMARSAT Mobile Number
IMO................................................................................International Maritime Organization
INMARSAT ..................................................... International Maritime Satellite Organization
I/O...................................................................................................................... Input/Output
IOR ...................................................................................................... Indian Ocean Region
IPMS................................................................................. Interpersonal Messaging Service
ISDN..............................................................................Integrated Services Digital Network
ISL ............................................................................................... Interstation Signalling Link
ISO ............................................................... International Organization for Standardization
ITA2......................................................................... International Telegraph Alphabet No. 2
ITU.......................................................................... International Telecommunication Union

J
JASREP ................................................................................ Japan Ship Reporting System

Volume 1: System Description, Chapter 10: Glossary and Abbreviations Page: 13


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

L
LAPB.............................................. Link Access Procedures (CCITT Red Book Rec. X.25)
LCN ............................................................................................... Logical Channel Number
LES ......................................................................................................... Land Earth Station
LHCP..................................................................................... Left Hand Circularly Polarized
LMES ...........................................................................................Land Mobile Earth Station
LMSS ......................................................................................Land Mobile Satellite Service
LNA ....................................................................................................... Low Noise Amplifier
LPDT ..................................................................................Low Power Distress Transmitter
LPES .........................................................................................Land Portable Earth Station
LSB ....................................................................................................... Least Significant Bit

M
M............................................ Number of signalling channels associated with a given TDM
MARECS........................................................ Maritime European Communication Satellite
MCC .................................................................................................... Mobile Country Code
MCS ................................................................................ Maritime Communication Satellite
MEM ............................................................................................. Macro Encoded Message
MES.......................................................................................................Mobile Earth Station
METAREA..........................................................................Meteorological Information Area
MHS ........................................................................................... Message Handling System
MID ........................................................................................... Maritime Identification Digits
MMSS................................................................................Maritime Mobile Satellite Service
MRCC........................................................................Maritime Rescue Coordination Centre
MS .................................................................................................................Message Store
MSB ....................................................................................................... Most Significant Bit
MSI ............................................................................................ Maritime Safety Information

N
N ........................................................................................ Block size for Message Channel
NAVAREA.................................................................................................Navigational Area
NCS........................................................................................ Network Coordination Station
NMEA.................................................................... National Marine Electronics Association
NOC .......................................................................................... Network Operations Centre
NRZ ........................................................................................................ Non Return to Zero
N/S ..................................................................................................................... North/South

P
PAD................................................................................... Packet Assembler Disassembler
PEP ................................................................................................. Packet Error Probability
PER .......................................................................................................... Packet Error Rate
PFD ........................................................................................................ Power Flux Density
PIN .......................................................................................Personal Identification Number
POR.................................................................................................... Pacific Ocean Region
PROM............................................................................ Programmable Read Only Memory
PSDN .................................................................................. Packet Switched Data Network
PSPDN ......................................................................Packet Switched Public Data Network
PSS ............................................................................................... Packet Switched Service
PSTN........................................................................... Public Switched Telephone Network
PVT ....................................................................................... Performance Verification Test

R
RAM ..............................................................................................Random Access Memory
RCC......................................................................................... Rescue Coordination Centre
RHCP ..................................................................................Right Hand Circularly Polarized
RMS .................Square Root of the Mean of the sum of the Squares of a number of terms
ROM ....................................................................................................... Read Only Memory
RSS ..................................... Square Root of the Sum of the Squares of a number of terms

Volume 1: System Description, Chapter 10: Glossary and Abbreviations Page: 14


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

RX .............................................................................................................Receive/Receiver

S
SAR....................................................................................................... Search and Rescue
SCADA................................................................ Supervisory Control and Data Acquisition
SCC..................................................................................................Satellite Control Centre
SCD ................................................................................. .... Signalling Channel Descriptor
SDL ......................................................... Specification and Description Language (CCITT)
SDM ............................................................................................. System Definition Manual
SES .......................................................................................................... Ship Earth Station
SFU ..................................................................................................Store and Forward Unit
SOLAS ............................................................................... Safety of Life at Sea convention
SSB ........................................................................................................... Single Side Band
SWR .................................................................................................... Standing Wave Ratio

T
TBD ....................................................................................................To Be Decided/Define
TDM.................................................................................................. Time Division Multiplex
TDMA .................................................................................... Time Division Multiple Access
TRD ...............................................................................Technical Requirements Document
TT&C............................................................................ Tracking, Telemetry and Command
TX .........................................................................................................Transmit/Transmitter

U
UTC .......................................................................................... Coordinated Universal Time
UW ................................................................................................................... Unique Word

V
VDU......................................................................................................... Visual Display Unit
VSWR..................................................................................... Voltage Standing Wave Ratio

W
WMO ..............................................................................World Meteorological Organization

Volume 1: System Description, Chapter 10: Glossary and Abbreviations Page: 15


Inmarsat Confidential C SDM
(Version Release CD004, CN143)

Chapter 11: Protocol for the Enhanced Pre-Assigned


Data Reporting Service

Contents

1 Introduction ............................................................................ 2

2 Slot Logical Channel ............................................................... 2


2.1 Report Length ...................................................................................................2
2.2 Report Interval ..................................................................................................2
2.3 Assignment Duration .........................................................................................3

3 Slot Logical Channel Assignment ............................................ 3


3.1 LES Initiated Assignment ..................................................................................3
Figure 1: LES Issued Assignment ...........................................................................3
3.2 MES Requested Assignment ............................................................................4
Figure 2: MES Requested Assignment ...................................................................4
3.3 Demand Assigned Mode ...................................................................................5

4 Slot Logical Channel Assignment Control ................................ 5


Figure 3: LES Issued Assignment Query / Control..................................................6

5 Data Reporting ........................................................................ 6

Volume 1: System Description, Page: 1


Chapter 11: Protocol for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN143)

1 Introduction
The enhanced pre-assigned data reporting service is intended for users who need to gather data from
MESs on a regular basis. With the ability to define a constant interval between transmissions from
each MES, pre-assigned (reserved access) TDMA operation of signalling channels can be used
instead of the normal unreserved Slotted-Aloha access scheme, thereby allowing more efficient use
of the return channel capacity.

Enhanced pre-assigned data reporting uses a dedicated management protocol to assign, and control
MESs using enhanced pre-assigned data reporting. Enhanced pre-assigned data reporting introduces
capabilities to improve performance and operational flexibility. It also makes use of the enhanced
(unreserved) data report packet formats which offer improved flexibility and data integrity.

Enhanced pre-assigned data reporting may be offered on a DNID basis and is therefore compatible
with other existing data reporting services. It may also make use of additional features and flexibility
provided by the enhanced data reporting packet formats.

An LES offering the Pre-assigned Data Reporting service must synchronise its TDM frame numbers
with UTC.

This chapter describes the protocols for the service; the packet formats are described in Volume 4.

2 Slot Logical Channel


The From-Mobile connection between a particular MES and an LES is called a 'slot logical channel'. A
slot logical channel provides an MES with one or more reserved MES signalling channel slots on a
fixed interval basis.

A particular slot logical channel has a set of attributes associated with it which describe the
connection assigned to the user. These are defined in the following subsections.

In addition to the key attributes defined below, additional low level attributes are also provided as part
of the assignment. These include; the slot number in the assigned frames for transmission, the
signalling channel and TDM channel associated with the issuing LES.

2.1 Report Length


A report consists of 1 to 4 signalling channel packets (enhanced data report format) which can contain
up to 40 bytes of user data. Thus a slot logical channel can provide a maximum of four consecutive
multi-slots for each report.

2.2 Report Interval


The report interval is given in terms of frames. There are 10,000 frames in 24 hours with the duration
of each frame being 8.64 seconds. The interval between reports can be set to one of eight preset
intervals. These intervals vary from 100 to 10000 frames.

An LES operating an enhanced pre-assigned data reporting service is not obliged to offer all possible
report intervals. The operator might restrict the intervals available to a sub-set of those defined.
Typically the LES will offer one or more slots on a signalling channel for each interval.

Note: Signalling channels do not have to be uniquely set aside for pre-assigned data reporting. They
can be shared with other services using unreserved access operation on the same signalling
channels. However, the three multi-slots prior to an assigned slot need to be reserved (whether for
another assignment or not) in order to prevent an unreserved multi-packet data report from colliding
with the pre-assigned data report.

Volume 1: System Description, Page: 2


Chapter 11: Protocol for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN143)

2.3 Assignment Duration


An assignment is valid for a duration given in terms of the number of data reports which may be
transmitted on the slot logical channel. The duration can be from one report to 7000 reports.

3 Slot Logical Channel Assignment


Slot logical channel assignments are controlled by the issuing LES. New, changed or additional
assignments may be issued at the request of the application/user on the terrestrial side or by the MES
user/application, if supported by the LES. In either case, the actual assignment parameters are
controlled by the LES.

3.1 LES Initiated Assignment


In the case of a new or changed assignment issued by the LES, the procedure is as shown in Figure
1. The assignment is sent from the LES to the MES via the NCS common channel. If the LES sends
an assignment, the assignment is stored and activated by the recipient MES. The MES responds with
a slot logical channel assignment query response/acknowledgement, echoing the parameters of the
assignment received.

Figure 1: LES Issued Assignment

MES NCS LES

Slot logical channel assignment

Slot logical channel assignment

Slot logical channel assignment acknowledgement

An MES may receive a Slot Logical Channel Assignment packet from an LES via the NCS at any time
whilst idle and tuned to the common channel. If the MES already has 4 valid assignments, or the
assignment defines a 100 frame interval or the assignment parameters are otherwise unacceptable, it
will reject the assignment by sending a Slot Logical Channel Assignment Control/Query
Response/Acknowledgement packet indicating that the assignment is rejected, and the reason for
rejection where appropriate. Otherwise, the assignment will be accepted and a positive
acknowledgement sent to the LES echoing the assignment parameters and the MES saves and

Volume 1: System Description, Page: 3


Chapter 11: Protocol for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN143)

executes the assignment; transmitting pre-assigned data reports at the next available scheduled
slot/frame/channel, once the MES is idle.

3.2 MES Requested Assignment


The MES may also request a new or changed assignment by sending a slot logical channel
assignment request directly to the LES, as shown in Figure 2. This packet may be sent when a pre-
assigned data reporting program is required. It may also be sent when a change of programming, e.g.
a different interval, is required. The required interval, number of packets per report and duration of the
assignment are sent in the request packet. If the LES is configured to allow requests from this MES, it
will respond with an assignment that may or may not match these requirements. If the LES is
configured to forbid MES originated requests from that MES it will reject the request using the short
format Slot Logical Channel Assignment. The LES may also reject the request for other reasons that
may be identified in the status code sent in the short format Slot Logical Channel Assignment. If the
LES is unable to currently handle the request it may issue a pending status which will re-initialise the
timeout at the MES allowing the LES more time to respond with an actual assignment. The
assignment will also include the remaining details such as slot number, start frame and signalling
channel. The Slot Logical Channel Assignment Request is sent using unreserved access on an LES
signalling channel. When the MES receives a valid assignment following transmission of a Slot
Logical Channel Assignment Request, it will terminate the current assignment and replace it with the
newly received assignment and respond with an acknowledgement echoing the new assignment
parameters. See the SDL in Volume 5.

Figure 2: MES Requested Assignment

MES NCS LES

Slot logical channel assignment request

Slot logical channel assignment

Slot logical channel assignment acknowledgement

In general, it is expected that most applications, particularly where the MES is unmanned, will not
issue slot logical channel assignment requests, except perhaps under exceptional circumstances, e.g.
where an assignment is about to expire or has already expired and a new assignment has not been
received.

Note that all signalling interactions will use unreserved access on an available LES signalling channel.
Only the programmed (pre-assigned) data reporting will exclusively use reserved access.

Volume 1: System Description, Page: 4


Chapter 11: Protocol for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN143)

Each assignment is associated with a LES ID and slot logical channel number. The slot logical
channel number is used to identify an assignment made to an MES. Combined with the LES ID, it is
unique for a particular assignment issued to an MES from a particular LES. Different MESs may have
the same slot logical channel number. Subsequent assignments made to the same MES will generally
have different slot logical channel assignment numbers (modulo-255). However, new or renewed
assignments may have the same slot logical channel numbers as previous expired or terminated
assignments. Multiple simultaneous or temporally overlapping assignments made to the same MES
by the same LES will always have different logical channel numbers. Slot logical channel number 00H
is reserved and not to be assigned by LESs as part of the slot logical channel number sequence. The
slot logical channel number is unrelated to, and does not have the same significance as for
messaging logical channel numbers.

MESs may have assignments issued by multiple LESs and these could in theory have the same
logical channel numbers, so logical channel numbers are also differentiated on the basis of LES ID.
An MES may have up to 4 simultaneous valid assignments that may originate from the same or
different LESs.

3.3 Demand Assigned Mode


Enhanced pre-assigned data reporting is only supported using signalling channels associated with
LES TDMs operated in permanent assigned mode. It is not supported on TDMs operated in demand
assigned mode.

4 Slot Logical Channel Assignment Control


An LES is able to exercise control over an MES using enhanced pre-assigned data reporting. This is
accomplished using the slot logical channel assignment control/query packet issued by the LES and
sent on the NCS common channel, as shown in Figure 3.

The slot logical channel assignment control/query packet is a compact packet with a series of control
fields defining a control command and/or query with or without an acknowledgement response
requested from a particular MES. Using this packet, the LES is able to control and query assignments
at MESs, though it may only get full details and be able to exercise control over assignments that
have been sent to the MES by that LES. An LES cannot control assignments issued by other LESs.
LESs are forbidden from issuing the control code (FH) to terminate all valid assignments. This control
code may only be issued from the Inmarsat NOC. Where an LES is simultaneously serving more than
one ocean region, assignment control packets for any ocean region served may be forwarded to the
NCS indicating an alternative ocean region (for which that LES also provides service). In such cases
the LES ID indicated in the assignment control packet will have a different 2-bit ocean region identifier
than the sending LES.

The query command may be used to retrieve details of a particular assignment at an MES, as defined
by the slot logical channel assignment. If the LES issues a slot logical channel assignment
control/query, the MES responds with a query response, if one has been requested, and act on any
control commands sent. An LES may control assignments at MESs, such as suspending, resuming
and terminating assignments. In addition an LES may request limited details of all valid assignments
at an MES. These operational functions are provided to ensure that LESs can manage assignments
effectively and efficiently minimising the likelihood of duplicate assignments or assignment errors and
conflicts.

When an MES receives a slot logical channel assignment control/query packet, it first checks that it
has a valid assignment with the LES initiating the packet and corresponding to the Slot Logical
Channel Number indicated. If it does, the command is implemented and an acknowledgement sent, if
one was requested, echoing the current assignment parameters. If the LES issuing the control packet
is not the one for which the MES has a current assignment, or the slot LCN is not valid, or the
command cannot be implemented, it will respond with a Slot Logical Channel Assignment Query
Response/Acknowledgement packet with a rejection indicated in the sub-type field and a reason code

Volume 1: System Description, Page: 5


Chapter 11: Protocol for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN143)

identifying the reason for rejection. If the Slot Logical Channel Assignment Control/Query packet does
not have a control code, it is a query (Q flag set) and may require either that the MES send details of
the specified assignment, or its schedule of currently active assignments, depending on the setting of
the S (schedule) flag. In the former case the MES sends the Slot Logical Channel Assignment Query
Response/Acknowledgement packet with the appropriate assignment parameters to the requesting
LES (only if a corresponding valid assignment exists with that LES, otherwise it is rejected). In the
latter case the MES responds with a Slot Logical Channel Assignment Schedule packet. This
provides limited, but sufficient information concerning the MES’s currently active assignments. These
details are limited to the operational information concerning the next frame of transmission, the
interval and remaining data reports to be sent under each assignment.

An MES with a pre-programmed slot logical channel cannot clear its channel. The LES may clear a
slot logical channel by sending a Slot Logical Channel Assignment Control/Query Packet with the
control field indicating "Terminate assignment". The MES terminates Data Reporting.

If the network enters restoration mode operation and the TDM radiating on the common channel
frequency indicates a joint NCS/LES TDM, all MESs shall terminate pre-assigned data reporting.

If an MES logs out of an ocean region, or logs into another ocean region, any active assignments
within that ocean region are immediately suspended.

Figure 3: LES Issued Assignment Query / Control

MES NCS LES

Slot logical channel assignment


control/query

Slot logical channel assignment


control/query

Slot logical channel assignment control/query response

5 Data Reporting
On being enabled to start pre-assigned data reporting, the MES is free to transmit in its pre-assigned
slot from the allocated starting frame. Before the frame number on the NCS common channel
matches the allocated starting frame, the MES retunes to the given TDM and checks that the bulletin
board origin ID corresponds to the pre-programmed LES ID. If they do not match, then the data report
will be abandoned. When the programmed start frame number and the TDM frame number match and
if the associated slot state marker indicates that the slot is reserved, the MES will begin its data report
in the pre-defined slot using enhanced data report packets. Packet formats are given in Volume 4.

Volume 1: System Description, Page: 6


Chapter 11: Protocol for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN143)

The associated slot state marker on the TDM is used to feed back the result of the transmission in the
normal manner.

If any one packet of a multi-packet Pre-assigned Data Report is not received correctly or there is any
other problem with the Reserved status, SCD decode, Bulletin board decode, etc., the Data Report is
abandoned. Any remaining reserved slots are unused. The entire Data Report may be re-sent using
the unreserved access Enhanced Data Reporting service. The re-transmission bit is set to indicate
that it is a pre-assigned data report re-transmission. The control field will indicate the corresponding
slot logical channel number and the frame number of the lost scheduled transmission enabling the
LES to identify the report in sequence, should this be required. It should be noted that the payload
capacity of the EDR in this case will be 3 bytes less than that achievable for a 4 packet enhanced pre-
assigned data report so this technique is only appropriate where there are at least three bytes free in
the fourth packet of the enhanced pre-assigned data report. If this requirement cannot be met, then an
alternative re-transmission strategy may need to be employed. For example, this could be to use
messaging, or to place the data into 2 unreserved enhanced data reports, transmitted one after the
other.

On reception of a pre-assigned data report or pre-assigned data report re-transmission, the LES will
check the MES ID against the details it has for that assignment and take any remedial action
necessary should there be an error or inconsistency.

Pre-assigned data reporting may not interrupt a message transfer from the MES; that is, once an MES
has received a logical channel assignment giving the frame offset and start slot for a message
transfer, a data report may not interrupt the message transmission. Similarly, if a Class 2 MES which
is not in the EGC receive only mode is receiving an EGC message addressed to that MES, a pre-
assigned data report may not interrupt the EGC reception.

Volume 1: System Description, Page: 7


Chapter 11: Protocol for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 1: Introduction

Contents

1 Introduction ............................................................................ 2
1.1 The Inmarsat-C System ....................................................................................2
Figure 1: The Inmarsat-C Communication System .................................................3
1.2 Definition of Terms ............................................................................................3
1.2.1 Inmarsat-C Protocols .....................................................................................3
1.2.2 Inmarsat-C Services.......................................................................................4
1.2.3 Inmarsat-C Applications .................................................................................5

2 Interconnecting Networks........................................................ 5

3 Terrestrial User Facilities ........................................................ 6

4 User Applications .................................................................... 6

Volume 2: User Services, Part 1: Services and Facilities, Page: 1


Chapter 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
The Inmarsat-C Communications System can be used, either alone or in conjunction with other
systems, for a range of applications. The information in this volume is intended to assist equipment
manufacturers, LES operators, service providers and application developers to design and implement
the most popular services and applications demanded by users in a such a manner as to ensure
consistency and compatibility of services throughout the network.

The volume is split into two parts. Part 1, entitled Services and Facilities, describes the various
Inmarsat-C services and facilities and is largely built upon the protocols described in Volume 1. No
additional system requirements are included in this volume beyond that contained in other volumes of
the Inmarsat-C System Definition Manual, except in the form of advice, guidance or recommendations
for the implementation of specific services or applications. Further supporting material has been
provided where it has been found useful.

The structure of each chapter in Part 1 is generally as follows:

- Introduction/Description of service

- Inmarsat-C Protocol/protocol related matters

- Requirements and/or recommendations for Mobile Earth Stations

- Requirements and/or recommendations for Land Earth Stations

- Appendices (where appropriate)

Other sections may also be included where required. Each chapter also includes extensive references
to other volumes of the SDM and other relevant material, such as CCITT Recommendations.

Part 2 contains a number of Application Notes. These Application Notes are intended to convey ideas,
suggestions, recommendations and other information relevant to the development of user applications
based on Inmarsat-C. Further Application Notes for inclusion in this volume may be prepared in the
future as new applications of Inmarsat-C emerge.

Part 3 describes a set of extensions to the CMC (Common Messaging Call). CMC Application
Programming Interface (API) defines a standard programming interface for applications to access
services supported by most messaging systems, but it also provides the capability to extend the
interface to support additional messaging features. This part of Volume 2 defines a set of extensions
to the CMC API to provide support for the full range of Inmarsat-C services (excluding certain
maritime safety related services) and also specifies how particular CMC API features should be
implemented using Inmarsat-C.

1.1 The Inmarsat-C System


The Inmarsat-C Communications System can be used to establish a virtual connection between two
parts of a user application. At least one of the parts of this application may reside at the Inmarsat-C
MES. The other part may either reside at another MES, or in another form of user system. The user
would use an Inmarsat-C service, or a combination of the Inmarsat-C services, and an
interconnecting network between the Inmarsat-C system and the user system to implement the virtual
connection.

For a detailed description of the various elements of the Inmarsat-C system and how they interact,
refer to Volume 1. For details of the various Earth Station requirements, refer to Volume 3.

Figure 1 shows how the Inmarsat-C System may be linked with other systems using various
interconnecting networks.

Volume 2: User Services, Part 1: Services and Facilities, Page: 2


Chapter 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: The Inmarsat-C Communication System

Inmarsat-C
System

User
Satellite LES
System

Interconnecting
Inmarsat-C NETWORK
Service

NCS MES

User
User Vir Application
Application tua
l conn ation
ectio
n of user applic

Inmarsat-C Services:Store and Interconnecting Networks:Telex User Systems: Telex Machine,


Forward Messaging, Data PSDN, PSTN, Private Networks, PSDN Terminal, PSTN
Reporting, Polling, Pre-assigned Leased Lines, Other Inmarsat Terminal, Fax Machine, Minitel
Data Reporting, Distress Systems, Inmarsat-C. Terminal, User Computers,
Alerting, Enhanced Group Call, Inmarsat-A/B/C/M /Aero
Land Mobile Alerting. terminals.

1.2 Definition of Terms

1.2.1 Inmarsat-C Protocols


For the purpose of this volume the following definition applies:

Protocol: The interaction via the Inmarsat space segment between the various ground segment
elements of the Inmarsat-C System in order to provide communications functions.

An Inmarsat-C Protocol specifies the functions performed by the interacting elements of the network
(LES, MES and NCS) in order to enable an LES to offer a service. The basic Inmarsat-C
communication protocols are as follows:

a) Store and Forward Messaging protocol

b) Prefixed Store and Forward Messaging protocol

c) Data Reporting protocol

d) Polling protocol

e) Pre-assigned Data Reporting protocol

f) Alerting protocol

Volume 2: User Services, Part 1: Services and Facilities, Page: 3


Chapter 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

g) Enhanced Group Call protocol

Included as part of the store and forward messaging protocol are other functions that are required for
network management and control, such as logging in/out, Performance Verification Testing (PVT) and
confirmation/message status request and delivery.

Not all of these protocols are mandatory for LESs and MESs.

The following is an example of the Basic From-Mobile message transfer Protocol:

From To Protocol Packets Comments


NCS All MESs Bulletin Board, Network Config. [Network] LES Channels and services
MES LES Assignment Request [Set-up] Type of service and address
LES NCS MES Status (busy) [Set-up]
LES MES Logical Channel Assignment [Set-up] Time/channel for transmission
MES LES Message data [Transfer] Data transfer from MES
LES MES Clear [Clear] No acknowledgement needed if OK
LES NCS MES Status (idle) [Clear] Call completed

1.2.2 Inmarsat-C Services


The Inmarsat-C protocols listed above may be used to support a range of services. For the purpose of
this volume the following definition applies:

Service: The provision of an end-to-end communication link by an LES making use of the
Inmarsat-C protocols.

A service operates between one or more mobile subscribers and one or more terrestrial or mobile
subscribers. A service may employ more than one Inmarsat-C protocol. Services are provided by LES
operators and/or their agents.

Examples of services are as follows:

a) Telex store and forward messaging service

b) PSDN store and forward messaging service

c) PSTN (Fax or modem) store and forward messaging service

d) X.400 store and forward messaging service

e) EGC SafetyNETSM service

f) EGC FleetNETSM service

g) Data Reporting service

h) Polling service

i) Maritime Distress Alerting service

j) Land Mobile Alerting service

Not all of these services are mandatory for LESs and MESs. For details of mandatory and optional
services refer to Volume 1, Chapter 1.

Volume 2: User Services, Part 1: Services and Facilities, Page: 4


Chapter 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

LES operators and service providers may make use of these services and other Inmarsat-C services
and protocols to offer customised, value added services and applications, see 1.2.3 below.

The following is an example of Mobile to Telex message delivery service:

From To Service Protocols Comments


MES MES [Telex message entry] Includes telex address
Operator
MES LES From-Mobile message transfer Transfer to LES successful
LES Telex [Telex message successful] Assume delivery to telex addressee
addressee successful
LES MES Confirmation (if requested by MES) Positive delivery notification

1.2.3 Inmarsat-C Applications


The Inmarsat-C services listed above may be used to support user level applications. For the purpose
of this volume the definition of an application is as follows:

Application: The use or purpose to which the Inmarsat-C Service(s) is (are) to be put.

An Inmarsat-C application makes use of Inmarsat-C services and protocols to perform very specific
functions. Applications are generally the responsibility of the end user(s).

For example Telex, as referred to in this SDM, defines an Inmarsat-C service (using the store and
forward messaging protocol) which provides access to/from an Inmarsat-C mobile from/to the
terrestrial telex network. An application of this service could be ship weather reporting to a
meteorological bureau. Such an application could be implemented a number of ways; for instance:

i) manually; that is the data is entered manually at the MES and is retrieved and handled
manually at the receiving destination (the meteorological bureau);

ii) automatically at either end; whereby the data is acquired automatically (e.g., from instruments)
and transmitted with no human intervention, or it is entered manually at the MES in a pre-
defined format for automatic recovery and machine processing at the destination, or

iii) fully automatically; whereby there is no human intervention at either end.

As a second example, the Position Reporting Service (described in Part 2, Application Note 2) could
form the basis of an application utilising the Data Reporting and Polling services, which make use of
the data reporting and polling protocols, for vehicle or ship fleet management.

2 Interconnecting Networks
The entry point from the interconnection networks into the Inmarsat-C System will always be through
the LES. Logically, the interconnection interface is a network - Inmarsat-C System interface, but
because of the single entry point into the Inmarsat-C System, the interface is often referred to as LES
- network interface, or simply as LES terrestrial network interface (e.g. LES telex interface).

Telex is the mandatory interconnection network, but a variety of networks are being offered by LES
operators. Where gateways between different networks exists, the interconnection network may be of
two or more different types. It is assumed that the interconnection network specification will conform
to the appropriate CCITT Recommendation. This is the LES owners responsibility, and outside the
control of Inmarsat.

The following is a list of possible interconnecting networks:

a) Telex (refer to Chapter 2)

Volume 2: User Services, Part 1: Services and Facilities, Page: 5


Chapter 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

b) PSTN (refer to Chapter 7)

c) PSDN (refer to Chapter 8)

d) ISDN

e) Private Networks

f) Leased Lines

g) Other Inmarsat Systems

h) Inmarsat-C

The actual interconnecting networks available to a particular terrestrial user will depend on their local
(terrestrial) network service provider and agreements between that service provider and Inmarsat-C
LES operators.

3 Terrestrial User Facilities


The least complex user system will be a terminal connected to the interconnecting network. It is up to
the user to define a more complex user system depending on their requirements.

The following is a list of possible user systems:

a) Telex Machine/Store and Forward message switch

b) PSDN Terminal

c) PSTN Terminal (e.g. Personal Computer + V.22 bis modem)

d) Minitel Terminal

e) Inmarsat-A/B/C/M/Aero Terminal

f) User Computers/LAN systems

g) Facsimile machines (PSTN)

4 User Applications
There is no limit to the variety of user applications that can be envisaged. Some typical user
applications are listed below:

a) Message/data transfer

b) Message/data broadcast to mobiles

c) Search and Rescue Co-ordination

d) Position reporting

e) Data logging and remote monitoring and control (SCADA) applications, e.g. weather
monitoring, water supply management etc.

f) Non - Latin alphabet messaging

Volume 2: User Services, Part 1: Services and Facilities, Page: 6


Chapter 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

g) Document/file transmission

h) Fixed thin route communications

i) E-Mail

j) Electronic Data Interchange (EDI)

Applications are not defined in the Inmarsat-C SDM. However, Part 2 of this volume does include a
number of Application Notes. These Application Notes do not present detailed definitions of
applications, but in some cases sufficient general details may be provided to form the basis of an
application; in particular guidance may be offered in respect of packet formatting, MES and/or LES
technical requirements (where these may be affected) and interfacing issues.

Volume 2: User Services, Part 1: Services and Facilities, Page: 7


Chapter 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 2: Telex Interconnection

Contents

1 Description of Service ............................................................. 2

2 Inmarsat-C Protocol Used ........................................................ 2

3 Requirements and Recommendations for Mobile Earth Stations2

4 Requirements and Recommendations for Land Earth Stations.. 2


4.1 Single Stage Access .........................................................................................3
4.2 Two Stage Access ............................................................................................3
4.3 Telex Message Header Format .........................................................................4
4.4 LES Non-delivery Codes ...................................................................................4
4.5 Two Digit Prefix Code Addressing.....................................................................6

Volume 2: User Services, Part 1: Services and Facilities, Page: 1


Chapter 2: Telex Interconnection
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Description of Service
Telex was the first service defined as mandatory for all Inmarsat-C LESs. A telex interconnection at
an LES allows Inmarsat-C Mobile users to send and receive telex messages from the international
telex network.

Despite the fact that telex is rapidly being replaced with more modern communications technology in
many parts of the world, the technology associated with telex communications is considered "mature"
and is still used very widely, including in many third world countries. It is access to this global
infrastructure that has given Inmarsat-C its appeal to many users, particularly in the maritime
community.

2 Inmarsat-C Protocol Used


The telex message service makes use of the Inmarsat-C store and forward message transfer
protocols. Note that telex can be used as the interconnecting network for other Inmarsat-C services,
e.g. data reporting and polling. However for the purpose of this chapter it is assumed that telex is
being used for messaging only.

The protocols are described in detail in Volume 1. In particular Volume 1, Chapter 4.

Packet definitions are included in Volume 4. The following references in Volume 4 are particularly
relevant:

Volume 4, Chapter 3, 4 and 5.

Volume 4, Chapter 12.

The SDL figures are given in Volume 5.

3 Requirements and Recommendations for Mobile Earth Stations


The following requirements are relevant:

Volume 3, Part 2, Chapter 2.

All MES types provide full telex addressing functions using the IA5 alphabet. MESs may also support
the 5-bit ITA 2 alphabet, though this is optional (refer also to Chapter 9).

4 Requirements and Recommendations for Land Earth Stations


The following requirements are relevant:

Volume 3, Part 1, Chapter 2, Sections 5

The following CCITT Recommendations are also relevant to LES - telex network interfacing:

F.60 Operational provisions for the international telex service

F.69 Plan for telex destination codes

F.72 International telex store and forward - general principles and operational aspects

F.125 Telex numbering plan for the mobile-satellite services of Inmarsat

Volume 2: User Services, Part 1: Services and Facilities, Page: 2


Chapter 2: Telex Interconnection
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

F.126 Selection procedures for the Inmarsat mobile-satellite telex service

F.127 Operational procedures for interworking between the telex service and the service offered by
nmarsat-C system

S.1 International Telegraph Alphabet No. 2

S.18 Conversion between International Telegraph Alphabet No. 2 and International Alphabet No.5

T.50 International Alphabet No. 5

U.1 Signalling conditions to be applied in the international telex service (type A and B signalling)

U.11 Telex and gentex signalling on intercontinental circuits used for intercontinental automatic
transit traffic (type C signalling)

U.12 Terminal and transit control signalling system for telex and similar services on international
circuits (type D signalling)

U.80 International telex store and forward access from telex

U.81 International telex store and forward - delivery to telex

U.82 International telex store and forward - interconnection for telex store and forward units

U.208 The international telex service - interworking with the Inmarsat-C system using one stage
selection

4.1 Single Stage Access


Single stage access is described in CCITT Recommendation U.208.

Every Inmarsat-C MES has a unique Inmarsat Mobile Number (IMN). It is a 9 digit number in
accordance with CCITT Recommendation F.125. For all Inmarsat-C MESs the leading digit (referred
to as the "T" digit) is always 4.

To send a message from the terrestrial telex network to a MES via a LES using single stage
addressing, the user should send the message to the following telex address:

58STX1X2X3X4X5X6X7X8

where S following the 58 is the ocean region identifier digit (1 for AOR-E, 2 for POR, 3 for the IOR and
4 for AOR-W). The code 58S is the F.125 code for Inmarsat. The digits TX1X2X3X4X5X6X7X8 comprise
the Inmarsat Mobile Number (IMN). For full details of the Inmarsat-C Numbering Plan refer to Volume
3, Part 1, Chapter 3.

Routing arrangements in each country are a national matter and outside the control of Inmarsat. The
answerback received will be the answerback assigned to that MES at the time of commissioning, and
not the LES answerback.

4.2 Two Stage Access


As an alternative to single stage selection, the LES may accept calls from the terrestrial network using
a two stage selection procedure. This requires the LES to respond to terrestrial network originated
calls by requesting the address and other information. Two stage selection is also required for the
implementation of services such as multi-addressee calls, follow-on calls and scheduled delivery
calls. Most of the elements of two stage access are described in CCITT Recommendation U.80.

Volume 2: User Services, Part 1: Services and Facilities, Page: 3


Chapter 2: Telex Interconnection
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Telex users in some countries may not be able to send messages using single stage access. In such
cases it should be possible for users to set up two stage access with an LES(s). For security reasons
users sending messages using two stage access are generally assigned a PIN (Personal
Identification Number) or some form of user identification which they must enter before access to the
service is granted.

The two stage access procedure is not necessarily uniform from one LES to another.

The general procedure for calling an Inmarsat-C MES using two stage access is as follows:

i) The operator dials the number of the LES through which an arrangement has been established.
Including the country code if required.

ii) On making connection the LES will respond with its own answerback and may request the
operator to enter a PIN (or user identity, or both).

iii) The operator may then be requested to enter the type of service required (perhaps from a
menu of options) and a list of addressed MESs.

iv) The operator may then be requested to enter the message text and terminate using an end of
message sequence which may typically be NNNN or ++++. If an acknowledgement of
successful delivery is required the user may need to enter NNNNACK (or ++++ACK).

4.3 Telex Message Header Format


It is common practice for LES operators/telex service providers to insert a message header in To-
Mobile and From-Mobile telex messages. This header generally includes service information such as:

- Service provider/Ocean region identifier

- LES ID

- Date

- Time (UTC)

- Message identifier (Message Reference Number)

This information is generally restricted to the first line of the message text.

For further information concerning message headers, refer to Chapter 9, Appendix 1: LES Code of
Practice for Message Headers.

4.4 LES Non-delivery Codes


The store and forward messaging protocols allow Mobile users to request message delivery status.
The user may request this during call set up, in which case a confirmation will be issued following call
completion, or the request may be sent subsequently, after transmission of the message.

The Non-delivery Code field in a Message Status Descriptor or Confirmation packet holds a 1-3
character failure code formatted as IA5 with odd parity. The meaning of the codes are LES specific,
but it is mandatory that the following codes are used (Volume 3, Part 1, Chapter 2, Section 5.7.3
refers):

ABS* Absent subscriber

BK* Message aborted

Volume 2: User Services, Part 1: Services and Facilities, Page: 4


Chapter 2: Telex Interconnection
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

BMC* No end of message or end of transmission received

DER* Out of Order

DTE Remote DTE clearing

EOS Element of service not subscribed (X.400)

FMT* Format error

IAB* Invalid answerback

INC Inconsistent Request (X.400)

INF* Call the Network Information service

INV Invalid Call

ITD* Awaiting delivery

LDE* Maximum message length exceeded

LPE Local Procedure Error

NA* Access Barred

NC* Network Congestion

NCH* Subscriber's number has been changed

NP* Not Obtainable

NRC Reverse charging acceptance not subscribed

OCC* Number Busy

RIS Recipient improperly specified (X.400)

RDI* Redirected call

RPE Remote Procedure Error

RSB† Retransmission still being attempted

TMD† Maximum number of addresses exceeded

UNK Unknown status (e.g. when the Logical channel number is zero)

Codes marked * are identical to telex code expressions from CCITT Recommendation F.60. Codes
marked † are similar, but not identical, to telex code expressions in F.60. Codes specific to X.400 are
identified.

Other codes may also be used. These are LES specific. LES operators should make available to
users a complete list of non-delivery codes and their meanings.

Volume 2: User Services, Part 1: Services and Facilities, Page: 5


Chapter 2: Telex Interconnection
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.5 Two Digit Prefix Code Addressing


For GMDSS purposes, the following 2-digit codes are defined (also refer to CCITT Recommendation
F.126). It is a national matter whether all of these services are provided by a particular LES. Further
codes are provided in F.126.

for maritime safety services -

32 Medical Advice Used for requesting medical advice.

38 Medical Assistance Used for requesting medical assistance.

39 Maritime Assistance Used for requesting maritime search and rescue


assistance.

41 Meteorological reports Necessary for ease of addressing weather reports


from ships to meteorological centres.

42 Navigational Hazards and warnings Used for making urgent navigational/


meteorological danger reports.

43 Ship position reports Used for routing of messages to ship safety


reporting systems.

for general utility -

31 Maritime enquiries Desirable for requesting information including


service offerings.

33 Technical assistance Desirable for addressing technical enquiries to


appropriate personnel.

37 Time and charges requested Desirable for mobile operator when sending traffic
at end of call for a third party.

Note that for an MES to send a message to a two digit code, the MES would set the destination
network to Special Access Code and not telex. The address would be the two digit code.

Volume 2: User Services, Part 1: Services and Facilities, Page: 6


Chapter 2: Telex Interconnection
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 3: Enhanced Group Call Services

Contents

1 Description of Service ............................................................. 2

2 The EGC Protocol .................................................................... 2


Figure 1: The EGC Receive Protocol ......................................................................4

3 Requirements and Recommendations for Mobile Earth Stations5

4 Requirements and Recommendations for Land Earth Stations.. 5

Volume 2: User Services, Part 1: Services and Facilities, Page: 1


Chapter 3: Enhanced Group Call Services
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Description of Service
Enhanced Group Call (EGC) is a message/data broadcast service within the Inmarsat-C System.
Messages are broadcast on NCS Common Channel TDMs. Reception may be by means of an EGC
receiver (Class 0 Inmarsat-C MES) operating either stand-alone or in conjunction with an Inmarsat
MES. Inmarsat-C MESs are capable of receiving EGC messages continuously (in the case of a Class
3 MES or a Class 2 MES in the EGC receive only mode of operation) or when idle (in the case of a
Class 2 MES in the Inmarsat-C traffic mode of operation).

There are three types of Enhanced Group Call broadcast Services as follows:

SafetyNETSM Only available to SafetyNETSM Information Providers, registered by the IMO for GMDSS
purpose (refer to Chapter 4). Examples of registered users include Maritime Rescue Co-ordination
Centres and Meteorological Bureau's.

FleetNETSM Available for use by commercial Information Providers (refer to Chapter 5).

System Restricted, and use is covered by Inmarsat System Operation Procedures.

Service
Service Name C3 Code* Service Type
Code (Address)
00 General Call none System
02 Group Call 5 digits FleetNETSM
04 Urgency message, NAV warning to rectangular area 12 digits SafetyNETSM
11 INMARSAT System Message 2 digits System
13 Coastal Warning 4 digits SafetyNETSM
14 Shore-to-Ship Distress Alert to circular area 10 digits SafetyNETSM
23 EGC System Message 9 digits System
24 Urgency message, MET/NAV Warning to Circular Area 10 digits SafetyNETSM
31 MET/NAV Warning or MET Forecast to NAVAREA 2 digits SafetyNETSM
33 Download Group Identity (ENID) 9 digits System
34 SAR Co-ordination to rectangular area 12 digits SafetyNETSM
44 SAR Co-ordination to circular area 10 digits SafetyNETSM
72 Chart Correction Service 5 digits FleetNETSM
73 Chart Correction Service for fixed areas 7 digits SafetyNETSM

* Refer to Section 4 below for definitions of C codes.

It is possible that other services and other message types within each service may be defined in the
future.

The service code is a hexadecimal number when transmitted within the Inmarsat-C network, although
the EGC call originator may send the code as a decimal C code over the terrestrial network to an LES
(see Section 4). The second (hex) digit of the service code is used in the EGC satellite protocol to
indicate the length of the address field (in bytes) in the header of the EGC packet.

2 The EGC Protocol


A description of the EGC protocol is given in Volume 1, Chapter 4, Section 13.

The following references are relevant:

Volume 1, Chapter 4

Volume 4, Chapter 3, Section 3.10

Volume 4, Chapter 6

Volume 2: User Services, Part 1: Services and Facilities, Page: 2


Chapter 3: Enhanced Group Call Services
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

A summary description of the EGC (satellite) protocol at the receiver is given below:

The EGC broadcast protocol allows messages to be processed based on the following criteria:

i) Service Type (i.e. SafetyNETSM; or FleetNETSM): Receivers may be set up to receive only
SafetyNETSM or only FleetNETSM, or both.

ii) Service Code/Message Type: Receivers may be set up to receive only certain service codes.
The service code also indicates the type and length (in bytes) of the address.

iii) Address Validity: The message address must be valid for the MES in accordance with the
addressing rules for that particular service code.

iv) New Message: The EGC protocol includes a mechanism for allowing repeated messages,
which have previously been received error free, from being processed subsequently.

v) New Packet: Missing packets or packets received with bad checksums (but good header
checksums; i.e. packets with mutilated characters) may be received during subsequent re-
broadcasts of the original message.

A flowchart representing this is shown in figure 1.

Volume 2: User Services, Part 1: Services and Facilities, Page: 3


Chapter 3: Enhanced Group Call Services
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: The EGC Receive Protocol

Start

N
EGC Service
handled?

one Y
Reject
test

N
Service code
handled?

N Reject
Address
valid?

N
New message
?

Y N Reject
New packet
?

Process packet

Volume 2: User Services, Part 1: Services and Facilities, Page: 4


Chapter 3: Enhanced Group Call Services
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3 Requirements and Recommendations for Mobile Earth Stations


The following references are relevant:

Volume 3, Part 2, Chapter 2

Volume 3, Part 2, Chapter 8

The specific requirements for EGC receivers and MESs providing EGC functionality are in Volume 3,
Part 2, Chapter 8.

4 Requirements and Recommendations for Land Earth Stations


The requirements for LESs relating to EGC are given in Volume 3, Part 1, Chapter 2, Section 9.
The following references are relevant:

Volume 3, Part 1, Chapter 1

Volume 3, Part 1, Chapter 2, Sections 5.8.3 and 9

Volume 3, Part 1, Chapter 3

Information Providers wishing to have an EGC message transmitted via the Inmarsat-C system will
use an appropriate terrestrial service such as the Telex or Packet Network (PSDN) to gain access to
the required LES. CCITT Recommendation F.127 describes the operational procedures for telex.

In general, access to EGC services is only available to authorised and registered users.

After gaining access to the LES, the Information Provider must give EGC Packet address information
so that the right groups of MESs receive the EGC message. The EGC packet address information is
sent by the Information Provider by means of a special message header at the beginning of the
message. The message header consists of 5 (or 6) special codes called C codes. The codes may be
prefixed by additional characters to indicate that the message is an EGC transmission. The
functionality that the C codes define needs to be maintained regardless of the LES interface chosen.

The following generalised message header format using C codes is used.

C codes transmitted to the land earth station are: (C0) C1 C2 C3 C4 C5:

Where:

(C0 is an optional ocean region identifier code - 1 digit)

C1 is the priority code - 1 digit

C2 is the service code - 2 digits

C3 is the address - up to 12 digits

C4 is the repetition rate - 2 digits

C5 is the presentation code - 2 digits

A digit in this context means an alpha-numeric character received from the terrestrial network. The
optional C0 code is used to identify the ocean region the message is intended to be transmitted to.
This is used where an LES may serve more than one ocean region.

Volume 2: User Services, Part 1: Services and Facilities, Page: 5


Chapter 3: Enhanced Group Call Services
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The meanings of the C codes are explained in Volume 3, Part 1, Chapter 2, Section 9.

Volume 2: User Services, Part 1: Services and Facilities, Page: 6


Chapter 3: Enhanced Group Call Services
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 4: SafetyNETSM

Contents

1 Description of Service ............................................................. 2

2 Inmarsat-C Protocol Used ........................................................ 2


2.1 SafetynetSM Addressing ......................................................................................3
2.1.1 Pre-defined Areas: NAVAREAS .....................................................................3
2.1.2 Pre-defined areas: Coastal NAVTEX Coverage Areas ..................................3
2.1.3 Absolute areas: Rectangular Areas ...............................................................3
2.1.4 Absolute areas: Circular Areas ......................................................................4
2.2 Message Types .................................................................................................4
2.2.1 NAV Warnings ...............................................................................................4
2.2.2 Coastal Warnings ...........................................................................................4
2.2.3 Shore-to-Ship Distress Alerts .........................................................................4
2.2.4 Meteorological Forecasts and Warnings ........................................................4
2.2.5 SAR Co-ordination .........................................................................................4
2.2.6 Urgency Messages ........................................................................................4
2.2.7 Chart Correction Service for Fixed Areas.......................................................4

3 Requirements and Recommendations for Ship Earth Stations .. 5

4 Requirements and Recommendations for Land Earth Stations.. 5


Appendix 1: NAVAREA Determination from Absolute Geographical Location ........6
Appendix 2: Determination of the Distance Between Two Known Points on the
Earth's Surface....................................................................................9

Volume 2: User Services, Part 1: Services and Facilities, Page: 1


Chapter 4: SafetyNETSM
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Description of Service
SafetyNETSM is an Inmarsat Enhanced Group Call (EGC) service provided primarily for the
dissemination of maritime safety information (MSI), such as Shore-to-Ship distress alerts, weather
forecasts and coastal warnings.

The SafetyNETSM service makes use of a flexible addressing techniques to allow the reception of
messages from a variety of service providers depending on the particular requirements of the user.

Access to SafetyNETSM services is limited to registered authorised users, for example Maritime
Rescue Co-ordination Centres and Meteorological bureaux.

The message types available within the service are as follows:

- Urgency messages, NAV Warnings to rectangular areas (service code 0416)

- Coastal Warnings (service code 1316)

- Shore-to-Ship Distress Alerts to circular areas (service code 1416)

- Urgency Messages, MET/NAV warnings to circular areas (service code 2416)

- MET/NAV Warnings or MET Forecasts to fixed MET/NAVAREAS (service code 3116)

- SAR Co-ordination to rectangular areas (service code 3416)

- SAR Co-ordination to circular areas (service code 4416)

- Chart correction service for fixed areas (service code 7316)

The aim of this note is to assist manufacturers in their implementation of SafetyNETSM service
receivers, in particular concerning Coastal NAVTEX area, rectangular and circular area and
NAVAREA addressing and related issues.

For further information on the SafetyNETSM service, refer to the latest issue of the International
SafetyNETSM Manual available from the IMO, London.

For general information on the implementation of Inmarsat EGC services, refer to Chapter 3 of this
volume.

2 Inmarsat-C Protocol Used


The Inmarsat-C EGC protocol is used to support the SafetyNETSM service.

The following references are relevant:

Volume 1, Chapter 4, Section 3.2.6

Volume 4, Chapter 3, Section 3.10

Volume 4, Chapter 6, Section 3.9

Also refer to Chapter 3 of this volume.

Volume 2: User Services, Part 1: Services and Facilities, Page: 2


Chapter 4: SafetyNETSM
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.1 SafetynetSM Addressing


The SafetyNETSM service employs geographical area addressing. There are four methods of
SafetyNETSM area addressing as follows:

(i) Pre-defined (fixed) area addressing, such as NAVAREAS, and

(ii) Coastal NAVTEX service coverage areas.

(iii) Absolute area addressing such as Rectangular areas, and

(iv) Circular areas.

The addressed area may be expressed in terms of a fixed, pre-defined area such as the NAVAREA
(i), or Coastal NAVTEX service coverage area (ii), or in terms of an absolute geographical address.
An absolute geographical area address is a representation of a closed boundary on the surface of the
earth given in the address field of the message header. EGC receivers recognise two forms of
absolute geographical addressing: rectangular (iii) and circular (iv). Each form of absolute
geographical address is specified in terms of an absolute position in latitude and longitude and further
parameters which completely specify the boundary of the addressed area. EGC receivers lying within
an addressed area boundary will then process the messages directed to that area.

The type of address used in the header of an EGC packet is uniquely determined by the service code
field.

2.1.1 Pre-defined Areas: NAVAREAS


NAVAREAS are defined by the IMO, IHO and WMO. Appendix 1, Figure 1 shows the definition of
these areas (as of 1992). Appendix 1 also includes a means for approximating the NAVAREA
definitions so that SESs may automatically determine their NAVAREA from latitude and longitude co-
ordinates.

Other types of fixed area may be defined in the future, for example for the SafetyNETSM Chart
Correction service (code 7316). Refer to section 2.2.7 below.

2.1.2 Pre-defined areas: Coastal NAVTEX Coverage Areas


NAVTEX messages are conventionally broadcast from Coast Radio Stations (CRSs) to one of several
zones within its coverage area. Zones are identified by a letter in the range A-Z and different radio
stations can share the same IDs without ambiguity since their coverage areas do not overlap.
However, some ambiguity could arise where each ship receives re-broadcast messages from all
CRSs situated within it's ocean region. This problem is resolved by specifying the zone ID plus the
NAVAREA in which it is situated. For example, the NAVTEX address (XIV, A, B) indicates a
meteorological warning (message type B) to vessels in the coverage area of transmitter A in
NAVAREA XIV.

The current NAVAREA can be determined automatically as described in Appendix 1. However,


encoding of the NAVTEX zones is more difficult and it is recommended that the user inputs the
desired zone(s) manually.

2.1.3 Absolute areas: Rectangular Areas


For rectangular area addressing, the addressed area is defined in terms of the South Westerly corner
point (latitude and longitude) and the rectangle Northerly and Easterly extents. Messages received
using this form of addressing are processed if the MES position lies on the boundary of, or within, the
rectangle defined in the address.

Volume 2: User Services, Part 1: Services and Facilities, Page: 3


Chapter 4: SafetyNETSM
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.1.4 Absolute areas: Circular Areas


For circular area addressing, the addressed area is defined as a centre point, specified in terms of its
latitude and longitude co-ordinates, and a radius in nautical miles (1 Nmi = 1852 m).

In order to determine if a circular area address is valid it is necessary to determine the distance from
the SESs known position to the position defined as the centre of the circular address. The distance
may then be compared to the radius sent in the circular area address. The address is considered
valid if this distance is less than or equal to the radius also sent in the circular area address.

Any error in estimating the distance from the centre of the addressed area should be inclusive (i.e., err
on the low side) and preferably within +0/-5 % of the actual distance.

An algorithm for calculating this distance is described in Appendix 2.

2.2 Message Types


The following summarises the various message types and associated addressing for the SafetyNETSM
service.

2.2.1 NAV Warnings


Navigational warnings as sent using service code 0416 addressed to rectangular areas, code 2416
addressed to circular areas, and code 3116 addressed to fixed NAVAREAS.

2.2.2 Coastal Warnings


Messages using service code 1316 are Coastal warnings addressed to NAVTEX service coverage
areas within specified NAVAREAS.

2.2.3 Shore-to-Ship Distress Alerts


Messages using service code 1416 are Shore-to-Ship Distress Alerts, and are addressed to Circular
areas.

2.2.4 Meteorological Forecasts and Warnings


Messages using service codes 2416 and 3116 may be Meteorological Forecasts and Warnings.
Service code 2416 uses circular area addressing. Service code 3116 uses NAVAREA addressing.

2.2.5 SAR Co-ordination


Search and Rescue (SAR) Co-ordination messages use service code 3416 (rectangular areas) and
4416 (circular areas).

2.2.6 Urgency Messages


Messages from Rescue Co-ordination Centres of an urgent nature may use service code 0416 when
addressed to rectangular areas and code 2416 when addressed to circular areas.

2.2.7 Chart Correction Service for Fixed Areas


For Chart Correction service for fixed areas the form and definition of the addressing is currently
undefined.

Volume 2: User Services, Part 1: Services and Facilities, Page: 4


Chapter 4: SafetyNETSM
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

[It is expected that processing of these messages would be performed by an external computer
connected to the EGC receiver/SES via a dedicated, or possibly shared, interface. All messages of
this type would then be routed directly to this interface on reception; the DCE itself would probably not
be required to perform message filtering based on the address. Note that the address is simply a
number (in binary) in the range 0 to 9,999,999; i.e. a possible 10 million discrete areas.]

3 Requirements and Recommendations for Ship Earth Stations


The following references are relevant:

Volume 3, Part 2, Chapter 2

Volume 3, Part 2, Chapter 8

4 Requirements and Recommendations for Land Earth Stations


The following references are relevant:

Volume 3, Part 1, Chapter 1, Sections 1 and 2

Volume 3, Part 1, Chapter 2, Sections 5, 5.8.3, and 9

Volume 3, Part 1, Chapter 3

Only authorised and registered information providers may gain access to an LES for the purpose of
transmitting SafetyNETSM messages. For further details refer to the International SafetyNETSM Manual.

Volume 2: User Services, Part 1: Services and Facilities, Page: 5


Chapter 4: SafetyNETSM
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Appendix 1: NAVAREA Determination from Absolute Geographical Location


Manufacturers may wish to implement an automatic facility for determining the current NAVAREA
from the ship's position. In this event some guidelines are required to ensure consistent
implementation of this feature. Meteorological (MET) areas for high seas warnings and forecasts have
been harmonised with NAVAREAS so that these areas are now identical.

The NAVAREAS as shown in figure 1 are difficult to encode in some cases because the area
boundaries are not simple and may be subject to change by the organisations responsible for defining
these areas (IMO/IHO/WMO). To facilitate software implementation the approximate areas shown in
figure 2, where all boundaries are either latitudinal or longitudinal lines, may be implemented.

Manufacturers should note the following:

• Users must be allowed to override any automatic facility by manual input of the current
NAVAREA;

• Shaded areas in figure 2 represent areas of uncertainty. For this reason EGC receivers located
in these areas should respond to messages addressed to both NAVAREAS indicated;

• NAVAREAs shown in Figure 2 include land masses for convenience of implementation;

• Manufacturers may elect to provide a warning to the user whenever the current NAVAREA as
determined by the ship's position is likely to be incorrect because the ship is situated close to
the area boundary;

• Users may want to select at least one NAVAREA ahead, along the intended trackline, in order
to obtain advance information or warnings and forecasts which are broadcast to
MET/NAVAREAS.

Volume 2: User Services, Part 1: Services and Facilities, Page: 6


Chapter 4: SafetyNETSM
Figure 1 GMDSS NAVAREAS
180° 160° 140° 120° 100° 80° 60° 40° 20° 0° 20° 40° 60° 80° 100° 120° 140° 160° 180°

71°
67° 67°
Inmarsat Confidential

Chapter 4: SafetyNETSM
60° 60°
53°
I 50°
48° 27' XIII
45°

35°
III INDIA/PAKISTAN
30° BORDER 30°
XII IV II XI
180°

IX
7° 12°

63°
6° North

141°

0° 54° 15.5° 64.5° 178°


0° 0°

Volume 2: User Services, Part 1: Services and Facilities,


3° 25' IOR POR
AOR-W 6° AOR-E
10° 30' Tlx: 583 10° Tlx: 582 South
Tlx: 584 Tlx: 581
12°
170°

18° XVI V VIII

20°
127°

55°
95°

30° 29°
30° 30°
XIV 35° 50'

120°
VII X 45°
VI
80°

60° XV XIV 60°


160°

67° 16'

Page: 7
(Version Release CD004, CN000)
C SDM

West East
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

100ÞW

AREA

AREA
3Þ25'S

XVI

XV
120ÞW

AREA
XII

AREA
XIV
0ÞS
170ÞW

29ÞS
180ÞE

170ÞE
160ÞE

45ÞS
AREA
XIII

45ÞN

AREA

10ÞS 141ÞE
XI

AREA
127ÞE

X
12ÞS
6ÞN

NAVAREAS
100ÞE
95ÞE
AREA
VIII

80ÞE
30ÞS

66ÞE
63ÞE

90ÞS
55ÞE

FIGURE 2
48Þ27'N

AREA IX

10Þ30'S
12ÞN
AREA III
AREA

30ÞN

AREA
71ÞN

VII
I

15ÞE
7ÞN

6ÞS

0ÞE
AREA
II

20ÞW
35Þ50'S
AREA

35ÞW
AREA
VI
V
7ÞN
67ÞN

AREA
IV

67Þ16'W
AREA
AREA

18ÞS
3Þ25'S
30ÞN

XVI

XV

100ÞW
Volume 2: User Services, Part 1: Services and Facilities, Page: 8
Chapter 4: SafetyNETSM
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Appendix 2: Determination of the Distance Between Two Known Points on the


Earth's Surface
MESs which are geographically addressed using circular area addressing (EGC SafetyNETSM or
polling area/group addressing) need to determine their distance from the centre of the circular area
addressed. The circular area address consists of two parameters; the centre of the addressed circular
area, defined in terms of it's latitudinal and longitudinal co-ordinates, and the radius in Nautical miles.

In the diagram below, the MES is located at point m (co-ordinates θm, ϕm) and the centre of the
addressed circular area is at a (co-ordinates θa, ϕa).

a
θa

m
θm
y

ϕm ϕa

The shortest distance between two points on the surface of the earth is a great circle passing through
both points (m and a). If the points are defined in terms of their latitude and longitude ( , ) then the
angular separation between the points, and hence the distance between them, may be calculated.

The following formulae describe one method for calculating this distance. A perfectly spherical Earth
is assumed, therefore no terms are included for compensating for the oblateness of the earth's
surface. Furthermore it is assumed that the MESs position is at sea level (no height term). More
elaborate expressions can be deduced which incorporate additional terms to include the effects of the
earth's oblateness and the altitude of the MES.

For the centre of the circular address determine:

Xa = R0 cos(θ a )cos (ϕ a )
Y a = R0 cos(θ a )sin (ϕ a )
Z a = R0 sin (θ a )

where R0 is the mean radius of the earth and may be taken as 3440 Nautical miles (~6371 km), θ a
and ϕ a are the latitude and longitude of the address centre respectively.

Volume 2: User Services, Part 1: Services and Facilities, Page: 9


Chapter 4: SafetyNETSM
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

For the position of the MES determine:

Xm = R0 cos (θ m )cos (ϕm )


Y m = R0 cos (θ m )sin (ϕ m )
Z m = R0 sin (θ m )

whereθm and ϕm are the latitude and longitude of the MES location respectively.

The distance along the great circle between these two points is then given as,

⎧ ⎫
−1 ⎪ (X a − Xm )2 + (Y a − Y m ) + (Za − Z m )
2 2

D = 2 R0 sin ⎨ 2 R0 ⎬
⎪⎩ ⎪⎭

To determine if the MES is located within the addressed area, this value is compared to the radius
value supplied as a parameter in the circular area address. If D is greater than this value then the
address is invalid; if D is less than this value then the address is valid.

Volume 2: User Services, Part 1: Services and Facilities, Page: 10


Chapter 4: SafetyNETSM
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 5: FleetNETSM

Contents

1 Description of Service ............................................................. 2

2 Inmarsat-C Protocol Used ........................................................ 2


2.1 Downloading and Deleting ENIDS ....................................................................2
2.2 Group Calling ....................................................................................................3
2.3 Chart Correction Service ...................................................................................3

3 Requirements and Recommendations for Mobile Earth Stations3

4 Requirements and Recommendations for Land Earth Stations.. 3


4.1 Terrestrial Access Arrangements ......................................................................3

Volume 2: User Services, Part 1: Services and Facilities, Page: 1


Chapter 5: FleetNETSM
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Description of Service
FleetNETSM is an EGC service provided for commercial message and data broadcasting to pre-
defined groups of EGC receivers.

The FleetNETSM service addressing is performed on the basis of EGC closed Network Identities
(ENIDs).

In order for an EGC receiver to belong to a group defined by an ENID, the 16 bit ENID must be
downloaded to that receiver. The ENID can also be deleted from the receivers memory. Receivers
may belong to more than one ENID.

2 Inmarsat-C Protocol Used


The Inmarsat-C EGC protocol is used to support the FleetNETSM service.

The following references are relevant:

Volume 1, Chapter 4, Section 3.2.6

Volume 4, Chapter 3, Section 3.10

Volume 4, Chapter 6, Section 3.9

Also refer to Chapter 3 of this volume.

2.1 Downloading and Deleting ENIDS


Since downloading and deleting of ENIDs make use of the same EGC protocol, there is never a 100%
certainty that the ENID download/deletion has been successful unless the recipient uses an
alternative method for acknowledging. In general downloads/deletes should be repeated to improve
the probability of reception by the addressed receiver.

The download/delete command is simply a pre-formatted text message which the EGC FleetNETSM
receiver is able to interpret and act upon. The download or delete commands are contained in the text
of a message sent using service code 33. This is a system message as its use is under the control of
LES operator. The message text should also contain an identification of the ENID "owner" so that the
EGC receiver operator is aware of what action has been taken and by whom.

An example of a ENID download command received and printed could be as follows:

/1/N/05454/

102, ACME SatCast-7

*************************

[further text.......]

The receiver will act on the command (one new ENID downloaded as indicated in the character string
between the / ... /). It will also store the first 25 characters following this command along with the
ENID, i.e., 102, ACME SatCast-7[CR][LF][CR][LF]**. These characters may be used to identify the
downloading LES and the FleetNETSM service information provider.

Volume 2: User Services, Part 1: Services and Facilities, Page: 2


Chapter 5: FleetNETSM
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.2 Group Calling


EGC service code 02 is for FleetNETSM group calling to a group of receivers each previously
downloaded with the group ENID. Messages sent using this service code will be simultaneously
received by all members of the group defined by the ENID. Any receivers that missed the original
transmission for any reason may be able to receive the message if it is repeated.

2.3 Chart Correction Service


EGC service code 72 defines a commercial FleetNETSM Chart Correction Service.

The operation of this service is not currently defined.

3 Requirements and Recommendations for Mobile Earth Stations


The following references are relevant:

Volume 3, Part 2, Chapter 2

Volume 3, Part 2, Chapter 8

4 Requirements and Recommendations for Land Earth Stations


The following references are relevant:

Volume 3, Part 1, Chapter 1, Sections 1 and 2

Volume 3, Part 1, Chapter 2, Sections 5.8.3 and 9

Volume 3, Part 1, Chapter 3

In order to ensure an adequate level of security across the network for the provision of EGC closed
networks under FleetNETSM, the following defines the restrictions on general access and the
necessary cross-checks:

i) only registered users shall have access to EGC closed network functions;

ii) an Information Provider shall only have access to those EGC closed network IDs (ENIDs),
allocated to him by the service provider;

iii) the LES shall not permit general access to service code 33, Download Group Identity, which
provides the mechanism to download and delete EGC closed network IDs (ENIDs). The LES
shall maintain a separate list of Information Providers, who have been given explicit access to
service code 33, and in addition, the LES shall only perform such a command if:

a) the requesting Information Provider is a registered user, and

b) this registered user has the right to have the given ENID downloaded or deleted.

4.1 Terrestrial Access Arrangements


Telex is mandatory for access to LESs, but other interconnecting networks, such as PSTN or PSDN,
may be provided for FleetNETSM information providers.

In any event, access to the service must be restricted to registered and authorised users.

Volume 2: User Services, Part 1: Services and Facilities, Page: 3


Chapter 5: FleetNETSM
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Addressing is normally by use of the C codes described in Volume 3, Part 1, Chapter 2 and Chapter 3
of this volume.

FleetNETSM information providers should be forbidden from using C codes associated with the
SafetyNETSM service. FleetNETSM messages should only be transmitted with routine priority.

Volume 2: User Services, Part 1: Services and Facilities, Page: 4


Chapter 5: FleetNETSM
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 6: Distress Alerting / Messaging

Contents

1 Description of Service ............................................................. 2

2 Inmarsat-C Protocol Used ........................................................ 2

3 Requirements and Recommendations for Mobile Earth Stations2


3.1 Distress Alerting ................................................................................................3
3.1.1 MES Return ID ...............................................................................................3
3.1.2 Position, Course and Speed ..........................................................................3
3.1.3 LES ID............................................................................................................3
3.1.4 Nature of Distress ..........................................................................................3
3.2 Distress Messaging ...........................................................................................3
3.2.1 Addressing .....................................................................................................3

4 Requirements and Recommendations for Land Earth Stations.. 4


4.1 Further Notes for LES Operators ......................................................................4

Volume 2: User Services, Part 1: Services and Facilities, Page: 1


Chapter 6: Distress Alerting / Messaging
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Description of Service
This service is intended to meet the distress message handling requirements as recommended in the
Radio Regulations 39-9 (Volume 3, Part 1, Chapter 2, Section 7.1 refers):

"an earth station in the maritime mobile-satellite service at a specified fixed point receiving a distress
message shall, without delay, take the necessary action to advise the appropriate authorities
responsible for providing for the operation of rescue facilities."

Distress alerting allows a maritime MES user to send a short coded transmission to a Maritime
Rescue Co-ordination Centre (MRCC). The operation of the MES when sending a distress alert is
somewhat similar to the operation of an EPIRB. The MES is regularly updated with relevant
information to be sent such as position, time of last position update, nature of distress, etc.
Transmission duty cycles are very low so that the transmissions do not impose an excessive load on
vessel power supplies (perhaps batteries). Unlike an EPIRB however, the MES receives an
acknowledgement to the distress alert giving the user confidence that the alert will be responded to.

Distress alerting can only be performed in the From-Mobile direction, that is the distress alert packet
is transmitted from the MES to the LES. The LES then decodes the information and passes this on to
an MRCC. If the MES is unable to reach the selected LES, or the selected LES is operating demand
assigned, then the distress alert packet will be sent to the NCS. In any event, the maritime distress
alert packet received at the LES (NCS) is copied to the NCS (LES).

Distress messaging is provided to allow MRCCs to conduct Search and Rescue co-ordination
activities at the scene of a distress event. Distress priority messaging is available to maritime MES
users only for the purpose of communicating with an MRCC.

Distress messaging makes use of the store and forward messaging protocol with distress priority
signalling to ensure a rapid call completion in the event of signalling channel congestion, congestion
within an LES or terrestrial interface congestion. Distress messaging can be performed in both To-
Mobile and From-Mobile directions.

2 Inmarsat-C Protocol Used


The protocols for distress alerting and distress messaging are described in Volume 1, Chapter 4.

Packet definitions and SDL are included in Volumes 4 and 5. Note that during Network Recovery,
Distress Alerts can be relayed. The LES must forward such Alerts to a Rescue Co-ordination Centre.

The following references are relevant:

Volume 1, Chapter 4, Sections 4.3.2 and 6.4

Volume 4, Chapter 4, Section 6.3

Volume 4, Chapter 4, Section 10.3.

Also see the SDL figures in Volume 5 for the handling of Distress Alerts and Distress Priority
messaging traffic.

3 Requirements and Recommendations for Mobile Earth Stations


Distress alerting and distress message transmission are requirements for maritime MESs only.

Volume 2: User Services, Part 1: Services and Facilities, Page: 2


Chapter 6: Distress Alerting / Messaging
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The following references are relevant:

Volume 3, Part 2, Chapter 2, Section 8

Volume 3, Part 2, Chapter 5, Section 8

Also refer to Volume 3, Part 2, Chapters 3 and 4.

3.1 Distress Alerting

3.1.1 MES Return ID


The distress alert packet, in common with most other Inmarsat-C signalling channel packets, includes
the MES return ID. This allows the LES to check the status of the MES and also to find its
corresponding Inmarsat Mobile Number (IMN) in its database. The IMN is passed to the MRCC so
that the MRCC will be able to call the vessel directly.

3.1.2 Position, Course and Speed


MESs have facilities for updating the position co-ordinates, vessel course and speed at regular
intervals. Since the distress alert packet also includes the time of the position update, the rescue
authorities may use the course and speed information supplied to estimate the current, or a future
position of the vessel.

It is mandatory for all MESs that a facility for manual updating of position co-ordinates be provided.
The provision of an interface to a navigational instrument for the purpose of updating the MES ships
position information is optional, though recommended. A suitable interface definition is the NMEA
0183 Standard for Interfacing Electronic Marine Navigational devices.

It is the responsibility of the MES operator to ensure that the MES position information, including
course and speed, is maintained up to date. If the position and/or course/speed is not updated for
more than 24 hours, the MES will set appropriate flags in the distress alert packet (should one be
sent) to indicate that the position and/or course/speed information supplied is more than 24 hours old.
This provides the rescue authorities with some indication of the integrity of the position information.

3.1.3 LES ID
The distress alert packet also includes a LES ID. This is the LES ID of the LES to which the distress
alert is being sent. The selected LES must be one from the ocean region to which the MES last
logged in. If the LES is operating demand assigned or the MES is unable to send the packet to the
selected LES, the distress alert packet will be sent via the NCS. The NCS forwards the distress alert
packet to the LES indicated in the LES ID field.

3.1.4 Nature of Distress


The distress alert packet also includes a nature of distress field. This provides the rescue authorities
with some general information on the type of distress situation of the sending vessel; such as fire,
sinking etc. In many real distress situations there may be little time for the operator to set this
parameter before activating, therefore there is a default setting which will be used under these
circumstances.

3.2 Distress Messaging

3.2.1 Addressing
Addressing of distress messages is currently undefined.

Volume 2: User Services, Part 1: Services and Facilities, Page: 3


Chapter 6: Distress Alerting / Messaging
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Since for all distress situations there will be only one co-ordinating body, the MRCC, all distress
messages received at an LES are routed to the MRCC with which that LES has an arrangement,
regardless of the contents of the address fields.

It is recommended that when sending a distress From-Mobile message the MES should be set with
the following default address parameters:

Protocol: Store and Forward (message)

Network type: Telex

Address (example): 000 000000000

Maritime DTE software approved for GMDSS use shall inhibit the input of a destination address when
distress From-Mobile messages are being set up.

4 Requirements and Recommendations for Land Earth Stations


The following references are relevant:

Volume 3, Part 1, Chapter 2, Section 7

Volume 3, Part 1, Chapter 2, Section 4.8.1.

In order that LES operators may fully satisfy their legal obligations under the Radio Regulations with
respect to distress handling, the following are recommended:

i) Full details of the distress alert/message should be recorded by at least two independent
means, e.g. two separate hard copies, or one hard copy and one archived to disc/tape.

ii) Connection to the MRCC should preferably be via a dedicated leased line.

iii) In the event that a terrestrial connection is not immediately available, it should be possible to
pre-empt an outgoing public line.

iv) Means should be provided for recognition (e.g. by an alarm) of any failure or delay in delivering
a distress alert or distress priority message to an MRCC.

v) Provision for manual intervention should be made in case of a terrestrial connection failure or
delay.

4.1 Further Notes for LES Operators


Due to the very high sensitivity of LES signalling channel demodulators, LES operators should be
aware that there is a possibility of receiving false (or 'phantom') distress alerts triggered by channel
noise. Such events, though by no means common, are likely to occur from time to time. These may be
recognised by the fact that the MES return ID sent in the distress alert may be (most probably)
unknown, and the LES will be unable to associate this with a corresponding forward ID and IMN. Note
that there are other possible anomalies in the system whereby the LES may not know the ID of the
MES even if it is entered in the system. Other parameters of the distress alert may also be corrupted
or unusual; for instance an incorrect or unknown LES ID, an undefined nature of distress or position
co-ordinates indicating a location clearly on land.

These 'phantom' distress alert events should nevertheless be recorded.

Volume 2: User Services, Part 1: Services and Facilities, Page: 4


Chapter 6: Distress Alerting / Messaging
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 7: PSTN Interconnection

Contents

1 Description of Service ............................................................. 2

2 Inmarsat-C Protocol Used ........................................................ 2


2.1 Recommendation for Destination Extension Formatting ...................................2
Table 1: Assignment Request packet destination extension contents for various .....
PSTN circuit terminating equipment ..........................................................2

3 Requirements and Recommendations for Mobile Earth Stations3

4 Requirements and Recommendations for Land Earth Stations.. 3


4.1 Facsimile Interface ............................................................................................4
4.1.1 From-Mobile ...................................................................................................4
4.1.2 To-Mobile .......................................................................................................4
4.2 Voice band data modem connection .................................................................4
4.2.1 Data File transfer Protocols............................................................................4
4.3 Provision of Non-Delivery Notifications .............................................................4
4.4 Selection Procedures ........................................................................................5
4.4.1 Two Stage Selection ......................................................................................5

Volume 2: User Services, Part 1: Services and Facilities, Page: 1


Chapter 7: PSTN Interconnection
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Description of Service
PSTN interconnection allows MES users to transmit and receive messages via the International PSTN
(Public Switched Telephone Network).

A number of different modem types are available for operation over the PSTN. Conventional V series
modems may be used for sending messages/data to computers equipped with suitable modems, or T
series Fax modems may be used at LESs to allow Inmarsat-C Mobile users to send textual messages
to facsimile machines.

2 Inmarsat-C Protocol Used


PSTN can be the interconnection method for supporting all of the Inmarsat-C protocols (i.e.
messaging, data reporting and polling).

The protocols are described in detail in Volume 1.

Packet definitions are included in Volumes 4. The following references in Volume 4 are particularly
relevant:

Volume 4, Chapter 3, 4 and 5.

Volume 4, Chapter 12.

Volume 4, Chapters 4 and 5 provide most detail on the MES addressing requirements.

The SDL figures are given in Volume 5.

2.1 Recommendation for Destination Extension Formatting


In order to maintain some network wide consistency for the specification of PSTN data modem types
at LESs, Table 1 shows some examples of common PSTN data modem types and the appropriate
assignment request packet destination extension contents.

Table 1: Assignment Request packet destination extension contents for various


PSTN circuit terminating equipment

Destination Extension Contents Description


T30 Group 3 FAX
T62 Teletex Terminals/Group 4 FAX
V22 V.22 modems
V22B V.22 bis modems (2400 bits/s)
V27T X.32/V.27 ter modems
V32 X.32/V.32 modems
V32B V.32 bis modems
X31A X.31 (Case A) Terminals (ISDN)

Note: The letter designations in Table 1 are all upper case (IA5 with odd parity). The two digits in byte
2 are coded BCD in a single byte. If the recommendation series number is a single digit, then the
leading digit of the pair will be zero. The last character, if required, is also upper case (IA5 with odd
parity) unless otherwise stated. If no last character is required then the field is coded 00H (null, no
parity), i.e, the characters are left justified within the field (refer to Volume 4, Chapter 4, Sections
3.3.2.2.4 and 3.3.2.3).

Volume 2: User Services, Part 1: Services and Facilities, Page: 2


Chapter 7: PSTN Interconnection
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3 Requirements and Recommendations for Mobile Earth Stations


The ability to handle PSTN addressing is optional for MESs. There are no specific requirements other
than compliance with the packet formatting described in Volume 4, Chapters 4 and 5.

It is recommended that MES manufacturers choosing to provide a PSTN addressing option should
format the assignment request destination extension contents field in accordance with Table 1 for the
common PSTN data modem types shown. It is preferable that the MES operator should not have to
enter this information each time a call is made. It is further recommended that MES models equipped
to transmit messages to and from the PSTN should also be capable of receiving and transmitting
messages using the data presentation code.

4 Requirements and Recommendations for Land Earth Stations


The ability to handle PSTN addressing is optional for LESs.

In order to provide interconnection to PSTN networks the LES must be equipped with suitable
modems. Table 1 provides some common examples. It is recommended that LESs offering PSTN
interconnection should respond to assignment request destination extension contents formatted in
accordance with Table 1 above.

In providing PSTN interconnection LES operators should make it known to users what modem
connection(s) are offered.

As a guide the following CCITT Recommendations may be of use:

T.30 Procedures for document facsimile transmission in the general switched telephone
network

T.62 Control procedures for teletex and Group 4 facsimile services

V.22 1200 bits per second duplex modem standardised for use on the general switched
telephone network and on leased circuits

V.22 bis 2400 bits per second duplex modem using the frequency division technique standardised
for use on the general switched telephone network and on point-to-point 2-wire leased
telephone-type circuits

V.27 ter 4800/2400 bits per second modem standardised for use in the general switched
telephone network

V.32 A family of 2-wire, duplex modems operating at data signalling rates of up to 9600 bit/s
for use on general switched telephone network and on leased telephone-type circuits

V.32 bis A duplex modem operating at data signalling rates of up to 14400 bits/s for use on the
general switched telephone network and on leased point to point 2-wire telephone-type
circuits

X.31 A support of packet mode terminal equipment by an ISDN

X.32 Interface between data terminal equipment (DTE) and data circuit-terminating equipment
DCE) for terminals operating in the packet mode and accessing a packet switched public
data network through a public switched telephone network or an integrated services
digital network or a circuit switched public data network

Volume 2: User Services, Part 1: Services and Facilities, Page: 3


Chapter 7: PSTN Interconnection
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.1 Facsimile Interface

4.1.1 From-Mobile
Messages received at the LES are converted to a facsimile "image" for transmission over the PSTN.

The choice of character font and size for the message content is a matter for the LES operator,
however the following is a good choice for clarity and legibility:

Font: [Geneva] Size: [12 point]

[This is an example of 12 point Geneva text]


The facsimile message header may convey essentially the same information as that conveyed in a
telex message header (refer to Chapter 2). Headers may be customised to suit the service provider,
e.g. by the provision of logos, borders, etc.

4.1.2 To-Mobile
Transmission of facsimile data in the To-Mobile direction is more complex. A single page of fax may
well require 30 kbytes or more to store as a bit mapped image. Converting the "image" to text is a
possible method for compressing the data to a manageable quantity if purely textual information is
conveyed in the fax. However many users may still wish to transmit graphics; for example hand drawn
sketches or hand written messages in non-Latin alphabets, mechanical/electrical drawings, maps etc.

No general solution exists at the present.

4.2 Voice band data modem connection


For From-Mobile messaging, essentially two modes of operation are possible:

i) Store and forward operation: whereby, following reception of the complete message, the LES
calls the destination PSTN number using the specified modem type (if supported) and transmits
the message;

ii) Store and retrieve operation: whereby the message is delivered to a mailbox, which may or
may not be located at the LES. The end user dials in to the mailbox to retrieve the stored
message(s).

LESs providing PSTN access may support either or both of these modes.

For To-Mobile messaging, operation of the LES is essentially the same as for telex; all messages are
stored at the LES prior to transmission to the destination MES.

4.2.1 Data File transfer Protocols


For the transfer of moderate quantities of data, it is recommended that a file transfer protocol should
be used between the LES and the terrestrial originator/destination in order to ensure data integrity
over the terrestrial network. File transfer protocols such as Kermit, Xmodem or others may be used. It
is further recommended that more than one file transfer protocol should be offered to users.

4.3 Provision of Non-Delivery Notifications


The provision of non-delivery notifications to originators of To-Mobile messages from the PSTN is a
national matter for the LES operator.

For non-delivery notifications to mobile operators sending From-Mobile messages, the three character
codes specified in Volume 3, Part 1, Chapter 2, Section 5.7.3 are used (also refer to Chapter 2 of this

Volume 2: User Services, Part 1: Services and Facilities, Page: 4


Chapter 7: PSTN Interconnection
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

volume). LES operators may adopt additional codes for PSTN calling. For example, the following may
be appropriate for certain types of call failure on the terrestrial path:

VAD Voice answer detected

MOD Incorrect/Incompatible/unknown modem type detected on answer

TMO Persistent off-hook timeout (no answer)

4.4 Selection Procedures


In general PSTN access in the To-Mobile direction is by two stage selection.

4.4.1 Two Stage Selection


LESs may accept calls from the terrestrial network using a two stage selection procedure. This
requires the LES to respond to PSTN originated calls by requesting the address and other
information. Two stage selection is also required for the implementation of services such as multi-
addressee calls, follow-on calls and delivery scheduled calls.

For security reasons users sending messages using two stage access are generally assigned a PIN
(Personal Identification Number) or some form of user identification which they must enter before
access is granted.

The two stage access procedure is not necessarily uniform from one LES to another.

The general procedure for calling an Inmarsat-C MES using two stage access is as follows:

i) The operator calls the number of the LES through which an arrangement has been established.
Including the country code if required.

ii) On establishing a connection the LES responds and may request the operator to enter a PIN
(or user identity/password, or both).

iii) The operator may then be requested to enter the type of service required (perhaps from a
menu of options) and a list of addressed MESs.

iv) The operator may then be requested to enter the message text.

It is recommended that LESs should be capable of suppressing responses to the user so as to allow
automatic connection, i.e. from applications running on the call originators machine.

Volume 2: User Services, Part 1: Services and Facilities, Page: 5


Chapter 7: PSTN Interconnection
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 8: PSDN Interconnection Using X.25

Contents

1 Description of Service ............................................................. 2

2 Inmarsat-C Protocol Used ........................................................ 2

3 Requirements and Recommendations for Mobile Earth Stations2

4 Requirements and Recommendations for Land Earth Stations.. 2


4.1 Data File transfer Protocols...............................................................................3
4.2 Provision of Non-Delivery Notifications .............................................................3
4.3 Selection Procedures ........................................................................................3
4.3.1 Single Stage Selection ...................................................................................3
4.3.2 Two Stage Selection ......................................................................................3
4.4 DNIC Checking at LES (From-Mobile Messages) .............................................4

Volume 2: User Services, Part 1: Services and Facilities, Page: 1


Chapter 8: PSDN Interconnection Using X.25
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Description of Service
PSDN interconnection allows MES users to transmit and receive messages via the International
PSDN (Packet Switched Data Network).

PSDN interconnection, although not mandatory for LESs, is a popular mode of interconnection. It
allows LESs to support access to a wide range of other services.

On the terrestrial side it offers high speed, security and virtually error free transmission.

2 Inmarsat-C Protocol Used


PSDN can be the interconnection method for supporting all of the Inmarsat-C protocols.

The protocols are described in detail in Volume 1.

Packet definitions are included in Volumes 4. The following references in Volume 4 are particularly
relevant:

Volume 4, Chapter 3, 4 and 5.

Volume 4, Chapter 12.

Volume 4, Chapters 4 and 5 provide most detail on the MES addressing requirements.

The SDL figures are given in Volume 5.

3 Requirements and Recommendations for Mobile Earth Stations


The ability to handle PSDN addressing is optional for MESs. There are no specific requirements other
than compliance with the packet formatting described in Volume 4, Chapters 4 and 5.

It is recommended that MES models equipped to transmit messages to and from the PSDN should
also be capable of receiving and transmitting messages using the data presentation code.

4 Requirements and Recommendations for Land Earth Stations


The ability to handle PSDN addressing is optional for LESs.

The following requirements are relevant:

Volume 3, Part 1, Chapter 2, Section 5

The following CCITT Recommendations are also relevant to LES - PSDN network interfacing:

X.21 Interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE)
for start-stop transmission services on public data networks

X.25 Interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE)
for terminals operating in the packet mode and connected to public data networks by dedicated
circuit

X.28 DTE/DCE interface for a start-stop mode data terminal equipment accessing the packet
assembly/disassembly facility (PAD) in a public data network situated in the same country

Volume 2: User Services, Part 1: Services and Facilities, Page: 2


Chapter 8: PSDN Interconnection Using X.25
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

X.29 Procedures for the exchange of control information and user data between a packet
assembly/disassembly (PAD) facility and a packet mode DTE or another PAD

X.75 Packet-switched signalling system between public networks providing data transmission
services

X.121 International numbering plan for public data networks

X.350 General interworking requirements to be met for data transmission in international public mobile
satellite systems

X.352 Interworking between packet switched public data networks and public maritime mobile satellite
data transmission systems

X.353 Routing principles for interconnecting public maritime mobile satellite data transmission
systems with public data networks

4.1 Data File transfer Protocols


For the transfer of moderate quantities of data, it is recommended that a file transfer protocol should
be used between the LES and the terrestrial originator/destination in order to ensure data integrity
over the terrestrial network. File transfer protocols such as Kermit, Xmodem or others may be used. It
is recommended that more than one file transfer protocol should be offered to users.

4.2 Provision of Non-Delivery Notifications


The provision of non-delivery notifications to originators of To-Mobile messages from the PSDN is a
national matter for the LES operator.

4.3 Selection Procedures


As for telex, both single stage and two stage access from the PSDN may be implemented at LESs.

4.3.1 Single Stage Selection


There is no equivalent to CCITT Recommendation U.208 (telex) for single stage PSDN access.

Every Inmarsat-C MES has a unique Inmarsat Mobile Number (IMN). It is a 9 digit number in
accordance with CCITT Recommendation F.125. For all Inmarsat-C MESs the leading digit (referred
to as the "T" digit) is always 4.

To send a message from the terrestrial PSDN to a MES via a LES using single stage addressing, the
user should send the message to the following telex address:

111STX1X2X3X4X5X6X7X8

where S following the 111 is the ocean region identifier digit (1 for AOR-E, 2 for POR, 3 for the IOR
and 4 for AOR-W). The code 111S is the X.121 or Data Network Identification Code (DNIC) for
Inmarsat. The digits TX1X2X3X4X5X6X7X8 comprise the Inmarsat Mobile Number (IMN). For full details
of the Inmarsat-C Numbering Plan refer to Volume 3, Part 1, Chapter 3.

Routing arrangements in each country are a national matter and outside the control of Inmarsat. The
single stage access procedure is not necessarily uniform from one LES to another.

4.3.2 Two Stage Selection


LESs may accept calls from the terrestrial network using a two stage selection procedure. This
requires the LES to respond to PSDN originated calls by requesting the address and other

Volume 2: User Services, Part 1: Services and Facilities, Page: 3


Chapter 8: PSDN Interconnection Using X.25
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

information. Two stage selection is also required for the implementation of services such as multi-
addressee calls, follow-on calls and delivery scheduled calls.

PSDN users in some countries may not be able to send messages using single stage access. In such
cases it should be possible for users to set up two stage access with an LES(s). For security reasons
users sending messages using two stage access are generally assigned a PIN (Personal
Identification Number) or some form of user identification which they must enter before access is
granted.

The two stage access procedure is not necessarily uniform from one LES to another.

The general procedure for calling an Inmarsat-C MES using two stage access is as follows:

i) The operator calls the number of the LES through which an arrangement has been established.
Including the country code if required.

ii) On establishing a connection the LES responds and may request the operator to enter a PIN
(or user identity/password, or both).

iii) The operator may then be requested to enter the type of service required, perhaps from a
menu of options, and a list of addressed MESs.

iv) The operator may then be requested to enter the message text.

It is recommended that LESs should be capable of suppressing responses to the user so as to allow
automatic connection, i.e. from applications running on the call originators machine.

4.4 DNIC Checking at LES (From-Mobile Messages)


It is recommended that the DNIC supplied in the assignment request packet for From-Mobile
messages should be checked as follows:

First non-zero digit of Check


DNIC
1 Only DNICs 1111 to 1114 are currently allowed.
2 to 7 Only the following first three digits (the country code) need be checked.
8 The immediately following digits should form a valid F.69 code.
9 The immediately following digits should form a valid E.164 code.

Leading zeroes are ignored. Therefore a leading digit of zero, although a valid X.121 escape digit, is
not allowed for addressing from MESs when sending messages to (or via) PSDN networks. CCITT
Recommendation X.121 specifies that the escape digit zero may be used followed by an E.164 code
for ISDN addressing. Alternative means for ISDN addressing may be provided, for example using
PSTN addressing (E.164 codes are common to PSTN and ISDN) and specifying the PSTN data
modem type to be [X31A]. Refer to Chapter 7.

Volume 2: User Services, Part 1: Services and Facilities, Page: 4


Chapter 8: PSDN Interconnection Using X.25
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 9: Alternative Presentation Codes

Contents

1 Introduction ............................................................................ 2

2 Presentation Code Options ...................................................... 2


2.1 Mandatory IA5 Presentation Code ....................................................................2
2.1.1 Accents in IA5 ................................................................................................2
2.1.2 Conversion to/from ITA2 ................................................................................3
2.2 ITA2 Presentation Code ....................................................................................3
2.2.1 National Character set Options using ITA2 ....................................................3
2.3 Data Presentation Code ....................................................................................3
2.4 Basic X.400 Encoding .......................................................................................3

3 Inmarsat-C Protocol Issues ..................................................... 3


3.1 Store and Forward Messaging ..........................................................................3
3.2 EGC ..................................................................................................................4
3.2.1 SafetyNETSM ...................................................................................................4
3.2.2 FleetNETSM......................................................................................................4

4 Requirements and Recommendations for Mobile Earth Stations5


4.1 ITA2 Character Handling...................................................................................5
Figure 1: Packing of 5-bit ITA2 characters into message packet bytes ...................5
4.2 Data Handling ...................................................................................................6
4.3 EGC Receivers .................................................................................................6

5 Requirements and Recommendations for Land Earth Stations.. 6


Appendix 1: LES Code of Practice for Message Headers .......................................7
1 Telex Message Headers ......................................................................................7
2 Message Headers with Data ................................................................................8

Volume 2: User Services, Part 1: Services and Facilities, Page: 1


Chapter 9: Alternative Presentation Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
The Inmarsat-C presentation codes describe the type of alphabet and coding used in message data
packets. Essentially this defines the number of bits/character and parity coding (if any). Four
presentation codes are currently defined - IA5 with odd parity, ITA2 5-bit code, 8-bit data and Basic
X.400 encoding.

This chapter summarises the uses of these presentation codes and provides recommendations for
conversion and handling by MESs and LESs.

The following CCITT Recommendations are relevant:

S.1 International Telegraph Alphabet No. 2

S.18 Conversion between international telegraph alphabet No. 2 and international alphabet No. 5

T.50 International Alphabet No. 5

T.61 Character repertoire and coded character sets for the international teletex service

In addition the following document provides useful guidance on other character sets:

ISO 2022Information processing – ISO 7-bit and 8-bit coded character sets - Code extension
techniques

2 Presentation Code Options

2.1 Mandatory IA5 Presentation Code


The mandatory form of character (presentation code) transmission in the Inmarsat-C System is IA5 7-
bit data (see CCITT Recommendation T.50) with odd parity (total of 8-bits/byte or character - 7
information bits and 1 parity bit). Odd parity is used. This is defined as meaning that the number of
bits set to one in the byte must always be an odd number. If the 7 information bits have an even
number of ones, then the parity bit is set to one; if the 7 information bits have an odd number of ones,
then the parity bit is set to zero, thus ensuring that the overall number of bits set to one in the byte is
always odd.

The parity bit is not strictly necessary for the Inmarsat-C store and forward messaging services. In this
case entire messages are only received error free due to the ARQ mechanism of the store and
forward message transfer protocol. The undetected message error probability is extremely low (better
than 1 packet in 65,000). Nevertheless, the IA5 + odd parity format is extended to the DTE and parity
checking should be performed on the MES DTE - DCE link where this could be subject to errors,
perhaps due to operation in an environment with high ambient electrical noise.

Note that the recommended MES DTE - DCE link is RS-449/422A (CCITT Recommendations
V.24/V.11) which has balanced electrical characteristics and therefore superior noise immunity
properties than the more widely used and optional RS-232C (CCITT Recommendations V.24/V.28).

With the broadcast EGC services there is no ARQ in the protocol since EGC receivers are unable to
transmit to provide an ARQ mechanism. The EGC protocol forbids reception of message packets with
corrupted headers, however message data formatted IA5 with odd parity may be accepted even if it is
corrupted. Parity checking of individual characters provides a simple means for detecting and
identifying corrupted characters within a message; refer to section 3.2 below.

2.1.1 Accents in IA5

Volume 2: User Services, Part 1: Services and Facilities, Page: 2


Chapter 9: Alternative Presentation Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The CCITT Recommendation T.61 defines accents Grave, Circumflex and Tilde/Overline. CCITT
Recommendation T.50 additionally states that Quotation mark, Apostrophe and Comma may be used
to represent Diaresis/Umlaut, Acute and Cedilla respectively. Interpretation of these
recommendations is up to the LES operator. Differences of interpretation may therefore exist from one
LES to another.

2.1.2 Conversion to/from ITA2


In general, terrestrial telex networks use ITA2 5 unit code. Therefore conversion to/from IA5 is
required at the LES. Conversion should be in accordance with CCITT Recommendation S.18.

2.2 ITA2 Presentation Code


Telex transmission on terrestrial circuits is normally performed using the International Telegraph
Alphabet No. 2 (ITA2) character repertoire (CCITT Recommendation S.1). The characters are coded
into just 5 bits. For the transmission of basic alphanumeric characters this offers a potential saving
over IA5 or data transmission for transmission over the Inmarsat-C link.

This presentation code is mainly intended for telex users, nevertheless LESs may offer conversion to
or from ITA2 for other interconnecting networks. The ITA2 character set does not support accents.

2.2.1 National Character set Options using ITA2


To ensure consistency and to avoid varying interpretations within the Inmarsat-C system, MESs
should not provide national character options for character Nos. 6, 7 and 8 in figure case.

2.3 Data Presentation Code


Data presentation code allows the transmission of any byte oriented data (8 bits/character) over the
Inmarsat-C link.

Typical applications include the transmission of executable files, formatted application files, binary
data, non-Latin alphabet text etc.

This presentation code is mainly intended for transmission to or from (or within) the Inmarsat-C
network via X.25 or other data networks, that allow transparent byte oriented data transmission.

2.4 Basic X.400 Encoding


For basic X.400 interworking, the message data field follows a pre-defined structure, unlike normal
messaging where no structure is assumed. In order to indicate a basic X.400 message structure,
presentation code 80H is used. The actual message data content may be coded either as 8-bit data
or 7-bit IA5 with odd parity, depending on the MES implementation. It is expected that in most cases
the data will be full 8-bit (or 7-bit with no parity). The message header also allows the possibility that
the formatting of message data may be defined and may be different from that used for the message
header.

It is likely that further presentation codes for X.400 interworking will be defined.

3 Inmarsat-C Protocol Issues


The store and forward messaging and EGC services make use of presentation codes to define the
type of character coding and/or the structure of the data conveyed in the data/message packets

3.1 Store and Forward Messaging

Volume 2: User Services, Part 1: Services and Facilities, Page: 3


Chapter 9: Alternative Presentation Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

For store and forward message transfer the presentation code is transmitted at the time of call set up
for To-Mobile calls. The presentation code is included in the announcement packet.

On receiving the announcement for the To-Mobile message, the MES checks that the assigned
presentation code for the message is supported (Volume 5, Chapter 3, Figure 3.5.10[1] refers). In the
event that the presentation code is not supported by the MES, the call is force cleared. If the
presentation code is supported then the MES will receive and process the message.

For From-Mobile messages the presentation code is in the header of the first message packet and
therefore accompanies the message data. LES operators are not obliged to support all presentation
code types. If the presentation code is not supported then the LES may force clear the call with a
reason for clear code of 09H - unrecognised presentation code.

3.2 EGC
For EGC messages the presentation code is a field in the header of each packet and is the same for
every packet associated with a particular message. The EGC services support the same presentation
codes as for Inmarsat-C store and forward messaging.

3.2.1 SafetyNETSM
All SafetyNETSM messages use IA5 coding with odd parity with the exception of service code 73H -
Chart Correction Service to fixed areas.

All Inmarsat-C packets consist of a packet type field and a checksum. In addition EGC packets
consist of a header field in each packet with its own checksum. EGC packets received with invalid
checksums may be processed provided that the header checksum is valid. If the header address and
other parameters are accepted by the receiver the message data may then be output. Any characters
received in the message which have been corrupted may be identified as such by use of the low-line
character if a parity error is detected. An example of a message received complete but having
character errors may appear as follows:

MET__ROLOGICAL WARNING NAVA_kA 1. ISSUED AT 2300 6/11/92.

WEST CENTRAL:

HI__ WINDS EXPW_TED, GUS_hNG GALE FORCE 9 NORTH NORTH-WEST. HEAVY RAIN.

PEA_2WINDS EXPECTED 0230 HRS 8/11, EASING TO GAL__FORCE 4 BY 0600 HRS,


BECOMING NORTHERLY.

SEA _Z_DITIONS SEVERE.

XYZ 07/11 2300 UTC

Examination of the example above shows that in many cases the corruption is such that the parity
check fails and an errored character is indicated. In some cases the corruption is such that there may
be an even number of (bit) errors in the character, or an odd number of errors including the parity bit
itself. In these cases an error is not indicated. However, provided there are not too many errors,
overall the message may still be quite legible. The low-line character allows an operator to write in the
correct character if they so wish. Errored characters often occur in groups of 2 or more.

Like SafetyNETSM, System messages are also broadcast using IA5 with odd parity.

3.2.2 FleetNETSM
FleetNETSM messages may be transmitted using other presentation codes. Since the main purpose of
FleetNETSM messaging is to broadcast messages to groups of mobiles, use of other presentation

Volume 2: User Services, Part 1: Services and Facilities, Page: 4


Chapter 9: Alternative Presentation Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

codes should be exercised with care. Operators should ensure that all EGC receivers within a group
are capable of receiving messages in the desired presentation code if this is not IA5 with odd parity.

4 Requirements and Recommendations for Mobile Earth Stations


Handling of presentation codes other than IA5 with odd parity is optional for MESs.

The following references are relevant:

Volume 3, Part 2, Chapter 2, Section 7.2

Volume 3, Part 2, Chapter 8, Section 7.2

4.1 ITA2 Character Handling


For ITA2 messaging, the formatting of transmitted message packets must be in accordance with the
Volume 4, Chapter 5, Section 3.1.3. An example of how a message packet is packed with 5-bit data is
illustrated in Figure 1 below.

Figure 1: Packing of 5-bit ITA2 characters into message packet bytes

Bit
8 7 6 5 4 3 2 1
5 2
3 2 1 4 3 1 1
1 5 4 3 2 1 5 4 2
Byte
4 3 2 1 5 4 3 2 3
2 1 5 4 3 2 1 5 4 "mark" (Z) = binary 1
5 4 3 2 1 5 4 3 5 "space" (A) = binary 0
1 6

Bit
8 7 6 5 4 3 2 1
"HELLO.." = 0 0 1 1 0 1 0 0
1 34H
0 1 0 0 1 0 0 0 2 48H
0 0 1 3 Byte
1 0 0 1 0 89H
Note that character 0 0 1 1 0 1 1 1
4 37H
number 6 is a 1 1
1 1 1 0 0 1 5 E7H
Figure-shift
6

Volume 2: User Services, Part 1: Services and Facilities, Page: 5


Chapter 9: Alternative Presentation Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

It is recommended that the 5-bit characters are converted to/from 7/8-bit ASCII/IA5 characters (with or
without parity) within the MES DCE, including the appropriate insertion or removal of figure and letter
shift characters.

4.2 Data Handling


For data presentation there are no special requirements. For messages received with data
presentation no parity checking need be performed (in the DTE). No parity bit should be set for
messages prepared for transmission. The MES DCE and DTE should be transparent with respect to
the data to be transmitted, neither inserting, changing or removing data. Similarly for received
messages.

It is recommended that MESs handling data presentation code should have the facility for transmitting
data directly from stored files, and receiving data and storing as a file without necessarily
printing/displaying. Specific application file formats may include non-printable characters and other
control characters which may disrupt printer operation. Additionally the file data may not be in a
readable form and could also be compressed and/or encrypted.

4.3 EGC Receivers


For EGC receivers capable of receiving messages containing ITA2 or data presentation, it is
recommended that the following options are exercised by the receiver:

i) messages with errored packets are not output (printed/displayed/processed) until subsequent
reception(s) of the same message allows the receiver to assemble the complete message with
all good packets;

ii) messages may be printed/displayed following reception but packets with errors (i.e. a valid
header checksum but invalid packet checksum) are clearly identified

Option (i) is most appropriate to data presentation where the data message is to be further processed.
An example might be for the chart correction service where the integrity of the received information
may be important. For ITA2 handling, either option may be exercised.

5 Requirements and Recommendations for Land Earth Stations


Handling of presentation codes other than IA5 with odd parity is optional for LESs.

The following references are relevant:

Volume 3, Part 1, Chapter 2, Sections 5 and 9

Volume 2: User Services, Part 1: Services and Facilities, Page: 6


Chapter 9: Alternative Presentation Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Appendix 1: LES Code of Practice for Message Headers


The following presents a Code of Practice for the use and formatting of message headers within the
Inmarsat-C system. Compliance with the code of practice is not mandatory for LESs, but is strongly
recommended.

1 Telex Message Headers


The telex header format described may be used whenever the LES is transferring messages between
the Inmarsat-C network and the telex network. The recommended general conditions under which the
telex message header should be used are as follows:

To-Mobile: The call originates from a telex subscriber.

From-Mobile: The Destination Network (in the assignment request packet) specifies telex.

Mobile-to-Mobile: Same as From-Mobile.

EGC FleetNETSM: The call originates from an authorised (FleetNETSM) telex subscriber.

The recommended information to be supplied in a telex message header is as follows:

Service Provider: The name identifying the operator and/or the name of the service.

Ocean Region Identifier: The following shorthand forms are recommended: AOR-W, AOR-E, IOR,
POR.

LES ID: Transmitting LES ID. Recommended though not essential, as this
information is available to the MES.

Message Originator: Though not essential, it is recommended that the telex address of the
originator should be provided along with the answerback. The TNIC may
also be supplied.

Date: The preferred numeric format is YYYY-MM-DD (or YY-MM-DD),


where YYYY indicates the year, MM the month and DD the day . Other non-
ambiguous forms of date expression may be employed.

Time: The preferred format for time is HH-NN or HHNN, where HH indicates the
hour on a 0-24 basis and NN the minute. UTC is strongly recommended.

Message Identifier: The recommended format is an up to six digit Message reference number.

It is recommended that all header text be formatted upper case. Wherever possible, numeric rather
than textual expression should be used (e.g. for the date, 1993-01-23 is preferable to 23-JAN-1993)
as this is more universally readable, and generally more compact. The message header should be
terminated by at least two [CR][LF] combinations to provide a blank space before the start of the
message.

An example of a From-Mobile telex message header (as received at a destination telex machine)
could be as follows:
_________________________________________________________________________________

INMARSAT-C AOR-E 139 499999923=ABACK X 1993-01-23 1235 UTC 125871

[message text......]
_________________________________________________________________________________

Volume 2: User Services, Part 1: Services and Facilities, Page: 7


Chapter 9: Alternative Presentation Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2 Message Headers with Data


Users may wish to transfer binary files to/from Inmarsat-C MESs for direct input to applications. An
example could be where a central computer downloads a spreadsheet file to a MES using X.25 file
transfer. In order for the spreadsheet to be usable at the receiving end and recognisable by the
running application (a commercial spreadsheet package for example), it is most important that the
data is not corrupted in any way.

The following are recommendations for handling messages using data presentation:

i) It is recommended that LESs offering data presentation code handling should not delete, insert
or change characters or modify submitted message data in any way whatsoever. This is
particularly important where the addressed network or destination is able to support 8-bit data.

ii) If header information is inserted into the submitted message before forwarding, it is
recommended that an end of header sequence should be used and the format of the header
and end of header sequence should be made known to users.

The structure of the header and end of header sequence is a national matter, however the
following delimiter/end of header sequence is recommended:

[Message] ::= [Message Header][End of Header][User Data]

where [End of Header] is the following (IA5/ASCII) six character sequence:

"S" "T" "X" ":" [CR][LF]

or in hexadecimal:

53 54 58 3A 0D 0A

The STX are upper case only. This sequence should be inserted after the header with the first
byte of the users data appearing after the [LF]. It is expected that the message header would
end with a new line sequence, e.g. [CR][LF].

LES operators should make known to users and potential users which of the above methods
they use, and if they choose to insert a header, the precise format of that header and end of
header sequence.

The header format for data transmission may be used whenever the LES is transferring data
between the Inmarsat-C network and a terrestrial data network capable of supporting 8-bit data
(e.g. PSTN/PSDN). The recommended general conditions under which the data message
header should be used are as follows:

To-Mobile: The call originates from a data network subscriber and/or the message
contains 8-bit formatted information.

From-Mobile: The presentation code specifies data and the Destination Network (in the
assignment request packet) specifies a data network capable of supporting
8-bit data (e.g. not telex). If the destination does not support data (e.g. telex)
then the LES may reject (force clear) the call, or alternatively translate the
data to a suitable format provided this results in no loss of information
integrity.

Mobile-to-Mobile: Same as From-Mobile.

EGC FleetNETSM: The call originates from an authorised (FleetNETSM) subscriber using a data
network that supports 8-bit data.

Volume 2: User Services, Part 1: Services and Facilities, Page: 8


Chapter 9: Alternative Presentation Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 10: Data Reporting and Polling Service

Contents

1 Description of Service ............................................................. 2

2 INMARSAT-C Protocol Used ..................................................... 2


2.1 Individual Polling ...............................................................................................2
2.2 Group Polling ....................................................................................................2
2.3 Area/Group Polling ............................................................................................2
2.4 Poll Commands .................................................................................................3
2.4.1 Send Unreserved Report ...............................................................................3
2.4.2 Downloading and Deleting DNIDs ..................................................................3
2.4.3 Programming .................................................................................................3
2.4.4 Macro Encoded Messages.............................................................................3
2.4.5 User Defined ..................................................................................................3
2.5 Unreserved Data Reporting ..............................................................................4
2.6 Reserved (Pre-assigned) Data Reporting .........................................................4

3 requirements and Recommendations for Mobile Earth Stations 4

4 Requirements and Recommendations for Land Earth Stations.. 4

Volume 2: User Services, Part 1: Services and Facilities, Page: 1


Chapter 10: Data Reporting and Polling Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Description of Service
Although the data reporting and polling protocols can be used in isolation from one another to support
separate services, normally they will be used together. One reason for this is that if an MES is to
perform data reporting it needs to have a Data closed Network Identity (DNID) and associated LES ID
downloaded before it can start. Therefore it must support the polling protocol, even if only for a small
subset of (polling) command types.

This chapter is concerned with the provision of both protocols to support a variety of possible services
and applications. For further information on possible applications of the polling and data reporting
services, refer to the Application Notes in Part 2 of this volume.

2 INMARSAT-C Protocol Used


A description of the data reporting and poling protocols is provided in Volume 1, as follows:

Data Reporting: Chapter 5

Polling: Chapter 6

Pre-assigned Data Reporting: Chapter 7

Packet definitions are described in Volume 4, as follows:

Data Reporting: Chapter 8

Polling: Chapter 9

Pre-assigned Data Reporting: Chapter 10

The SDL figures are given in Volume 5, Chapter 5.

2.1 Individual Polling


Individual polls are sent to a single MES using the MES forward ID as the address parameter.

2.2 Group Polling


A group poll addresses all MESs previously downloaded with the group DNID/LES id pair (other than
those MESs which may have had the DNID/LES ID pair disabled by the MES operator). The
DNID/LES ID is the address parameter

2.3 Area/Group Polling


This is essentially the same as group polling except that only those MESs within the group that are
also within the addressed area will accept the poll. The area address types currently defined
correspond to those used for the EGC SafetyNETSM addressing schemes. Note that some of these,
namely those involving NAVAREA and other pre-defined addressing schemes are inappropriate for
Land Mobile services and applications. The address parameters are the DNID/LES ID and the
addressed area.

An algorithm for determining if an MES at a known location lies within a circularly addressed area is
described in Chapter 4, Appendix 2.

Volume 2: User Services, Part 1: Services and Facilities, Page: 2


Chapter 10: Data Reporting and Polling Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.4 Poll Commands

2.4.1 Send Unreserved Report


This command instructs the MES (application) to transmit a single data report in response to the poll.

2.4.2 Downloading and Deleting DNIDs


These functions are performed using Individual Polls only. The purpose of these commands is to
allow the LES operator to download a DNID to an MES or to delete a DNID from an MES memory.

a) Downloading a DNID

An example of a download text field could be as follows:

ACME Haulage FleetMonitor

*************************

[further text.......]

The receiver will act on the command (new DNID downloaded). It will also store the first 25 characters
of the free field associated with the download poll, i.e., ACME Haulage FleetMonitor. These
characters may be used to identify the downloading LES and the DNID operator.

b) Deleting a DNID

The parameters associated with the delete command are essentially the same as for the download
with the exception that the text field is optional. Generally a text field should accompany the delete
poll in order to provide some information to the MES operator when a DNID is deleted

2.4.3 Programming
Programming of data reporting using certain reserved poll command types allows terrestrial users and
LES operators to program MESs to transmit data reports. A number of polling command types are
associated with programming of unreserved and reserved (pre-assigned) access data reporting to
allow flexible control of the MES. These commands are:

- program reserved/unreserved data reporting

- initiate reserved/unreserved data reporting

- stop reserved/unreserved data reporting

2.4.4 Macro Encoded Messages


Two command types are available (Define Macro Encoded Message and Macro Encoded Message)
for use with Inmarsat defined applications. For details of these refer to Part 2 of this volume. These
allow users to define and send macro encoded messages which may allow very efficient transmission
of information associated with a particular application.

2.4.5 User Defined


A range of command types have been set aside for use by other user applications. These command
types are ignored by the MES DCE and are passed directly to the user application.

Volume 2: User Services, Part 1: Services and Facilities, Page: 3


Chapter 10: Data Reporting and Polling Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.5 Unreserved Data Reporting


Unreserved data reporting allows an MES to transmit small quantities of user data to a DNID file,
associated with a previously downloaded DNID and LES ID. The data reports use unreserved access
on the LES signalling channels (hence the name). Unreserved data reporting may be initiated at any
time by a user or associated application, or it may be pre-programmed using suitable poll command
types (refer to section 2.4.3 above). Unreserved data reporting is appropriate for non-critical
applications, requiring irregular or infrequent transmission of small quantities of data.

2.6 Reserved (Pre-assigned) Data Reporting


Reserved access, or pre-assigned data reporting is only available by programming the MES using
suitable poll command types. It allows an MES to be programmed to transmit regular data reports at
precisely known times. The advantage of this method over unreserved access data reporting is that
the times of transmission are precisely controlled, the transmissions are less susceptible to collision
or corruption from competing MES transmissions, and more efficient use is made of the available
signalling channel resources.

3 requirements and Recommendations for Mobile Earth Stations


MES requirements are in Volume 3, Part 2, Chapters 2 and 3 (in particular specific requirements
relating to data reporting and polling are supplied in Section 4 of Chapter 3).

MES models need not support all command types. As a minimum command type 0AH and 0BH
(download and delete DNID) must be supported.

4 Requirements and Recommendations for Land Earth Stations


LES requirements are in Volume 3, Part 1, Chapter 2. Polling addressing is described in Section 10 of
Chapter 2.

LES operators should ensure that their stations are equipped with sufficient return signalling channel
capacity to meet anticipated demand for data reporting.

Volume 2: User Services, Part 1: Services and Facilities, Page: 4


Chapter 10: Data Reporting and Polling Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 11: Land Mobile Alerting

Contents

1 Description of Service ............................................................. 2

2 INMARSAT-C Protocol Used ..................................................... 2

3 requirements and Recommendations for Mobile Earth Stations 2

4 Requirements and Recommendations for Land Earth Stations.. 2

Volume 2: User Services, Part 1: Services and Facilities, Page: 1


Chapter 11: Land Mobile Alerting
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Description of Service
The Land Mobile Alerting service is intended to satisfy the need for a rapid emergency alerting facility
for Land Mobile users. The operation of the service is similar to the distress alerting service available
to maritime Inmarsat-C users.

Land Mobile alerts are sent to LESs. On receipt of the alert the LES will forward the information
contained in the alert packet to a pre-registered address (for that MES). Unlike maritime distress
alerting, no back-up function is provided by the NCS.

2 INMARSAT-C Protocol Used


The protocol is described in Volume 1, Chapter 8. The MES essentially uses the maritime distress
alerting protocol with some small variations in as much as the service is restricted to LESs offering
Land Mobile alerting and also providing signalling channels available for Land Mobile alerting. Also
the format and contents of the Land Mobile alert packet differs from that defined for the maritime
distress alert packet.

Packet definitions are in Volume 4.

The following references are relevant:

Volume 4, Chapter 4

Volume 4, Chapter 4, Section 10.3

Also see the SDL figures in Volume 5, Chapters 2 and 3 for the handling of Maritime Distress Alerts.

3 requirements and Recommendations for Mobile Earth Stations


The following references are relevant:

Volume 3, Part 2, Chapter 2, Section 8

Volume 3, Part 2, Chapter 6, Section 8

4 Requirements and Recommendations for Land Earth Stations


The following references are relevant:

Volume 1, Chapter 8, Section 3

Volume 3, Part 2, Chapter 2, Section 8

Volume 3, Part 2, Chapter 6, Section 8

LESs that support the Land Mobile alerting service are only obliged to provide a service to those
MESs pre-registered for the service at that LES. Arrangements for handling and routing of Land
Mobile alerts is a matter for the LES operator.

LESs not providing the service, or not providing the service to a MES sending an alert to that LES
need not send an acknowledgement to that MES.

Volume 2: User Services, Part 1: Services and Facilities, Page: 2


Chapter 11: Land Mobile Alerting
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 12: Basic X.400 Service

Contents

1 Description of Service ............................................................. 2

2 Inmarsat-C Protocol Used ........................................................ 2

3 Requirements and Recommendations for Mobile Earth Stations2

4 Requirements and Recommendations for Land Earth Stations.. 2

Volume 2: User Services, Part 1: Services and Facilities, Page: 1


Chapter 12: Basic X.400 Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Description of Service
The CCITT X.400 series recommendations are a set of recommendations concerning message
handling. Message handling systems and services enable users to exchange messages on a store
and forward basis. Since the Inmarsat-C system is also based on store and forward principles, the
provision of X.400 services provides a natural extension of the capabilities of the system.

The X.400 element of service support is restricted. Support for the X.400 Interpersonal Messaging
Service (IPMS) application has been defined, i.e. the E-Mail application of X.400.
A simple plain text approach has been taken for transferring the X.400 envelope and header parts.

2 Inmarsat-C Protocol Used


The Basic X.400 service makes use of the Inmarsat-C store and forward message transfer protocols.
The protocols are described in detail in Volume 1. In particular Volume 1, Chapter 4.
Packet definitions are included in Volume 4. The following references in Volume 4 are particularly
relevant:

Volume 4, Chapter 3, 4 and 5.

Volume 4, Chapter 12.

The SDL figures are given in Volume 5.

3 Requirements and Recommendations for Mobile Earth Stations


The following requirements are relevant:

Volume 3, Part 2, Chapter 2.

4 Requirements and Recommendations for Land Earth Stations


The following requirements are relevant:

Volume 3, Part 1, Chapter 2, Sections 5

The following CCITT Recommendations are also relevant to Basic X.400 interworking:

T.300 General principles of telematic interworking

T.330 Telematic access to IPMS

X.208 Specification of abstract syntax notation one (ASN.1)

X.400 Message handling system and service overview

X.407 Message handling systems: abstract service definition conventions

X.410 Message handling systems: message transfer system

X.411 Message handling systems: message transfer system: abstract service definition and
procedures

X.419 Message handling systems: protocol specifications

Volume 2: User Services, Part 1: Services and Facilities, Page: 2


Chapter 12: Basic X.400 Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

X.420 Message handling systems: interpersonal messaging system

A document entitled Basic Inmarsat-C/X.400 Interworking Specification is also available from Inmarsat
for use by Inmarsat-C LES operators and LES manufacturers.

Volume 2: User Services, Part 1: Services and Facilities, Page: 3


Chapter 12: Basic X.400 Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Application Note 1: Chinese Character Transmission

Contents

1 Introduction ............................................................................ 2
1.1 Structure of Chinese Characters .......................................................................2
1.1.1 Chinese Character Standard Telegraphic (CST) Code ..................................2
1.1.2 Graphic character internal (GCI) code ...........................................................2

2 Inmarsat-C Protocol Used ........................................................ 2

3 Mobile Earth Station Requirements .......................................... 2


3.1 Character coding ...............................................................................................3
3.2 Display devices .................................................................................................3
3.3 MES memory capacity requirement ..................................................................3
3.4 Code translation of Chinese characters ............................................................3

Volume 2: User Services, Part 2: Application Notes, Page: 1


Application Note 1: Chinese Character Transmission
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
This Application Note explains how Chinese characters may be transmitted and received in IA5 code
and Graphic Character Internal (GCI) code.

1.1 Structure of Chinese Characters


There are more than 10,000 Chinese characters but only 6,000 – 7,000 are commonly used in China.
Two kinds of coding methods are adopted to transmit and receive these characters: the Chinese
character Standard Telegraphic (CST) code and the Graphic Character Internal (GCI) code.

1.1.1 Chinese Character Standard Telegraphic (CST) Code


This code is based on combinations of four decimal digits per Chinese character. The combination of
digits 0000-9999 are transmitted using ITA2 code.
For example:

3352 1316 0668 3938 0060 3189 0057 5898 2502 c- 2871 0402 4541

Meaning: Chinese characters may be applied in the Inmarsat-C system.

The digits may also be transmitted in IA5 code.

1.1.2 Graphic character internal (GCI) code


The GCI code is based on combinations of binary numbers. One Chinese character is encoded into
two bytes; each byte uses eight bits and the highest bit in every byte must have the value 1.
For example:

1 1 0 0 1 1 1 0
1 1 0 0 0 0 0 0 } Meaning: satellite
1 1 0 1 0 0 0 0
1 1 0 0 0 1 1 1
}

2 Inmarsat-C Protocol Used


When the Chinese character Standard Telegraphic (CST) code is used in the telex messaging or
EGC, the digits shall be encoded in IA5.

When the Graphic Character Internal (GCI) code is used, the presentation code shall be 07H (Data).
Parity checking shall not be performed. Refer to Volume 4, Chapter 5.

3 Mobile Earth Station Requirements

Volume 2: User Services, Part 2: Application Notes, Page: 2


Application Note 1: Chinese Character Transmission
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.1 Character coding


When the CST code is used, digits representing each Chinese character shall be encoded in eight
bits using odd parity. Chinese characters in GCI code shall use eight bits in each byte without parity.

3.2 Display devices


Display devices should be able to handle Chinese characters.

3.3 MES memory capacity requirement


It is recommended that at least 512 Kbytes memory capacity be provided to meet the demand of
Chinese character processing software.

3.4 Code translation of Chinese characters


The conversion function between the code and the Chinese characters may be performed as follows:

KEYBOARD
ADMINISTRATION
MODULE
GCI
GCI

CHINESE CHARACTER GCI DISPLAY


PROCESSING ADMINISTRATION
MODULE MODULE

GCI GCI CCM GCI

COMMUNICATION PRINTING GCI CHARACTER LIBRARY


ADMINISTRATION ADMINISTRATION ADMINISTRATION
MODULE MODULE CCM MODULE

CCM GCI

COMMUNICATION NETWORK PRINTER CHINESE


CHARACTER
LIBRARY

CCM ----- Chinese Character Dot Matrix

GCI ----- Graphic Character Internal Code

The diagram above is a typical "Chinese character DOS" module chart.

Volume 2: User Services, Part 2: Application Notes, Page: 3


Application Note 1: Chinese Character Transmission
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

In order to convert Chinese characters in GCI code into figures in ASCII code, the code conversion
module should be included between the Chinese character processing module and the English
language processing module:

CHINESE
ENGLISH
ASCII CONVERSION GCI CHARACTER
PROCESSING
MODULE PROCESSING
MODULE
MODULE

The structure of the conversion module is as follows:

ASCII GCI
CODE CONVERSION
ADMINISTRATION
MODULE

CODE
CONVERSION
TABLE

When a file in GCI code is processed by the CGI to ASCII conversion administration module, it
performs a look-up for the corresponding IA5 characters using the code conversion table, and then
transfers the converted file to the English processing module for further processing and to be sent to
the MES DCE.

When a file in IA5 is processed by the ASCII to CGI conversion administration module, it performs a
look-up for the corresponding CGI characters using the code conversion table and then transfers the
converted file to the Chinese character processing module for display and printing.

Volume 2: User Services, Part 2: Application Notes, Page: 4


Application Note 1: Chinese Character Transmission
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Application Note 2: Position Reporting Service

Contents

1 Introduction ............................................................................ 5

2 Inmarsat-C Protocols Used ...................................................... 5


2.1 Data Reporting ..................................................................................................5
2.2 Polling ...............................................................................................................5
2.3 Message Acknowledgements ...........................................................................5
2.3.1 Data Reporting Protocol ................................................................................5
2.3.2 Polling Commands .........................................................................................5
2.4 Formats of Data Report Packets .......................................................................5
2.4.1 General Packet Format ..................................................................................5
Figure 1: Data Report Packet Format .....................................................................6
2.4.1.1 P (1 bit) ................................................................................................................................... 6

2.4.1.2 C (1 bit)................................................................................................................................... 6

2.4.1.3 Type (6 bits) ........................................................................................................................... 6

2.4.1.4 LES ID (1 byte) ....................................................................................................................... 6

2.4.1.5 Closed Data Network ID (DNID) (2 bytes) ............................................................................. 6

2.4.1.6 Member No (1 byte) ............................................................................................................... 6

2.4.1.7 Category (2 bits) ..................................................................................................................... 6

2.4.1.7.1 Sub-Category (6 bits) .......................................................................................................... 7

2.4.2 Land Mobile Position Report ..........................................................................7


2.4.2.1 Data Reporting Protocol ......................................................................................................... 7

Figure 2: Land Mobile Position Report (Data Reporting Protocol) ..........................7


2.4.2.1.1 Category (2 bits).................................................................................................................. 7

2.4.2.1.2 Position (39 bits) ................................................................................................................. 8

2.4.2.1.2.1 Latitude (19 bits) .............................................................................................................. 8

2.4.2.1.2.1.1 Hemisphere (1 bit)......................................................................................................... 8

2.4.2.1.2.1.2 Degrees (7 bits)............................................................................................................. 8

2.4.2.1.2.1.3 Minutes (6 bits).............................................................................................................. 8

2.4.2.1.2.1.4 Fractional part (5 bits) ................................................................................................... 8

Volume 2: User Services, Part 2: Application Notes, Page: 1


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.4.2.1.2.2 Longitude (20 bits) ........................................................................................................... 8

2.4.2.1.2.2.1 Hemisphere (1 bit)......................................................................................................... 8

2.4.2.1.2.2.2 Degrees (8 bits)............................................................................................................. 8

2.4.2.1.2.2.3 Minutes (6 bits).............................................................................................................. 8

2.4.2.1.2.2.4 Fractional part (5 bits) ................................................................................................... 8

2.4.2.1.3 Macro Encoded Message (MEM) (7 bits) ........................................................................... 8

2.4.2.1.4 Attribute (16 bits) ................................................................................................................. 8

2.4.2.1.5 Reserved (2 bytes) .............................................................................................................. 9

2.4.2.1.6 User Defined Field .............................................................................................................. 9

2.4.3 Maritime Position Report ................................................................................9


2.4.3.1 Data Reporting Protocol ......................................................................................................... 9

Figure 3: Maritime Position Report (Data Reporting Protocol) ................................9


2.4.3.1.1 Category (2 bits).................................................................................................................. 9

2.4.3.1.2 Speed (1 byte) ..................................................................................................................... 9

2.4.3.1.3 Course (9 bits) ..................................................................................................................... 9

2.4.3.1.4 Reserved (15 bits) ............................................................................................................... 9

2.4.3.1.5 Macro Encoded Message (MEM) (7 bits) ......................................................................... 10

2.4.3.1.6 Attribute (16 bits) ............................................................................................................... 10

2.4.4 Poll Acknowledgement ................................................................................. 10


2.5 Use of Polling Protocol .................................................................................... 10
Figure 4: Polling Command Format ...................................................................... 11
2.5.1 Header ......................................................................................................... 11
Figure 5: Polling Packet Format ............................................................................ 12
2.5.1.2 Header contents ................................................................................................................... 12

2.5.2 Command Field ............................................................................................ 12


2.5.2.1 Define Macro Encoded Message ......................................................................................... 13

2.5.2.2 Initiate Reporting using Reserved Data Reporting Protocol ................................................ 13

2.5.2.2.1 Supplementary Parameters (16 bits) ................................................................................ 13

2.5.2.2.1.1 Category (2 bits)............................................................................................................. 13

2.5.2.2.1.2 N (2 bits)......................................................................................................................... 13

2.5.2.2.1.3 Sub-Category (6 bits) ..................................................................................................... 13

2.5.2.2.1.4 Spare (6 bits).................................................................................................................. 13

Volume 2: User Services, Part 2: Application Notes, Page: 2


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.5.2.3 Initiate Unreserved Data Reporting...................................................................................... 13

2.5.2.4 Macro Encoded Message Transmission .............................................................................. 13

2.5.2.5 Data Transmission ............................................................................................................... 13

2.5.2.6 Program Reserved Data Reporting...................................................................................... 14

2.5.2.7 Program Unreserved Data Reporting .................................................................................. 14

2.5.2.8 Send Report ......................................................................................................................... 14

2.5.2.9 Stop Reserved Reporting: .................................................................................................... 14

2.5.2.10 Stop Unreserved Data Reporting ....................................................................................... 14

2.6 DATA Encryption ............................................................................................ 14


2.6.1 Data Report.................................................................................................. 14
2.6.1.1 User Data ............................................................................................................................. 14

2.6.2 Poll Command.............................................................................................. 14

3 Requirements for Mobile Earth Stations ................................ 15


Figure 6: Typical MES Used for Position Reporting .............................................. 15
3.1 Mobile Initiated Reporting ............................................................................... 15
3.2 Polled Reporting ............................................................................................. 15
3.3 Acknowledgement ........................................................................................... 15

4 Requirements for Land Earth Stations ................................... 15


4.1 Delivery of Position Reports by the LES ......................................................... 15
4.1.1 Formatting of Position Reports and other message types by the LES ......... 16
Figure 7: Message Types...................................................................................... 16
Figure 8: Format of Position Report or Related Message as Forwarded to a
Customer ............................................................................................... 16
4.1.2 Terrestrial Access Methods.......................................................................... 17
4.2 DNIDs At Different LESS ................................................................................ 17

5 Terrestrial Access to the Position Reporting Service ............. 17


5.1 Command Field ............................................................................................... 17
5.2 Free Field ........................................................................................................ 17

6 Macro Encoded Messages ..................................................... 17


6.1 Definition of Macro Encoded Messages (Land Mobile to base) ...................... 17

Volume 2: User Services, Part 2: Application Notes, Page: 3


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6.1.1 Messages Related to Vehicle Status ........................................................... 18


6.1.2 Messages Related to Driver Status .............................................................. 18
6.1.3 Messages Related to Route Status .............................................................. 19
6.1.4 Messages Related to Customer Premises ................................................... 19
6.1.5 Messages Related to Cargo......................................................................... 19
6.1.6 Messages Related to Road, Weather and Traffic Conditions....................... 20
6.1.7 Emergency Message ................................................................................... 20
6.1.8 Reserved for Inmarsat Use .......................................................................... 20
6.1.9 User-Defined Messages............................................................................... 20
6.2 Definition of Macro Encoded Messages (Maritime Terminal to Base) ............. 23
6.3 Definition of Macro Encoded Messages (Base to Land Mobile) ...................... 23
6.4 Definition of Macro Encoded Messages (Base to Maritime Terminal) ............. 23

Volume 2: User Services, Part 2: Application Notes, Page: 4


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
This Application Note describes essential elements of a Position Reporting Service that is suitable for
Land Mobile and Maritime users. It has been designed using the Data Reporting and Polling Protocols
of the Inmarsat-C system. Full details of packet contents are provided for system designers.

A Position Reporting System provides means for determining the location of a mobile terminal and the
method by which the information is relayed back to a Base Station that requires the information. In
addition, by using the Polling protocol, the Base Station can actually request that the mobile transmits
the appropriate information. In the system described below, further facilities such as the ability of the
MES to transmit and receive coded or plain text messages, are described.

The position of an MES is determined by means of an on-board navigational system such as GPS,
GLONASS, Loran-C, Omega, etc. Whilst this Application Note mainly describes a Position Reporting
Service, the service provides the capability for coded and plain text transmission and a range of
sensor inputs such as temperature and pressure for example.

2 Inmarsat-C Protocols Used

2.1 Data Reporting


The Position Reporting Service is based on the use of the Data Reporting or the Pre-assigned Data
Reporting Protocol which are described in Volume 1, Chapters 5 and 7. These are referred to in the
text as Unreserved and Reserved Data Reporting respectively.

The Data Reports are sent by the MESs to LESs for subsequent retrieval by the Base Station (for
example, Shipping or Freight company head offices) or the reports can be forwarded automatically
depending on local facilities.

2.2 Polling
The Polling protocol is described in Volume 1, Chapter 6.

2.3 Message Acknowledgements

2.3.1 Data Reporting Protocol


The slot state markers advise the MES whether to retransmit a packet. See Volume 1, Chapter 5.

2.3.2 Polling Commands


A polling command can request all addressed MESs to respond with a Data Report which
acknowledges the receipt of a polling command.

2.4 Formats of Data Report Packets


A Position Report is transmitted by a MES as a Data Report of up to 3 packets.

The high order bit of the fields shown in the following diagrams is the leftmost bit of the field. Where a
field is wrapped-around from byte to byte, the high order bit is the leftmost bit of the first part.

2.4.1 General Packet Format


The general format for reserved or unreserved Data Reporting is given in Figure 1 below.

Volume 2: User Services, Part 2: Application Notes, Page: 5


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: Data Report Packet Format

Bit No. Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
1 P C Type 1 P C Type 1 P C Type
2 2 2
DN ID
3 3 3
4 LES ID 4 4
5 Member No. 5 5
6 Cat Sub-category 6 6
7 7 Data 7 Data
Byte

8 8 8
9 Data 9 9
10 10 10
11 11 11
12 12 12
13 13 13
14 Check sum 14 Check sum 14 Check sum
15 15 15
Data Report Packet First Continuation Packet Second Continuation Packet
(Optional) (Optional)

The packet contents are described below:

2.4.1.1 P (1 bit)

Gives the priority of the Data Report and is set to 0.

2.4.1.2 C (1 bit)

The continuation bit: indicates if there is a subsequent packet.

2.4.1.3 Type (6 bits)

The Type field is set to 04H (Data Report).

2.4.1.4 LES ID (1 byte)

Identifies the LES to which the report is to be transmitted.

2.4.1.5 Closed Data Network ID (DNID) (2 bytes)

Identifies the DNID to which the MES belongs.

2.4.1.6 Member No (1 byte)

Identifies the MES in a closed network. One byte allows 256 members in a group. If more are required
additional DNIDs can be allocated for the user group.

2.4.1.7 Category (2 bits)

This field is used to specify the report category:

00B Land Mobile Position Report


01B Maritime Position Report
10B Extended
11B Spare

The Extended Category is used when sub-categories are required (see 2.4.1.7.1).

Volume 2: User Services, Part 2: Application Notes, Page: 6


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.4.1.7.1 Sub-Category (6 bits)

This field is included only if the Extended Category is selected (see 2.4.1.7).

The sub-categories are divided into:

00H Poll Acknowledge (see Volume 4, Chapter 9)


01H-2FH Reserved
30H-3FH User defined

The reserved sub-categories will be used to define additional standardised reports. Examples of sub-
categories that might be included are:

AMVER (Automated Mutual assistance Vessel Rescue System)

JASREP (Japan Ship Reporting System)

AUSREP (Australian Ship Reporting System)

Maritime Weather Report

The user defined sub-categories can be used to identify user defined reports, i.e. reports where the
user defines the interpretation of the data.

2.4.2 Land Mobile Position Report


2.4.2.1 Data Reporting Protocol

The format of the packets is given in Figure 2. The first packet contains a Position Report, a Macro
Encoded Message (MEM) and an associated Attribute. A second optional packet contains 2 reserved
bytes.

Figure 2: Land Mobile Position Report (Data Reporting Protocol)

Bit No. Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

Type 1 PC Type 1 PC Type


1 P C
2 2
2 Reserved
DN ID 3 3
3 4 4
4 LES ID
Member no 5 5
5 6 6
6 Cat H Deg-
7 7 User Defined
Position

7 -rees Minutes Lat.


Byte

Byte
Byte

Fraction part 8 User Defined 8


8 H Deg-
9 9
9 -rees Min-
Long. 10 10
10 -utes Fraction pa 11 11
11 rt MEM 12 12
12 Attribute 13 13
13
14 14
14 Check sum 15 Check sum 15 Check sum
15
Data Report Packet First Continuation Packet Second Continuation Packet
(Optional) (Optional)

Only the fields specific to Position Reports are described in the following paragraphs.

2.4.2.1.1 Category (2 bits)

Volume 2: User Services, Part 2: Application Notes, Page: 7


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The Category is 00B for Land Mobile Position Reports.

2.4.2.1.2 Position (39 bits)

[Position] ::= [Latitude][Longitude]

2.4.2.1.2.1 Latitude (19 bits)

[Latitude] ::= [Hemisphere][Degrees]


[Minutes][Fractional part]

2.4.2.1.2.1.1 Hemisphere (1 bit)

A North/South flag. Set to 0 for North or 1 for South.

2.4.2.1.2.1.2 Degrees (7 bits)

The degrees of Latitude, North or South.

2.4.2.1.2.1.3 Minutes (6 bits)

The integer part of the Minutes of latitude.

2.4.2.1.2.1.4 Fractional part (5 bits)

The fractional part of the Minutes of latitude in units of 0.04 of a Minute.

2.4.2.1.2.2 Longitude (20 bits)

[Longitude] ::= [Hemisphere][Degrees]


[Minutes][Fractional part]

2.4.2.1.2.2.1 Hemisphere (1 bit)

An East/West flag. Set to 0 for East or 1 for West.

2.4.2.1.2.2.2 Degrees (8 bits)

The degrees of Longitude, East or West.

2.4.2.1.2.2.3 Minutes (6 bits)

The integer part of the Minutes of longitude.

2.4.2.1.2.2.4 Fractional part (5 bits)

The fractional part of the Minutes of longitude in units of 0.04 of a Minute.

2.4.2.1.3 Macro Encoded Message (MEM) (7 bits)

A Macro Encoded Message (MEM) is a pre-defined message represented by a unique 7 bit code.
00H to 7FH are defined in Section 6.1.

2.4.2.1.4 Attribute (16 bits)

A parameter of the Macro Encoded Message. The use of this field is determined by the value of the
Macro Encoded Message (MEM). For the use and format of this attribute field for each MEM (see
Section 6).

Volume 2: User Services, Part 2: Application Notes, Page: 8


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.4.2.1.5 Reserved (2 bytes)

Unused and set to zero.

2.4.2.1.6 User Defined Field

10 bytes are available in the first continuation packet and 12 bytes in the second continuation packet
for user definition.

2.4.3 Maritime Position Report


2.4.3.1 Data Reporting Protocol

The format of the packet is shown in Figure 3 below. The first packet has the same format as in the
Land Mobile case and contains a Position Report, a Macro Encoded Message (MEM) and Attribute.
The second, optional, packet contains the Speed and the Course of the ship.

Figure 3: Maritime Position Report (Data Reporting Protocol)

Bit No. Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
1 PC Type 1 PC Type 1 P C Type
2 DN ID 2 Speed 2
3 3 Course 3
4 LES ID 4 Reserved 4
5 Member no 5 5
6 Cat 6 6
7 7 7 User Defined
Byte

8 Position 8 8
9 9 User Defined 9
10 10 10
11 MEM 11 11
12 12 12
Attribute
13 13 13
14 Check sum 14 Check sum 14 Check sum
15 15 15
Data Report Packet First Continuation Packet Second Continuation Packet
(Optional) (Optional)

Only the fields specific to Maritime Position Reports (or with differences of use) are described below.

2.4.3.1.1 Category (2 bits)

The Category is 01B for Maritime Position Reports.

2.4.3.1.2 Speed (1 byte)

Speed is coded as a one byte unsigned binary number with a resolution of 0.2 knots. If no valid data
is available at the MES, the field should be set to "FFH".

2.4.3.1.3 Course (9 bits)

The Course is coded as a 9 bit unsigned binary number with a resolution of 1 degree. If no valid data
is available at the MES, the field should be set to "1FFH ".

2.4.3.1.4 Reserved (15 bits)

Unused and set to zero.

Volume 2: User Services, Part 2: Application Notes, Page: 9


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.4.3.1.5 Macro Encoded Message (MEM) (7 bits)

A Macro Encoded Message (MEM) is a pre-defined message represented by a unique 7 bit code.
00H to 3FH are defined in section 11.2. The remaining codes are user definable.

2.4.3.1.6 Attribute (16 bits)

A parameter of the Macro Encoded Message. The use of this field is determined by the value of the
Macro Encoded Message (MEM). For the use and format of this attribute field for each MEM see
section 6.2.

2.4.4 Poll Acknowledgement


Under certain circumstances (see Section 8.3) the MES is requested to send a separate Poll
Acknowledgement. This takes the form of a Data Report with the format as defined in Volume 4,
Chapter 9.

2.5 Use of Polling Protocol


Polling Commands are used for the following purposes in the Position Reporting Service:

- to initiate Data Reports from one or several MESs.

- to send a text or data messages to MESs.

- to program MESs with the parameters used for the Reserved Data Reporting Protocol

(see Volume 1, Chapter 7).

The Polling Command consists of two main parts:

a) a Header field, and

b) a Text field.

It is important to note that the Polling Command packet descriptor, Header field, Text Field and
Checksum may not exceed 300 bytes.

The Text field can contain Command Specific Parameters pertinent to a particular Polling Command
and optionally a Supplementary Parameters field followed by a Free field.

The Supplementary Parameters Field contains additional application specific parameters appropriate
to the command type. The Free field, when present, can be used for user data.

Volume 2: User Services, Part 2: Application Notes, Page: 10


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 4: Polling Command Format

Bit No.
8 7 6 5 4 3 2 1

Header

Command specific
parameters

Supplementary
Parameters field

Free field
(optional)

2.5.1 Header
There are three header types for Individual, Group and Area Polling Command. They are shown in
Figure 5.

Volume 2: User Services, Part 2: Application Notes, Page: 11


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 5: Polling Packet Format

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
1 1
DN ID
2 MES ID 2
3 3 LES ID
4 LES ID 4 LES TDM
5 Sub-address 5
6 6 Sub-address
DNID 7 Randomising Interval
7
Byte

Byte
8 R Spare 8 R Spare
9 Command 9 Command
10 Sequence No. 10 Sequence No.
11 11
Command specific Command specific
12 12
parameters parameters
13 13
14 Supplementary 14 Supplementary
15 Parameters Field 15 Parameters Field

Free Field Free Field

Individual Poll Group Poll

Bit No.
8 7 6 5 4 3 2 1
1
DNID
2
3 LES ID
4
LES TDM
5
6 Sub-address
7 Randomising Interval
Byte

8 R Type Length
9 Area
10 Command
11
Sequence No.
12
13 Command specific
14 parameters
15 Supplementary
Parameters Field
Free Field
Area Poll

2.5.1.2 Header contents

These are described in Volume 4, Chapter 9.

2.5.2 Command Field


The Command Field is defined in Volume 4, Chapter 9. It includes an Acknowledgement sub-field and
a Command type sub-field. The Acknowledgement sub-field can be set at the discretion of the User,
see Volume 4, Chapter 9. The Position Reporting service uses only some of the basic commands of

Volume 2: User Services, Part 2: Application Notes, Page: 12


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

the Polling Protocol and defines no further ones. A number of the commands require the
Supplementary parameters field. The commands used are described below.

The Position Reporting service also uses the Response field in the Poll Header. Only two values are
used: 0 (No Response) or 1 (Data Report) as appropriate to the command.

2.5.2.1 Define Macro Encoded Message

Uses the Polling protocol (see Volume 1, Chapter 6 and Volume 4, Chapter 9).

The supplementary parameters field is not used.

2.5.2.2 Initiate Reporting using Reserved Data Reporting Protocol

Used to initiate Data Reporting using the Pre-Assigned Data Reporting protocol (see Volume 1,
Chapter 7). The supplementary parameters field is used:

2.5.2.2.1 Supplementary Parameters (16 bits)

[Supplementary Parameters] ::= [Category][Sub-category][N][Spare]

2.5.2.2.1.1 Category (2 bits)

Advises the MES what category of Data Report is to be transmitted (see Section 2.4.1.7).

2.5.2.2.1.2 N (2 bits)

Number of continuation packets to be transmitted. ( 0 – 2 )

2.5.2.2.1.3 Sub-Category (6 bits)

Advises the MES what sub-category is to be transmitted (see Section 2.4.1.7.1).

2.5.2.2.1.4 Spare (6 bits)

Unused and set to zero.

2.5.2.3 Initiate Unreserved Data Reporting

Used to initiate regular reporting by means of the Unreserved Data Reporting protocol. Response is
set to 1 (Data Report). The Supplementary parameters field is used. The sub-fields have the same
format and purpose as described in 2.5.2.2.1.

2.5.2.4 Macro Encoded Message Transmission

Used to send an agreed abbreviation for a common message from base to terminal. Codes in the
reserved range 0 - 3FH are defined in Sections 11.1.3 and 11.1.4. See the Polling protocol (Volume 1,
Chapter 6).

The Supplementary parameters field is used to convey the attribute as defined in Sections 6.1.3 and
6.1.4 for the codes listed therein. The sub-fields have the same format and purpose as described in
2.5.2.2.1.

2.5.2.5 Data Transmission

Available for use to send any byte oriented binary data or text.

The Supplementary parameters field is not used.

Volume 2: User Services, Part 2: Application Notes, Page: 13


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.5.2.6 Program Reserved Data Reporting

Uses the Pre-Assigned Data Reporting protocol (see Volume 1, Chapter 7).

The supplementary parameters field is not used.

2.5.2.7 Program Unreserved Data Reporting

Uses the Polling protocol (see Volume 1, Chapter 6).

The supplementary parameters field is not used.

2.5.2.8 Send Report

This command is used to request the MES to send a Report using the Unreserved Data Reporting
Protocol. Response is set to 1 (Data Report). The Supplementary parameters field is used. The sub-
fields have the same format and purpose as described in 2.5.2.2.1.

2.5.2.9 Stop Reserved Reporting:

Used to stop reporting by means of the Reserved Data Reporting protocol. Response is set to 1 (Data
Report) and the Poll Ack bit is set.

The sub-address in the header indicates which device is to stop reporting. If the sub-address is 0, all
devices are requested to stop reporting.

2.5.2.10 Stop Unreserved Data Reporting

Uses the Polling protocol (see Volume 1, Chapter 6).

The supplementary parameters field is not used.

2.6 DATA Encryption

2.6.1 Data Report


The following fields may be encrypted at the discretion of the User.

2.6.1.1 User Data

Packet Byte

First packet 6- 13
Continuation packets 2 - 13

2.6.2 Poll Command


The Free Field of the Poll Command may be encrypted.

Volume 2: User Services, Part 2: Application Notes, Page: 14


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3 Requirements for Mobile Earth Stations


The MES shall be capable of sending Position Reports using the Unreserved and the Reserved Data
Reporting protocol.

Figure 6: Typical MES Used for Position Reporting

3.1 Mobile Initiated Reporting


When unreserved data reporting is used, the MES shall be capable of either sending a single position
report or of automatically sending reports according to a pre-programmed schedule (for example,
every hour).

For pre-programmed unreserved data reporting, the user and service provider must ensure that the
data report timing for the set of mobiles results in the bursts being spread around the nominal
reporting time to avoid channel overload problems.

3.2 Polled Reporting


An MES shall be able to send reports in response to the poll commands given in Section 2.5.

3.3 Acknowledgement
When an MES receives a polling command with the Ack sub-field of the command field in the
HEADER set to 1B, the MES should send a Poll Acknowledge (see Section 2.4.4.1 of Volume 4,
Chapter 9).

4 Requirements for Land Earth Stations


The following factors in relation to the receipt, storage and access to Data Reports from MESs should
be taken into account by designers of LES equipment.

4.1 Delivery of Position Reports by the LES

Volume 2: User Services, Part 2: Application Notes, Page: 15


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.1.1 Formatting of Position Reports and other message types by the LES
Incoming Position Reports and related messages should be prepared for delivery by the addition of a
header as shown below. Reports that consist of more than one packet are first concatenated to form a
single item. Thus the Continuation bit is not used when the Report is forwarded to the Subscriber.
Furthermore, the Checksum field is omitted when the Report is forwarded. What is shown as Position
Report Data in the figure below, consists of all remaining fields. The Length field indicates the number
of bytes in the Position Report Data field. The LES ID is included to allow differentiation of DNIDs in a
joint file retrieved from a dual Ocean Region LES. A Message Type field and the Presentation field
(Volume 4, Chapter 3, Section 4.13) to allow differentiation of text messages from Position Reports
and their interpretation. Values for message types are:

Figure 7: Message Types

Message Type Represents

0H Data Report

1H Store and Forward Message

2H-FH Reserved

Figure 8: Format of Position Report or Related Message as Forwarded to a


Customer

Bit No.
8 7 6 5 4 3 2 1

.. DNID ..

.. LES ID ..

.. Year ..
Date and Tim e Stam p
(ASCII)
.. M onth ..

.. Day ..

.. Hour ..

.. M inute ..

M em ber No

M essage Type

Presentation

Length

Position Report
Data or
M essage Text

Volume 2: User Services, Part 2: Application Notes, Page: 16


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.1.2 Terrestrial Access Methods


The manner of delivery of Position Reports is determined by the LES operators and may take any of
the following forms:

a) Supplied on demand, either singly or in batches. Note that if the reports are to be supplied in
batches, it will be necessary to use a blocking structure, that makes it possible to determine
how many reports appear in a batch. For example, using X.25 packets it would be possible to
pack two to a packet and set the packet length to reflect this. The receiver can immediately
determine the number of reports enclosed and where each starts and ends, since each report
has a fixed header of 17 bytes and the length of the variable part is included in the report
header. If another method of transmission is used (for example, transmission via an
asynchronous serial link) it may be necessary to use block start and block end control
characters or to indicate the length of the block at its start. The latter method is more
appropriate since position reports contain binary data;

b) Delivered as agreed, for example according to an agreed schedule or immediately upon


reception;

c) By the use of a Value Added service, such as a Mailbox service.

d) If the TELEX network is used for access, it is recommended that translation from binary code to
ITA 2 be performed, via a Hexadecimal process.

For example, 01101010 Binary is split into two 4 bit "Nibbles" of 0110 and 1010. These translate to
Hex 6 and A respectively. The 6 and the A will then be transmitted on the telex network as ITA 2
characters.

4.2 DNIDs At Different LESS


If a fleet requires service to be provided by one or more LESs, for example for restoration purposes,
then DNIDs should be allocated at each LES. LESs should ignore Data Reports addressed to DNIDs
not registered with them (i.e. the packets may be discarded).

5 Terrestrial Access to the Position Reporting Service


Base stations access the Polling Services via a Land Earth Station as described in Volume 3, Part 1,
Chapter 2. In the Position Reporting service, the information that is to be carried in the DATA field
consists of a COMMAND field and a FREE field.

The method of transmission of this information to the LES is described below:

5.1 Command Field


The COMMAND field should be transmitted to the LES as a Byte oriented binary field.

5.2 Free Field


The FREE field should be transmitted to the LES as a Byte oriented binary field.

6 Macro Encoded Messages

6.1 Definition of Macro Encoded Messages (Land Mobile to base)


The Macro Encoded Message field with the associated Attribute field is used to send a message.

Volume 2: User Services, Part 2: Application Notes, Page: 17


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The following messages are proposed:

(If no valid message is available, the MEM code should be set to zero.)

6.1.1 Messages Related to Vehicle Status

MEM Message Attribute Attr. Note


Code Code
1 The vehicle is.. at repair 1 1)
at maintenance 2
ready for service 3
not ready for service 4
2 Engine hours hours in units of 10 h * 1)
3 Engine mileage km in units of 10 km * 1)
4 Distance to next service km in units of 10 km * 1)
5 Fuel consumption last litre/10 km in units of 0.1 litre * 1)
10,000 km
6 Error code of on-board code number * 1)
diagnostics
7 The load status of the empty 1 1)
vehicle is... full 2
partial 3
loaded 4
unloaded 5
8 units * 1)
Rest capacity

6.1.2 Messages Related to Driver Status

MEM Message Attribute Attr. Note


Code Code
9 The driver is... ready for work 1 1)
not ready for work 2
on break 3
at end of shift 4
at beginning of shift 5
10 Remaining shift time hours in units of 0.1 h * 1)

Volume 2: User Services, Part 2: Application Notes, Page: 18


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6.1.3 Messages Related to Route Status

MEM Message Attribute Attr. Note


Code Code
11 Time of position date, time * 2)
12 Estimated time of Arrival date, time * 2)
(ETA)
13 Actual Time of Arrival date, time * 2)
(ATA)
14 Estimated Time of date, time * 2)
Departure (ETD)
15 Actual Time of Departure date, time * 2)
(ATD)
16 Estimated Delay (ED) hours in units of 0.1 h * 1)
17 Actual Delay (AD) hours in units of 0.1 h * 1)
18 Mileage since start of km in units of 1 km * 1)
19 route traffic 1 1)
Delay caused by... road condition 2
weather 3
customer 4
authorities 5
customs 6

6.1.4 Messages Related to Customer Premises

MEM Message Attribute Attr. Note


Code Code
20 Conditions at customer no loading/unloading possible; 1 1)
premises: instructions requested
delay at customer dispatch 2 1)
no service personnel available 3 1)
no loading assistance available 4 1)

6.1.5 Messages Related to Cargo

MEM Message Attribute Attr. Note


Code Code
21 Cargo status: Loading 1)
according to plan 1
no space for full load on truck 2
load not available 3
Unloading
according to plan 4
vehicle empty; new order possible 5
Customer not ready for reception; 6
instructions requested
22 Cargo temperature Compartment / sensor number and * 3)
temperature
23 New orders TBD TBD TBD

Volume 2: User Services, Part 2: Application Notes, Page: 19


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6.1.6 Messages Related to Road, Weather and Traffic Conditions

MEM Message Attribute Attr. Note


Code Code
24 Traffic, road and weather Traffic condition 1)
condition smooth traffic 1
traffic congestion 2
traffic jam 3
road closed 4
Road condition
no problems 5
wet surface 6
snow covered surface 7
only passable with snow chains 8
ice/sleet 9
not passable 10
Weather condition
Rain 11
Snow 12
Fog 13
Storm 14

6.1.7 Emergency Message

MEM Message Attribute Attr. Note


Code Code
25 Emergency See Note 4. * 4)

6.1.8 Reserved for Inmarsat Use

MEM Message Attribute Attr. Note


Code Code
26-63 RESERVED

6.1.9 User-Defined Messages

MEM Message Attribute Attr. Note


Code Code
64-127 USER -DEFINED

Notes:

1) Coded as a two byte unsigned binary number. The first byte is the most significant.

Example: 530D is coded as

02H (first byte)

12H (second byte).

2) Date, Time is coded as:

[Date, time]::=[month][day][hour][minute]

month (1 bit): 0 for this month

Volume 2: User Services, Part 2: Application Notes, Page: 20


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 for next month

day (5 bits): day of the month

hour (5 bits): hour of the day

minutes (5 bits) in units of 2 minutes

3) For the Cargo Temperature MEM the attribute field is redefined as below:

Bit No.
8 7 6 5 4 3 2 1

1
2
3
4
5
6
7
Byte

8
9
10
11 MEM=22
12 S CMPT Temp-
13 -erature } Redefined AttributeField
14 Check sum
15

Redefined Field Name Size Value Meaning


Field in
Bits

S Sign Bit 1 0 Negative


1 Positive
CMPT Compartment/ 4 0 - 15 Number of
Sensor Number compartment or
Temperature 11 0 - 2048 sensor with this
Temperature temperature
Temperature in units
of 0.1 degrees Celsius
(0 - 204.8)

Volume 2: User Services, Part 2: Application Notes, Page: 21


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4) For the Emergency Message the attribute field is redefined as below:

Bit No.
8 7 6 5 4 3 2 1
1
2
3
4
5
6
7
Byte

8
9
10
11 MEM=25
12
13
TOP SP DOT
Nature } Redefined AttributeField
14 Check sum
15

Redefined Field Name Size Value Meaning


Field in
Bits

TOP Time Of Position 3 0 < 1 minute old


1 1 to < 5 mins old
2 5 to < 30 mins old
3 30 to < 60 mins old
4 1 hour or older
5 Not Available
6 Spare
7 Spare

SP Speed 2 0 Stopped
1 Slow < 20 kph
2 Medium 20 to 70
3 Fast >70

DOT Direction Of Travel 3 0 N 337.5,<22.5


1 N E 22.5,<67.5
2 E 67.5,<112.5
3 S E 112.5,<157.5
4 S 157.5,<202.5
5 S W 202.5,<257.5
6 W 257.5,<292.5
7 N W 292.5,<337.5

Volume 2: User Services, Part 2: Application Notes, Page: 22


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Redefined Field Name Size Value Meaning


Field in
Bits

Nature Nature of Emergency 8 Ambulance required


1 1 person injured
2 2 persons
3 3 persons
4 4 persons
5 5 - 10 persons
6 11 - 20 persons
7 > 20 persons
Other Emergency
8 Accident - No injured
9 Hijack situation
10 Theft
11 Toxic cargo release
12 Fire
13 Flat Tyre
14 Out of fuel
15 Engine problem
16 Other mechanical
problem

6.2 Definition of Macro Encoded Messages (Maritime Terminal to Base)


[To be defined]

6.3 Definition of Macro Encoded Messages (Base to Land Mobile)


[To be defined]

6.4 Definition of Macro Encoded Messages (Base to Maritime Terminal)


[To be defined]

Volume 2: User Services, Part 2: Application Notes, Page: 23


Application Note 2: Position Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Application Note 3: Application Developers Guide to


Data Reporting and Polling

Contents

Glossary ...................................................................................... 5

1 Scope ..................................................................................... 6

2 Introduction ............................................................................ 7

3 Data Reporting and Polling in Inmarsat-C ................................ 7


3.1 Description ........................................................................................................7
3.2 Data Reporting ..................................................................................................7
3.2.2.1 Data transfer using unreserved access ............................................................................... 10

3.2.2.2 Data transfer using pre-assigned (reserved) access ........................................................... 10

3.3 Polling ............................................................................................................. 10


3.3.1 Addressing ................................................................................................... 10
3.3.2 Polling .......................................................................................................... 11
3.3.2.1 Individually Directed Polling ................................................................................................. 11

3.3.2.2 Group Directed Polling ......................................................................................................... 11

3.3.2.3 Area Directed Polling ........................................................................................................... 11

4 Example Application - Position Reporting Service ................. 11


Figure 2: Grouping of DNID-LES Pairs (Note that DNIDs are Reused by LESs) .. 13

5 role of the mes in Data Reporting and polling ........................ 14


5.1 MES Configurations ........................................................................................ 14
Figure 3: Inmarsat-C Data Reporting and Polling Protocol Hierarchy ................... 14
Figure 4: MES DCE Configurations ...................................................................... 15
5.2 Functions of the DCE ...................................................................................... 16
5.3 Functions of the DTE ...................................................................................... 16

6 LES Role in Data Reporting / Polling ..................................... 16


6.2 Confirmations .................................................................................................. 16

Volume 2: User Services, Part 2: Application Notes, Page: 1


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6.3 Member Number ............................................................................................. 16


6.4 Billing and Call Records .................................................................................. 16
6.5 Use of the Polling Protocol .............................................................................. 16
6.6 Delivery of Data Reports by the LES .............................................................. 17

7 Operation .............................................................................. 17
7.1 Poll Commands ............................................................................................... 17
7.2 Utilisation of poll fields, DTE & DCE................................................................ 17
Figure 5(a): Utilisation of Poll Fields...................................................................... 18
Figure 5(b): Utilisation of Poll Fields (Download DNID or Delete DNID) ............... 19
7.3 Permitted Commands by Poll Type ................................................................. 20
7.4 Acceptance of Polls ........................................................................................ 20
7.5 Parameter Checking ....................................................................................... 20
7.6 Unexpected Command ................................................................................... 21
7.7 Response to a Poll .......................................................................................... 21
7.8 Acknowledgements ......................................................................................... 21
7.9 Repeated Polls ................................................................................................ 22
7.9.1 Example Strategy for Poll Sequence Numbers ............................................ 22
7.10 Randomisation .............................................................................................. 23
7.11 Priority ........................................................................................................... 23
7.12 Programmed Data Reporting ........................................................................ 23
7.12.1 Unreserved Data Reporting ....................................................................... 23
Figure 6: Sub-Flowchart for MES Handling of Sequence Numbers ...................... 24
7.12.2 Reserved Data Reporting........................................................................... 25
7.13 Program Discontinuation ............................................................................... 25
7.14 Program Re-Starting ..................................................................................... 25
7.15 Program Deletion .......................................................................................... 25
7.16 Downloading of DNIDs .................................................................................. 26
7.17 Deletion of DNIDs ......................................................................................... 26
7.18 Loss of Power ............................................................................................... 26
7.18.1 Loss of Power - Unreserved Data Reporting.............................................. 26
Volume 2: User Services, Part 2: Application Notes, Page: 2
Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

7.18.2 Loss of Power - Pre-Assigned Data Reporting........................................... 26


7.19 Spot Beam Operation ................................................................................... 26
7.20 Multi-Threading ............................................................................................. 27
7.21 Precedence of Activities ................................................................................ 27
7.22 Restoration Mode .......................................................................................... 27
7.23 Parameters Stored in Non-Volatile Memory .................................................. 27
7.24 Macro Encoded Messages............................................................................ 28
7.25 Pre-assigned Data Reporting ........................................................................ 28

8 Protocol Limitations .............................................................. 28


8.1 Data Report Collisions .................................................................................... 28
8.2 MES Identification ........................................................................................... 29
8.3 Conflict of Functions ....................................................................................... 29
8.4 TDM Selection ................................................................................................ 29
8.5 Barring of MES................................................................................................ 29
8.6 Frequency of Data Reporting .......................................................................... 30
8.7 Global DNIDs .................................................................................................. 30
8.8 Member Number Limitations ........................................................................... 30
8.9 Management of Randomisation Interval.......................................................... 30
8.10 Common Terrestrial Interfacing..................................................................... 30
8.11 DNID Management ....................................................................................... 30
8.12 Automatic Login / Logout .............................................................................. 30
8.13 Maritime Safety Services .............................................................................. 31
8.14 LES TDM Frame Synchronisation ................................................................. 31

9 Summary ............................................................................... 31

10 Further Information ............................................................. 31


10.1 SDM - General Background .......................................................................... 32
10.2 SDM - Relevant Sections .............................................................................. 32
Appendix 1: Protocol Implementation ................................................................... 33
1 Description of Protocols ..................................................................................... 33

Volume 2: User Services, Part 2: Application Notes, Page: 3


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1.1 Data Reports .............................................................................................................................. 33

1.2 Polls............................................................................................................................................ 33

1.2.1 Types of Polls .......................................................................................................................... 33

1.2.2 Polling Commands .................................................................................................................. 33

2 Schedule of Operation ....................................................................................... 34


Figure A-1: Schedule Chart.............................................................................................................. 35

3 The DNID-LES pair ............................................................................................ 36


4 Download and Delete DNID Polls ...................................................................... 36
5 Download DNID (Update) Polls .......................................................................... 37
6 Single and Multiple DNID Operation ................................................................. 38
7 Sub-Addressing ................................................................................................. 38
8 Responses ......................................................................................................... 39
9 Acknowledgements ............................................................................................ 39
10 Sequence Numbers ......................................................................................... 40
11 Randomising Interval (Unreserved Data Reporting Only) ................................ 41
12 Permanent and Demand Assigned TDM Operation. ........................................ 41
13 Action on Distress Alerts, EGCs and Messaging. ............................................ 41
14 Poll Command Flowcharts ............................................................................... 42
Figure A-2: Flowchart for MES Action on Receipt of a DOWNLOAD DNID Poll ............................. 43

Figure A-3: Flowchart for MES Action on Receipt of a PROGRAM DNID Poll................................ 44

Figure A-4(i): Flowchart for MES Action on Receipt of an INITIATE DNID Poll .............................. 45

Figure A-4(ii): Flowchart for MES Action on Receipt of an INITIATE DNID Poll ............................. 46

Figure A-5: Flowchart for MES Action on Receipt of a STOP DNID Poll ........................................ 47

Figure A-6: Flowchart for MES Action on Receipt of a DELETE DNID Poll .................................... 48

Figure A-7: Flowchart for MES Action on Receipt of a SEND UNRESERVED Poll ........................ 49

Figure A-8: Sub-Flowchart for MES Handling of Sequence Numbers ............................................. 50

Volume 2: User Services, Part 2: Application Notes, Page: 4


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Glossary
A number of acronyms and terms are used in this document that are commonly used in association
with the Inmarsat-C System. A full glossary and definitions can be found in the System Definition
Manual, Release 2.0, Volume 1, Chapter 9.

ACK Acknowledgement

AOR Atlantic Ocean Region

AOR(E) Atlantic Ocean Region East

AOR(W) Atlantic Ocean Region West

ASCII American Standard Code for Information Interchange

BCD Binary Coded Decimal

CES Coast Earth Station (see LES)

DCE Data Circuit Terminating Equipment

DNID Data Closed Network Identity

DTE Data Terminal Equipment

EGC Enhanced Group Call

ENID EGC Closed Network Identity

GMDSS Global Maritime Distress and Safety System

GPS Global Positioning System

IA5 International Alphabet No.5 (CCITT)

ID Identity

INMARSAT International Maritime Satellite Organisation

IME Internally Mounted Equipment

IOR Indian Ocean Region

ISDN Integrated Services Digital Network

ISO-OSI International Organisation for Standardisation - Open Systems Interconnection

ITA2 International Telegraph Alphabet No.2 (CCITT)

LES Land Earth Station

LMES Land Mobile Earth Station

LPES Land Portable Earth Station

MES Mobile Earth Station

NCS Network Co-ordination Station

Volume 2: User Services, Part 2: Application Notes, Page: 5


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

POR Pacific Ocean Region

PSDN Packet Switched Data Network

PSTN Public Switched Telephone Network

PVT Performance Verification Test

ROM Read Only Memory

SCADA Supervisory Control and Data Acquisition

SDL Specification and Description Language (CCITT)

SDM System Definition Manual

SES Ship Earth Station (see MES)

TDM Time Division Multiplex (channel)

TDMA Time Division Multiple Access

UTC Co-ordinated Universal Time

1 Scope
This Application Note provides a general description of the Inmarsat-C Data Reporting and Polling
protocol and is primarily intended for application developers, service providers and manufacturers of
Inmarsat-C mobile equipment.

The complete definition of the polling and data reporting protocol and MES/LES requirements are in
Volumes 1, 3, 4 and 5 of the Inmarsat-C SDM. These volumes should be referred to as the true
version of the data reporting and polling protocol implementation.

The following subjects are addressed by this document:

- introduction, illustrating the operation of the protocol with an example application;

- the role of the MES, describing the breakdown of functions between DCE and DTE;

- the role of the LES;

- operation of the protocol;

- further details of the protocol (in Appendix 1).

There are a number of references and acronyms in this document drawn from the normal Inmarsat-C
messaging protocols. The Inmarsat-C SDM should be referred to for further information on these
subjects; references are indicated in this document within section 10, ‘Further Information’.

Store and forward messaging may be used in conjunction with the data reporting and polling protocols
(i.e. for closed network services and applications), particularly when high reliability data transfer is
required. Details of store and forward messaging may be found elsewhere in the Inmarsat-C SDM
and is not covered by this application note.

Volume 2: User Services, Part 2: Application Notes, Page: 6


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2 Introduction
Inmarsat-C is a satellite communications system that facilitates data transfer between Mobile Earth
Stations (MESs) and fixed Land Earth Stations (LESs) connected to terrestrial networks. Data can
also be transferred from Mobile to Mobile via an LES. Mobile Earth Stations can be located on ships,
vehicles, trains, aircraft, as fixed land based installations or they may be hand transportable units.

The Inmarsat-C system provides:

- Telex and data (text) store and forward communication in both directions

- Alerting from Mobiles

- Enhanced group calls to Mobiles

- Data reporting from Mobiles

- Polling to Mobiles.

Some of the services supported by the Inmarsat-C system are mandatory; other services are optional
as indicated in the following table.

MES MES
Service LES
(maritime) (land-based)
Store and forward messaging Mandatory Mandatory Mandatory

Distress alerting (maritime) Mandatory Mandatory Not allowed

Land mobile alerting Optional Not applicable Optional

Data reporting Optional Optional Optional

Polling Optional Optional Optional

EGC Mandatory Optional Optional

3 Data Reporting and Polling in Inmarsat-C

3.1 Description
The data reporting and polling services are totally different from any other Inmarsat-C service in that
Inmarsat has defined only the basic level of protocols needed to operate this service. It is left to the
MES manufacturers, LES operators and application developers to provide facilities that make use of
the protocols and to create end-to-end services and applications.

The data reporting and polling protocol operates on a basis of accessing closed networks set up
between terrestrial user, MES user, and LES operator. It is envisaged that once application services
have been provided, the data reporting and polling protocol will be transparent to the user, i.e. it will
be the transport mechanism between MES and LES.

3.2 Data Reporting


The data reporting service is intended for transferring small quantities of data from an MES to a pre-
determined terrestrial user.

Volume 2: User Services, Part 2: Application Notes, Page: 7


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Data reports are sent from the MES to the LES, (or NCS when the LES is in demand assigned mode),
on the signalling channel. One advantage of using the signalling channel is that the transmission time
of a data report is short because a call does not have to be set up before report transmission.

Data reports are transmitted using unreserved or pre-assigned access; both access methods are
described in this section.

The LES that receives the data report (i.e. the LES that has the local agreement with the terrestrial
user) routes the data report to the terrestrial user or stores the report in a file for later retieval by the
terrestrila user.

3.2.1 Addressing

A short form of addressing is employed called "closed network addressing". A Data Reporting and
Polling Closed Network IDentity (DNID) is allocated to the MESs that will be reporting to a particular
terrestrial user. DNID management, such as downloading and deleting of DNIDs at the MES is
carried out by use of the polling protocol.

Each time the MES sends a data report, it addresses a closed network that it is a member of (MESs
may belong to more than one closed network) using the DNID as the destination address.

As the terrestrial user has to set up a local arrangement with an LES in order to configure a closed
network, the MES should only send data reports to that LES (other LESs will not know the destination
of the data report from the DNID). For this reason, the MES refers to a closed network by a DNID-LES
pair, as shown in Figure. 2. See Appendix 1, section A3 for further information on the DNID-LES pair.
A particular DNID may not therefore be unique within the system, though it will be unique to a
particular LES.

Volume 2: User Services, Part 2: Application Notes, Page: 8


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: Inmarsat-C channels Used for the Data Reporting and Polling Protocol

POLLING COMMANDS
USE NCS COMMON
CHANNEL (TDM) MES

NCS

a) Polls transmitted to MES on NCS common channel (TDM)

DATA REPORTS
USE LES SIGNALLING
CHANNEL MES
(UNRESERVED ACCESS)

LES

b) Unreserved data reports transmitted by MES to LES


on LES signalling channel

DATA REPORTS
USE LES SIGNALLING
CHANNEL MES
(RESERVED ACCESS)
LES

c) Reserved (pre-assigned) data reports transmitted


by MES to NCS on NCS signalling channel

Volume 2: User Services, Part 2: Application Notes, Page: 9


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.2.2 Data transfer


The MES accesses the LES signalling channel to transfer the data report to the LES. (See Figure 1
for the types of channels employed). The contents and format of each data report will depend on the
device attached to the DCE part of the MES and the service being implemented. The data reporting
protocol does not address this issue and the DCE is simply seen as packing the data provided by an
attached device (DTE) into the data field.

If the destination LES is operating with a demand assigned TDM, the data report packets will be
transmitted to the NCS. The NCS will route each data report to the destination LES.

3.2.2.1 Data transfer using unreserved access

Unreserved data reports of up to 32 bytes may be transmitted from the MES to the LES on the LES
signalling channel at regular intervals. The polling protocol can be used to program when to start data
reporting and how often data reports should be sent.

3.2.2.2 Data transfer using pre-assigned (reserved) access

Pre-assigned (also called reserved) data reporting is used with large groups of mobiles needing to
transmit up to 44 bytes of data per report on a pre-defined basis. Slots in the LES signalling channel
are reserved specifically so that the MES has unique access to send a data report. As in unreserved
access, in most cases a poll will be used to program the MES with the slots that it should use, when it
should start and how often data reports should be sent.

3.3 Polling
The polling service allows a user to transfer small quantities of data (up to 256 bytes) to an MES or
group of MESs. In this way the user may initiate some action by an MES or a group of MESs using a
telecommand protocol. This action could be a transfer of data by the MES to the terrestrial user or for
the MES to initiate some action, such as turning on a pump for example. Data transfer may be
undertaken using data reporting, the pre-assigned data reporting service or normal from-mobile
message transfer.

Polling requests sent to MESs may contain text or data prepared by the terrestrial user. This allows,
for example, a group call facility with acknowledgement to be implemented.

3.3.1 Addressing
Closed network addressing uses a DNID-LES ID pair allocated to MESs that are to respond to a poll
from a terrestrial user. In addition, a sub-address is provided to allow activation of a specific device
attached to an MES or controlled by an application.

There are a number of poll commands defined to control the operation of the MES. It is possible for
the MES manufacturer or applications developer to define additional poll commands for particular
applications.

Polls are sent to the MES on the NCS TDM channel because the MES monitors this channel while
idle. Terrestrial users wishing to send polls (as part of their application package) do so through their
local LES who forward the poll packet to the NCS for transmission. See Figure. 1 for the types of
channels employed.

The MES should only accept polls addressed to a DNID-LES ID pair that it holds if it has previously
received a download DNID poll from the same LES. This requirement for checking the DNID-LES pair
is in place to prevent unauthorised access to a MES.

For this reason the MES should only act on polls having the correct DNID and LES ID, see Figure. 2.
Every poll received should be checked for DNID-LES pair validity. Appendix 1, section A3 describes
the DNID-LES pair in further detail.

Volume 2: User Services, Part 2: Application Notes, Page: 10


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.3.2 Polling
Three types of polling are supported:

(a) 'individually directed' for polling on an MES by MES basis;

(b) 'group directed' for polling a group of MESs with the same closed network identity (DNID-LES
pair); and

(c) 'area directed' polling of a set of MESs with the same data reporting and polling closed network
identity within a given geographical area.

Because of the broadcast nature of a poll not all MESs being polled may receive the transmission (for
example due to blockage of the signal by buildings, trees, etc). Means are provided by the LES to
repeat a particular poll.

3.3.2.1 Individually Directed Polling

Individually directed polling refers to the process of sending an explicit polling command to one MES.
A poll command from a terrestrial user can contain a number of individually directed poll commands.

The MESs and the polling command originator will be pre-registered at the LES. After the terrestrial
circuit is connected, the end user enters a list of MES identities to which he wishes the individually
directed polling commands to be sent. If necessary, the LES establishes a polling output file to which
the polling responses are written. For each MES in the user's list, an individual poll is sent via the
NCS.

Each MES receiving an individual poll may respond using either the data reporting protocol or a From-
Mobile message transfer depending on the contents of the command and response fields. The data
report is placed in the polling output file at the LES. If message transfer is used, the destination
address may either be the data network identity given in the individual poll or a terrestrial end user
address. In the first case, the message is placed in the polling output file.

3.3.2.2 Group Directed Polling

Whereas with individually directed polling a poll command is sent to each individual MES, with group
directed polling a single poll command is broadcast on the NCS common channel. MESs will only
respond if they are idle, receive the poll command and are part of the group defined by the data
network identity.

Upon receipt of the group poll, addressed MESs may initiate a response to the originating LES
depending on the contents of the response field. A randomising interval is also given in the group poll
packet that gives the number of frames over which the MES must randomise its response. This
parameter is provided to prevent overload of the random access system by the polling response from
a large group. For each MES the manner of responding follows that given for individually directed
polling.

3.3.2.3 Area Directed Polling

Area directed polling is functionally the same as group directed polling with the exception that only
those MESs with the same data network identity and lying within a defined area are addressed. A
geographical address is included in the area poll as is the data network identity.

4 Example Application - Position Reporting Service


The Position Reporting Service provides a means of determining the location of a mobile terminal and
a method by which the information is relayed back to a base station. In addition, by using the polling

Volume 2: User Services, Part 2: Application Notes, Page: 11


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

protocol, the base station can request that the mobile transmits selected information. A brief example
of a typical application is given here to clarify the configurations of MESs with LESs and using the
DNID as a means of addressing polls to an MES. The application operates across the Inmarsat-C link
between, for example, a central office based computer and the mobiles in the group. The service also
provides the capability for coded and plain text transmission and a range of sensor inputs such as
temperature and pressure for example. The position of an MES can be determined by means of an
on-board navigational system such as GPS, GLONASS, Loran-C, Omega, etc.

Interconnection on the terrestrial side to LESs will usually be via X.25 (data network) or PSTN
(telephone network). The data reports can be stored by the LES for subsequent retrieval by the base
station (for example a shipping or freight company head office) or the reports can be forwarded
automatically depending on local facilities and arrangements between the LES operator and fleet
operator.

The service is suitable for both land mobile and maritime users and either unreserved or reserved
(pre-assigned) data reporting can be used.

Full details of packet contents are provided for system designers in Application Note 2.

In a possible scenario, a trucking operator would require regular reports to be sent from his fleet of
trucks to his head office. The reports could consist of information such as vehicle information or status
of the transported load.

In Figure 2 below, the truck operator owns a fleet of four trucks that he identifies (as a group) by DNID
1. He has an arrangement with LES X that enables him to poll all his fleet from his head office.

Trucks within his fleet may also belong to other groups and be polled by whoever has made a suitable
arrangement with the respective LES.

Note that DNID 1 is duplicated by both LESs X and Y because both LESs offer individual services to
separate users. Thus, for security reasons, the trucks only respond to the poll identified by both the
DNID AND the LES ID.

Volume 2: User Services, Part 2: Application Notes, Page: 12


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 2: Grouping of DNID-LES Pairs (Note that DNIDs are Reused by LESs)

DNID 2, LESX DNID 1, LES X DNID 1, LES Y

LES X
DNID 1
MEMBER 1 LES Y
LES X DNID 1
DNID 1 MEMBER 1
MEMBER 2

LES Y
DNID 1
MEMBER 3
LES Y
DNID 1
MEMBER 2

LES X LES Y

Terrestrial
Network
e.g. PSTN,
PSDN, x.400,
etc.

Terrestrial Users
e.g. in office.

Volume 2: User Services, Part 2: Application Notes, Page: 13


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

5 role of the mes in Data Reporting and polling

5.1 MES Configurations


The general model of an MES has a DCE that, on one side implements the satellite side protocols to
communicate with the LES, and on the other side has a number of addressable ports to communicate
with devices attached to the DCE. Each port is allocated a sub-address with sub-address zero being
reserved for the normal messaging DTE. A port in this context could be a separate physical
connection or a logical connection where, say, a PC is managing several sub-addresses (e.g. the PC
could be managing a number of separate devices). The DCE maintains a table that associates the
various parameters required to undertake data reporting.

The aim of the design of the data reporting and polling protocol has been to provide the basic protocol
mechanisms to operate a service. Likewise, Inmarsat has attempted to make the operation of the
DCE effectively as transparent as possible; in other words the DCE should appear as little more than
a modem. Figure. 3 indicates how the data reporting and polling protocol fits into the ISO-OSI model.

Figure 3: Inmarsat-C Data Reporting and Polling Protocol Hierarchy

Application Application

Presentation Not used Not used


Presentation

Session Not used Not used


Session
Data Reports/ Messages
Not used Not used
Transport Transport

Data Reporting/ Data Reporting/


Network Polling Polls Data Reporting/
Network Polling
Polling
Polls
Inm-C Inm-C Inm-C
Link Link
Signalling Signalling Signalling

Inm-C Inm-C Inm-C


Physical Physical
Physical Physical Physical

Terrestrial Terrestrial Satellite NCS DCE DTE


User
LES MES

However, the DCE is not completely transparent and some functions are necessary to provide
security and network integrity.

Polls to a MES are routed to a sub-address where the interface to control an operation is connected.
Sub-addresses may be physical ports or logical (application) addresses.

Two configurations of MES are envisaged:

- Configuration I - DCE with physical sub-address ports;

- Configuration II - DCE with only one physical port (logical sub-addressing).

DCEs may also be a combination of these two configurations.

These configurations are illustrated below in Figures 4.

Volume 2: User Services, Part 2: Application Notes, Page: 14


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 4: MES DCE Configurations

DCE Interface to Satellite


DNID LES ID Subaddress Member No.

Interface ports to DTEs with Sub-addresses


0 1 2 3 4 5

DTE

Configuration I MES

DCE
Interface to Satellite
DNID LES ID Member No.

DTE-DCE Interface (default sub-address 0)


0
To attached
devices
DTE

Configuration II MES

Volume 2: User Services, Part 2: Application Notes, Page: 15


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

5.2 Functions of the DCE


For data reporting and polling, the principal functions of the DCE are:

- to manage DNIDs,

- send acknowledgements to polls (should they be requested),

- send the correct response type,

- ensure that all data reports, including acknowledgements are randomised.

5.3 Functions of the DTE


In general the DNIDs stored should only be accessible for downloading and deleting via the RF path,
however the DNID and other parameters may be pre-programmed or deleted, at a user's request, by
arrangement with the MES manufacturer.

It should be possible for the MES operator to de-activate (or activate as required), via the DTE,
selected DNIDs previously downloaded.

Following an initial download the DNID and the "free" field should be printed and/or displayed.

6 LES Role in Data Reporting / Polling


6.1 TDM Frequency and Randomising interval

The LES must choose a TDM frequency and randomising interval to include as parameters in group
and area polls. It does this by taking into account the planned and current usage of the permanent
TDM groups that it is using. The randomising interval must be chosen taking into account the
expected size of the group and the need to avoid collisions. The settings of these parameters are an
operational matter for each LES. Note however that if the LES has no permanent TDMs, i.e. is
operating in demand assigned mode, the TDM frequency field must be set to hexadecimal FFFF.

6.2 Confirmations
When a positive confirmation is requested for a from-mobile call addressed to a DNID, the
confirmation should be sent when the message is written to the mailbox. If for any reason writing to
the mailbox is not possible, a non-delivery notification with the appropriate failure code should be
sent.

6.3 Member Number


When a message is sent to a DNID, no member number is available to the LES. The return ID (and
hence the Inmarsat Mobile Number) is available. If necessary the LES can obtain the member number
from this return ID, for example by using a look-up table.
If the terrestrial subscriber needs to know the member number, the MES may include it in the
message.

6.4 Billing and Call Records


LESs maintain call records for the purpose of billing.

6.5 Use of the Polling Protocol


Polling commands are used for the following purposes in the position reporting service:

Volume 2: User Services, Part 2: Application Notes, Page: 16


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

- To initiate data reports from one or several MESs;

- To send a text or data message to MESs;

- To program MESs with the parameters used for the reserved data reporting protocol.

6.6 Delivery of Data Reports by the LES


Incoming data reports for delivery to the terrestrial user may be prepared by the addition of a header.
Data reports that consist of more than one packet are first concatenated to form a single item. The
means of delivery of the file of data reports so created is a matter for the individual LES, but might, for
example, be supplied on demand, either singly or in batches.

If the Telex network is used for access, translation from binary code to ITA2 can be performed by
means of a hexadecimal procedure, e.g. 01101010 binary can be split into two 4-bit nibbles of 0110
and 1010. In hex these are 6 and A respectively. The 6 and the A can then be transmitted on the telex
network as ITA2 characters.

If a fleet requires service to be provided by one or more LESs, for example for restoration purposes,
DNIDS can be allocated by each LES. Note that LESs ignore data reports addressed to DNIDs not
registered with them.

7 Operation
Closed networks can be set up by individual LESs. Each terrestrial user can own one or several
unique Data Network Identities (DNIDs) with which he can configure MESs into closed user groups.
Note that each DNID is only unique to one LES, it may be duplicated by other LESs. The actual
configuration of MESs into closed networks is carried out by the individual LES, with whom the
terrestrial user will have a local arrangement for operation of the service.

The protocol is thus a means of both controlling MESs and sending data from MESs. Polls are used to
control and send data to MESs; data reports are used to send data from MESs. Store and forward
messaging may also be used to send data from an MES in response to a poll. Messaging is most
appropriate when the volume of data is large (say, more than ~100 bytes), and/or high reliability of
data transfer are required.

There are two methods of sending data reports, one on the basis of unreserved access (i.e. using the
Inmarsat-C slotted Aloha access scheme), the other on the basis of pre-assigned, or reserved,
access. These methods are treated separately in this document.

7.1 Poll Commands


As a minimum the DCE must support the download and delete individual poll commands, codes 0AH
and 0BH. The command type 00H must also be supported though this may be implemented as either
a DCE or a DTE function. The remaining commands are optional and may be supported by the DTE.
Note that command types 01H, 02H and 03H must be handled by the DCE if pre-assigned data
reporting is implemented.

7.2 Utilisation of poll fields, DTE & DCE


As mentioned in section 5, Inmarsat has attempted to make the operation of the DCE as transparent
as possible, i.e. so that most of the poll packet contents are passed to the application and also so that
the application passes to the DCE most of the contents of the data report.

The diagrams in figure 5 (a) and (b) show how the contents of poll packets are treated. Those fields
that are trapped by the DCE are used for network integrity and security purposes. The fields that are
passed to the DTE are processed by the application.

Volume 2: User Services, Part 2: Application Notes, Page: 17


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The treatment of some fields depends on whether the addressed port is a configuration I or
configuration II DCE (see section 5).

Figure 5(a): Utilisation of Poll Fields

C DNID C DNID
A SES FWD ID
A CES ID A CES ID
A CES ID A CES TDM A CES TDM
B SUB-ADDRESS
B SUB-ADDRESS B SUB-ADDRESS
C DNID
A RANDOMISING INTERVAL A RANDOMISING INTERVAL
B RESP SPARE D B RESP TYPE LENGTH D B RESP SPARE D
E AK COMMAND E E AK COMMAND E
B SEQUENCE AREA B SEQUENCE
C

B
TEXT / DATA B TEXT / DATA
E AK COMMAND E
B SEQUENCE

B TEXT / DATA
Individual Poll Group Poll

Area Poll

A
Fields trapped and used by DCE. Need not be
passed to DTE.

Passed to DTE, unused by DCE.


B
(see note 1).

C Address fields checked by DCE, passed to


DTE if valid. (see note 2).

D Not defined/used.

E Inspected by DCE but also passed to DTE.

Note 1. May be used for routing to appropriate port if configuration I DCE.

Note 2. Only polls for valid DNID/LES pairs may be accepted. Area validity
checking may be performed either by DCE or DTE.

Volume 2: User Services, Part 2: Application Notes, Page: 18


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 5(b): Utilisation of Poll Fields (Download DNID or Delete DNID)

A SES FWD ID

A CES ID
B SUB-ADDRESS
C DNID
B RESP SPARE D
E AK COMMAND E
B SEQUENCE

B TEXT / DATA

Individual poll
(download or delete)

A Fields trapped and used by DCE. Not passed


to DTE.

B Passed to DTE, unused by DCE.

C Fields used by DCE, may be passed to DTE.

D Not defined/used.

E Inspected by DCE but also passed to DTE.

Volume 2: User Services, Part 2: Application Notes, Page: 19


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

For data reporting and polling, the principal functions of the DCE are to:

- manage DNIDs (by associating DNIDs with LESs and member numbers);

- send acknowledgements to polls (if requested);

- randomise (if required) all data reports and acknowledgements;

- transmit data reports (for pre-assigned data reporting the data report has to be sent in correct
frame).

7.3 Permitted Commands by Poll Type


The MES should accept and respond to the following commands even if they are received in an
individual poll:

- Initiate reserved data reporting,

- Program unreserved data reporting,

- Initiate unreserved data reporting.

The table in Appendix A, gives the usual poll type for each command. Note that poll types 01H and
0AH must be individual polls and cannot be group or area polls.

7.4 Acceptance of Polls


A group/area poll should only be accepted for a valid DNID and LES ID (one previously downloaded).
Individual polls may only be accepted if the MES forward ID is valid and the DNID and LES ID are
also valid, except in the case of a download since they may not previously have been stored.

If for any reason the MES does not have a valid channel number for the LES, or if the LES is
operating demand assigned mode, the poll acknowledgement or response may be sent via the NCS.
Note, however, that, if the response should be a message transfer and the LES is not operating
demand assigned mode, the MES will be unable to respond to the poll unless it has a valid TDM
number for the LES.

The LES TDM field in the poll will take precedence over that contained in the network information. A
discrepancy between the response and the command is a matter for the DTE/application.

7.5 Parameter Checking


The DCE need only check the following parameters in a poll: DNID, LES ID, LES TDM, sub-address
(if applicable), randomising interval, command (including acknowledgement), sequence number.

If the DCE detects an inconsistency in these parameters (e.g. incorrect LES ID or LES TDM value out
of range) then it should ignore the poll, except for acknowledging if requested. Further checks for
consistency may be made by the DTE.

The main inconsistencies likely to concern the DCE concern the LES TDM and the randomising
interval. The TDM channel number used will be that sent in the latest relevant poll (that is, the
information contained in the initiating poll).

In the case of a poll received with a TDM channel number different from that stored in the network
configuration, the MES uses the TDM channel number supplied in the poll for the response regardless
of whether the response required is a data report or a message transfer. This TDM channel is also be
used for the poll acknowledgement, should one be requested.

Volume 2: User Services, Part 2: Application Notes, Page: 20


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Any discrepancy between the response and the command is a matter for the DTE/application.

In an area poll, the area parameters should be checked by the DCE, since in most cases they have
navigational inputs. The DCE should therefore only pass the poll to the DTE if the address (including
DNID) are valid (i.e. the MES actually lies within the addressed area). For MES implementations not
having navigational instrument inputs it is permissible for the area address to be passed to the DTE
for checking.

7.6 Unexpected Command


If an initiate or stop poll is received when no program is stored, the poll should be acknowledged, if
requested, but no other action should be taken by the MES.

If an MES receives a stop unreserved data reporting poll, when not doing programmed unreserved
data reporting, or an MES receives a stop reserved data reporting poll, when not doing programmed
reserved data reporting, the poll should be acknowledged, if requested. No other action should be
taken by the MES.

7.7 Response to a Poll


The poll response may be originated by the DTE and may take the form of a data report or message
transfer to the DNID (via the LES associated with the DNID) and may be determined by the setting of
the response field in the Poll.

However, the type of response depends on the application and the configuration of the DCE and may
not be as indicated in the response field. If the MES employs a Configuration II DCE, then the DTE
application is responsible for defining the type of response to be made to a poll.

If the response required is a Store and Forward message, the MES should still use the TDM channel
number given in the poll.

7.8 Acknowledgements
When the acknowledgement bit is set in a poll, the acknowledgement is always originated by the
DCE.

The acknowledgement data report is intended to convey to the poll originator that a poll has been
successfully received by an MES. It does not necessarily mean that the MES (application) is able to
process or send the required response to the poll.

If an MES (DCE) receives a second poll with the same sequence number and LES ID as one already
received, it should acknowledge this poll, if an acknowledgement has been requested and the poll is
an individual poll. The acknowledgement should also be resent, regardless of poll type, if it was not
previously successfully transmitted.

All group and area polls with new sequence numbers and recognised DNID-LES ID pairs are
acknowledged, if requested in the poll packet, even if the poll makes no change to the MES state.

All individual polls with any sequence number and recognised MES ID/DNID/LES ID are
acknowledged, if requested, regardless of whether the poll has been received before with the same
sequence number, or even if the command cannot be handled (e.g. Download DNID command, when
the MES is unable to accept further downloads).

A "Download" poll command for a particular MES is acknowledged, if requested, even if the DNID-
LES ID pair has previously been downloaded.

A "Delete" poll command for a particular MES is acknowledged, if requested, even if the DNID-LES ID
pair has already been deleted or is not recognised.

Volume 2: User Services, Part 2: Application Notes, Page: 21


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Group and area polls with a repeated sequence number are not necessarily acknowledged, in
accordance with the rules given in section 7.9.

The member number field in the poll acknowledgement is set to zero in the following cases:

1) On receiving an individual DNID delete poll for a DNID not previously downloaded;

2) On receiving an individual download poll when the MES memory is full;

3) On receiving an individual poll conveying a data transfer with a DNID not previously
downloaded;

4) On receiving any poll addressed to a disabled DNID.

7.9 Repeated Polls


On successful receipt of a poll, the sequence number is stored with the DNID, LES ID and poll type.

The sequence number (0 - 255) is normally incremented modulo 256. It is used by the MES to detect
duplicate polls, which are to be ignored. It is also used as a reference, when poll acknowledgements
are required. The MES should retain a record of all sequence numbers received for a maximum of
24 hours or until a sequence number is received which is at least 128 greater (modulo 256) in which
case repeat polls with the same sequence number may be ignored.

The DCE need not pass a duplicate poll to the DTE if it has already passed the original poll to it. It is
not necessary for the sequence number to be passed to the DTE, but it is not excluded.

When a poll is transmitted by an LES, that poll (with the same sequence number, DNID and LES ID)
may be repeated within 24 hours or before the sequence numbers have been incremented by 128.
The MES must, therefore, be able to store 256 sequence numbers for each DNID/LES ID pair
downloaded and active for up to 24 hours. Alternative strategies could be employed to conserve
memory (for example, a bit map of 128 bits).

7.9.1 Example Strategy for Poll Sequence Numbers


One method of detecting repeated polls is outlined below.

The MES should store the following:

- The "current" (last valid received) sequence number

- The date and time that the poll with the above sequence number was received

- 256 flags, two flags for each of the last 128 sequence numbers from (current sequence number
- 127) to current sequence number

One flag indicates whether a poll has been received for the particular sequence number and the other
flag indicates (in the case when a poll was received for the sequence number) whether an
acknowledgement data report was successfully sent (if one was requested).

N.B. There is no requirement to store any of the above in non-volatile memory. The 128 x 2 bit flags
require 32 bytes of RAM. In addition the date and time of the last poll received needs to be stored.
The time could be stored as the frame number in which the poll was received.

On receipt of a valid poll addressed to the MES:

The sequence number arithmetic is modulo 256 so that the test

Volume 2: User Services, Part 2: Application Notes, Page: 22


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(new sequence number - "current" sequence number) mod 256 is in range (1..127)

determines whether the received sequence number is ahead of the currently stored sequence
number. Polls with sequence numbers that are ahead of the stored sequence number are to be
accepted as new polls, while polls with sequence numbers that are not ahead are checked to see if a
poll with the same sequence number has been already received.

See the flow chart in Figure 6.

7.10 Randomisation
The DCE must randomise a response regardless of any delay between the DCE passing the poll to
the DTE and the DTE returning a response to the DCE. Frame randomisation must always be
performed.

In general, it is important to minimise the time that an MES is tuned away from the NCS common
channel. When an MES is randomising its response or acknowledgement to a poll, it should remain
tuned to the NCS TDM until the randomised backoff n (n frames where 1 ≤ n ≤ X and X is the
randomising interval) has occurred. If during the interval a higher priority activity starts (e.g. reception
of an EGC message) the MES may hold the backoff count until this activity has been completed and
only then resume the backoff count and data reporting.

When an MES is randomising its response to a poll, it should accept new traffic received on the NCS
common channel. If an EGC message (for a Class 2 MES) or a store and forward message is
received during this time the counting down of the randomising interval should be stopped until the
message has been received and should then continue.

An MES already engaged in unreserved data reporting should use the new randomising interval and
response indication given in a new initiate poll command.

The MES randomises each programmed data report so that the actual interval between any two
successive data reports is the programmed interval ± the randomising interval. The randomising
interval is taken from the Initiate command. The average interval will tend to converge toward the
programmed interval over a large number of reports.

7.11 Priority
Distress priority is not allowed for data reports or message transfers initiated in response to a poll.

7.12 Programmed Data Reporting


It is possible for an application to be set up so that data reporting is performed by a device connected
to one sub-address to more than one DNID, i.e. the device (sub-address) may be simultaneously in
more than one closed data network.

It is also possible for an MES implementation to use logical sub-addressing, i.e. only one physical
port, the main DTE. In this case the DTE could well be in more than one group at once.

In practice the most common arrangement is for a MES to be in a single closed network.

It is acceptable for an MES implementation to allow programmed data reporting on only one DNID-
LES ID pair at a time.

7.12.1 Unreserved Data Reporting


For programming unreserved data reporting, the program poll contains a start frame number, which
should be derived from the NCS, since it is the network timing reference. LESs supporting unreserved
data reporting do not have to ensure that their TDM frames are synchronised with UTC.

Volume 2: User Services, Part 2: Application Notes, Page: 23


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 6: Sub-Flowchart for MES Handling of Sequence Numbers

New valid Individual/Group/Area Poll


received

START

yes stored
date & time
> 24 hrs old
?
no
Clear all flags,
update "current" PSN (new PSN no
and date and time. -current PSN)
<128?
yes

update "current" PSN


and date and time
no yes
PSN received
before?

Process
Poll
yes Individual
Poll?
Set poll received
flag no
for this PSN
no
Ack previously
sent OK?
Ack no yes
requested?

yes

Send
Acknowledgement

yes
Ack sent
OK?

no
Set Ack sent OK
flag

END

The MES action should therefore be as follows:

- wait on the NCS Common Channel until the occurrence of the next programmed transmission,

Volume 2: User Services, Part 2: Application Notes, Page: 24


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

- randomise while still tuned to the NCS Common Channel,

- tune to the LES for transmission of the data report (LES frame numbers may be ignored),

- re-tune to the NCS Common Channel.

7.12.2 Reserved Data Reporting


For programming reserved data reporting, the slot logical channel assignment refers to specific slots
in specific frames on specific channels.

The MES action should therefore be to obtain its frame reference from the NCS TDM. The LES TDM
to which the MES will be transmitting its data reports will maintain its frame numbers in
synchronisation with UTC, and therefore with the NCS.

7.13 Program Discontinuation


An MES stops sending programmed data reports in any of the following cases:

a) The program expires;

b) A Stop Data Reporting command is received;

c) A Program command is received;

d) The network enters restoration mode;

e) The DNID/LES ID pair is deleted.

Note that in case (a), if the MES is unable to access every interval when a data report should be
transmitted, it must nevertheless terminate data reporting after a number of frames equal to the
product of duration and interval, starting from the programmed start frame.

When an MES leaves an ocean region (logs out or logs into a new ocean region), it should stop any
data reporting activity for an LES ID associated with the former ocean region. If an MES returns to an
ocean region, it may restart pre-assigned data reporting, if the program parameters are still valid.
Programmed unreserved data reporting may restart provided that the time of the next scheduled
transmission can be determined.

7.14 Program Re-Starting


If a data reporting program is stopped and then re-started, the program remains unchanged. Any
reporting allocations that would have been used in the interval when stopped are lost. However they
are still counted as part of the duration, i.e. regardless of how often or for how long the program is
stopped the program ends at the same time.

As an example: if an assignment is given to transmit 20 data reports and is stopped after the 5th has
been sent and restarted just after the point where the 10th would have been sent, only 15 data reports
in assigned positions 1 - 5 and 11 - 20 would actually be sent. The program will still finish at the same
time, i.e. after the 20th assigned position, as if all 20 had been sent.

7.15 Program Deletion


An MES should delete a program relating to a DNID-LES ID pair when:

a) the DNID-LES ID pair is deleted;

b) the network enters restoration mode.

Volume 2: User Services, Part 2: Application Notes, Page: 25


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Any program may be overwritten by a replacement. An unreserved program poll may overwrite an
earlier pre-assigned program for a given DNID and vice versa.

7.16 Downloading of DNIDs


If the text field of a download command includes the service provider name (at most 25 characters), it
should be encoded in IA5 with odd parity. The coding of the rest of the text field is a matter for the
application. The service provider name need not be made available to the DTE.

In the event that a download command is received when the DNID storage area is full, any DNID
which has been de-activated by the MES operator may be overwritten. If none have been de-activated
then the new download should not be accepted.

MESs should accept the download DNID even if there are more or less characters than the specified
25 in the text field. If there are less than 25 the MES stores only those characters sent in the poll. If
there are more than 25 the MES need only store the first 25 characters.

7.17 Deletion of DNIDs


De-activation of a DNID causes all activity associated with that DNID-LES ID pair to be stopped.
DNIDs which have been de-activated by the MES operator can be deleted or overwritten. (They may
also be re-activated by the operator).

If the text field of a delete command includes the service provider name (at most 25 characters), it
should be encoded in IA5 with odd parity. The coding of the rest of the text field is a matter for the
application. The service provider name need not be made available to the DTE.

7.18 Loss of Power


If program data is lost (e.g. due to a power outage) the MES will be unable to send data reports until
reprogrammed and re-initialised. Program data may be stored in non-volatile memory to avoid this
problem, but this is not mandatory for the MES. The end to end application should provide
mechanisms for recovering MESs that have lost assignments.

7.18.1 Loss of Power - Unreserved Data Reporting


When performing programmed data reporting, and in the event of a power interruption or loss of TDM
synchronisation, the MES may only continue using unreserved data reporting (not pre-assigned) if it is
able to unambiguously determine the precise number of elapsed frames since the last scheduled
transmission attempt and hence when the next scheduled transmission should occur. The actual
action taken will depend on the MES implementation and the application.

7.18.2 Loss of Power - Pre-Assigned Data Reporting


When performing programmed data reporting, and in the event of a power interruption or loss of TDM
synchronisation, the MES may only continue using pre-assigned data reporting if the last frame for
data report transmission, calculated by: last frame = start frame + (interval * (duration-1)) , has not
been reached.

The MES should have some means for checking that the calculated last frame has not been passed
while the mobile was not synchronised to the TDM. If the last frame for data report transmission has
been passed, then the mobile should stop data reporting and wait for a poll indicating the action it
should take.

7.19 Spot Beam Operation

Volume 2: User Services, Part 2: Application Notes, Page: 26


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

When spot beam satellite operation is introduced or when NCS common channel capacity expansion
becomes necessary, information relating to the new NCS common channels will be made available to
users who will then be responsible for entering the new NCS IDs and channel numbers into their
MESs. The Inmarsat 3 satellites will support spot beam operation.

For MESs that are operated remotely, a useful feature is a facility for downloading new NCS IDs and
channel numbers to MESs using a poll command so that they can benefit from spot beam operation.

When an MES data reporting to a DNID, associated with an LES, logs in to another spot beam, the
MES will use the TDM associated with the LES in that spot beam (or NCS if demand assigned) for
sending its data reports. This TDM will take precedence over the TDM which may have previously
been assigned in a program command (while logged into another spot beam, for example). Any
subsequent polls received while in this spot beam may contain different TDMs which should then be
used for data reporting.

All programmed reserved (pre-assigned) data reporting should be cancelled, when logging into
another spot beam.

7.20 Multi-Threading
For the purpose of supporting data reporting and polling, MES implementations are assumed to be
single threading, i.e. only able to support one activity at a time. However multi-threading
implementations are acceptable.

For a basic single threading implementation, an MES may be unable to send a scheduled data report
(reserved or unreserved) at a specific time because it is involved in another activity.

7.21 Precedence of Activities


In the case of MESs that support data reporting and polling and other Inmarsat-C protocols, the
transmission or reception of messages (including EGCs and distress/LM alerts) with priority other
than routine pre-empts any current data reporting/polling activity.

7.22 Restoration Mode


If the network goes into restoration mode all programmed data reporting is terminated and the
programs deleted.

7.23 Parameters Stored in Non-Volatile Memory


The parameters stored in non-volatile memory are:

- DNID

- LES ID

- Member Number

- Service provider identifier (25 characters). This name is transmitted in the first 25 characters of
the "free" field in an initial download command

Provision for storing at least 64 16-bit DNIDs is recommended.

For pre-assigned data reporting, the following are also stored:

- Start Frame

- Slot Number

Volume 2: User Services, Part 2: Application Notes, Page: 27


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

- Logical Channel Number

- Number of Packets / report (1, 2, 3 or 4)

- Duration

- Signalling Channel

- LES TDM

- Interval

Only Start Frame and Interval are used by the DCE.

Programmed parameters for programmed unreserved data reporting may also be stored in non-
volatile memory.

Additional parameters may be stored in non-volatile memory so that the MES does not loose the data
reporting program after a power outage. Section 7.18 describes the actions that the MES should take
after a power outage.

7.24 Macro Encoded Messages


All Poll commands include a sub-address field and therefore it is possible to use the command Define
Macro Encoded Message to define codes to be used for short text messages on a DNID/sub-address
basis. Subsequently Macro Encoded Messages (MEMs) can be sent to specific DNID/sub-address
pairs in the direction base to terminal.

Once a Macro Encoded Message has been defined, it can be used in either the terrestrial to mobile or
the mobile to terrestrial direction. The polling protocol only defines its use for the former direction, but
its use in the reverse direction is not excluded and is used, for example, in the position reporting
service. Note that for the direction mobile to terrestrial the inclusion of a Macro Encoded Message
field in the data report is an application matter.

In the direction mobile to terrestrial, it would also be possible to include a sub-address field in the data
with the MEM, but this is not done in the position reporting service. Therefore for that application,
MEMs are common for all sub-addresses. Other applications could be defined in which the MEMs are
sub-address specific.

7.25 Pre-assigned Data Reporting


As in unreserved data reporting, a pre-assigned data report is sent on the LES, (or NCS in demand-
assigned mode), signalling channel but the LES reserves slots for the MES to send data reports in.

This method of data reporting is designed for large groups of MESs belonging to one DNID and
allows the channel to be used more efficiently.

8 Protocol Limitations
There are some limitations in the data reporting and polling protocols which need to be taken into
consideration when designing applications.

8.1 Data Report Collisions


In most cases, collisions between data reports originated by different MESs are detected by the MES
and the MES automatically re-sends the lost report. However, data reports from one MES may be lost

Volume 2: User Services, Part 2: Application Notes, Page: 28


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

due to simultaneous transmission from another MES having a higher C/N at the LES. In the case of
single packet data reports, the DNID file will show which MESs within the group have not sent
responses to the poll. In this case the application could then issue individual polls to those members
from which responses had not been received. However the situation is more complicated when:

i) An area poll is sent and the application does not know how many responses to expect and from
which members of the group.

ii) Multi-packet data reports are sent from some or all members of a group, and possibly
simultaneously from MESs belonging to other groups. In this case it is possible for the output
file to mistakenly contain data reports comprising packets from more than one MES.

A possible solution to the second problem is for multi-packet reports (data reports consisting of two or
more packets) to include an additional checksum in the last packet covering data from all the packets
comprising the data report. Unfortunately this will not work if the first packet is lost, since only that
packet contains the identification of the originator, although it will provide a means for identifying
corrupted reports. Secondly some capacity is consumed in an already limited resource. Nevertheless,
the application developer should be aware of this and some sort of checksum or other validation is
recommended for multi-packet data reports.

For example, a single checksum byte could be included as the last data byte in the last packet of the
data report. This byte could be the modulo-2 addition of all the data field bytes (in each of the packets
of the data report). No information would be conveyed in this byte, but it would allow the receiving end
(application) to identify a corrupted data report which could then be ignored and the MES perhaps
polled once more.

[data]::= [data][check byte(s)]

where check byte is the modulo-2 addition of all bytes, used and unused, in the data field (e.g. 8 bytes
including the category and sub-category fields for a single packet report, 20 bytes for a 2 packet
report, 32 bytes for a 3 packet report and 44 bytes for a 4 packet, pre-assigned data report) with the
last byte set to zero. The check byte replacing this last byte. The category and sub-category fields are
considered as part of the user data.

8.2 MES Identification


The MES return ID, used in store and forward messaging is not used in data reports or
acknowledgements. This can make it difficult to uniquely identify an MES responding to a poll. This
situation arises because the range of member numbers is limited (to 255) and there may be a need to
re-use numbers when group membership is changed or a number previously allocated to an MES that
is no longer a member of the group is required for a new member. It is therefore important that LES
operators should keep track of MES/DNID/member number allocations and history.

8.3 Conflict of Functions


An MES that supports both store and forward messaging and data reporting may appear to be
available to receive a message when in fact it is tuned away from the NCS Common Channel, in order
to send a data report to a LES. There is no mechanism to signal to the NCS that the MES is busy. It is
therefore important to limit the time tuned away from the Common Channel for such MESs.

8.4 TDM Selection


Individual polls do not include a LES TDM field. Responses are always made on a signalling channel
associated with the primary LES TDM (i.e. the TDM provided to the MES in the network configuration
information received at login or subsequently in a network update). It is not possible to redirect
responses to signalling channels associated with another TDM.

8.5 Barring of MES

Volume 2: User Services, Part 2: Application Notes, Page: 29


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Barring an MES does not prevent it from sending data reports. It may still operate as a member of a
closed data network. LES operators should be aware that barring an MES only prohibits it from using
the system for store and forward messaging. If necessary the operator may issue a poll to delete the
DNID at the MES.

8.6 Frequency of Data Reporting


There is no formal requirement to limit the number and frequency of data reports from a given MES.
However if an excessive volume of data reports are transmitted by one MES, the availability of the
signalling channels for traffic from other MESs will be restricted.

8.7 Global DNIDs


There are applications that are likely to require the use of global DNIDs, such as maritime AMVER
and JASREP. There is no provision for global DNIDs in the current definition of Inmarsat-C. Large
groups will have to use multiple DNIDs. LES operators should reserve DNIDs greater than 32767 for
global allocations and make arrangements between themselves for their management for this
purpose.

8.8 Member Number Limitations


There are system reasons for limiting the size of a closed data group to a maximum of 255 members.
Therefore to support large groups, service providers may need to assign more than one DNID for a
single application. LESs may also provide additional signalling channels to accommodate responses
to multiple simultaneous polls.

8.9 Management of Randomisation Interval


If a data report is being sent by an MES in response to a group/area poll, it must insure that the
response is randomised. Consequently it is necessary to allow sufficient time to receive all of the
expected responses to a poll, before, for example, repeating the poll, or otherwise regarding
responses as missing. The LES should not expect all responses to be received within the
randomisation interval immediately following the transmission of the poll.

Scheduling of individual polls for the purpose of downloading/deleting DNIDs should be managed by
the LES. The LES is also responsible for managing the randomising interval and therefore needs to
know the size of the group.

8.10 Common Terrestrial Interfacing


Different LESs currently provide different facilities and different terrestrial interfaces. This may make it
difficult for a service provider to offer closed network services through more than one LES.

8.11 DNID Management


For Configuration I MESs it may be necessary to download/delete a DNID-LES ID pair for each sub-
address used.

8.12 Automatic Login / Logout


Automatic Log-in/Log-out is acceptable for MESs that are used for public store and forward
messaging. However MESs that are used exclusively as part of a closed data group should not be
equipped to perform automatic logouts. A suitably coded single packet data report may be used to
indicate the availability or non-availability of the MES within the closed network at the application
level.

Volume 2: User Services, Part 2: Application Notes, Page: 30


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Problems can occur when an automatic (e.g. SCADA) MES wakes up, logs in and then immediately
tries to send a message. The call is cleared if the LES database is not updated before it receives the
assignment request. It is recommended that the MES should be programmed to wait for a short period
(in general 5 minutes should be sufficient) following a successful log-in before attempting to send a
message.

8.13 Maritime Safety Services


The minimum interval between data reports of 100 frames for unreserved and reserved data reporting
is considered to be an acceptable limit for MESs intending to meet GMDSS requirements, which
support other services for which time tuned to the NCS Common Channel is a consideration. In some
applications 100 frames may be an unacceptable restriction, however it is essential that MESs are
tuned to the NCS Common Channel for at least some of the time. For shipboard installations intended
to meet the GMDSS requirements, a separate MES should be used if much data reporting is to be
performed.

8.14 LES TDM Frame Synchronisation


The SDM states that the LES TDM must synchronise its frame numbers with UTC.

It is not a requirement for an MES to check the synchronisation of the LES frame numbers with the
NCS frame numbers, but if, when tuning to a LES TDM to transmit a pre-assigned data report, an
MES finds that the expected frame number has passed as may be the case under certain
circumstances (e.g. if prolonged channel blockage occurred during the retuning operation), it must
abandon sending the report. The LES should attempt to ensure that the desired start frame has not
passed, before the MES receives the programming and the assignment is initiated.

9 Summary
The Inmarsat-C data reporting and polling service is different from other Inmarsat-C services in that:

(i) unlike other services, the data reporting and polling protocol can only be operated on a closed
network basis;

(ii) there is no single set of "rules" (e.g. SDL) for terrestrial network to mobile network access.
Access will be different depending upon the services provided by the (terrestrial) LES and the
(mobile) MES model;

(iii) the users' perception of the service is dependant on the application and application software;

(iv) the protocols are capable of allowing services to be operated to MESs that are unmanned
(remote operation) but the development of applications and the provision of services that are
resilient and stable in the absence of a human operator poses a considerable challenge.

The aim of Inmarsat as a service provider has been to provide the basic protocol mechanisms for
operating the service and for MES manufacturers, service providers and application developers to
actually provide the facilities making use of the protocols. The operation of the DCE has been made
as transparent as possible, in other words appearing as little more than a modem. However, the DCE
is not completely transparent and some DCE functions are needed to provide security and network
integrity.

10 Further Information
The following documents relating to Inmarsat-C data reporting and polling protocol are all available
from Inmarsat (address on front cover).

Volume 2: User Services, Part 2: Application Notes, Page: 31


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

10.1 SDM - General Background


For a general background describing the Inmarsat-C protocols, SDM Volume 1 gives a complete
system description (chapter 1) and overview (chapter 2).

10.2 SDM - Relevant Sections


The following sections of the Inmarsat-C SDM completely define the operation of the data reporting
and polling protocol. Inmarsat-C SDM Release 2.0 refers.

- Volume 1:

Chapter 5, ‘Protocol for Data Reporting Service’

Chapter 6, ‘Protocol for Polling Service’

Chapter 7, ‘Protocol for Pre-assigned Data Reporting Service’

- Volume 2, Part 1:

Chapter 10, 'Data Reporting and Polling Service'

Volume 3, Part 1, ‘Land Earth Station’:

Chapter 10, ‘Addressing of Polling’

- Volume 3, Part 2, ‘Mobile Earth Station Requirements’:

Chapter 2, ‘Technical Requirements for a Mobile Earth Station’

Chapter 3, 'Optional Capabilities for an Inmarsat-C Mobile Earth Station'

Chapter 4, ‘DTE-DCE Interface Control Codes'

- Volume 4:

Chapter 8, ‘Packet Formats for the Data Reporting Service’

Chapter 9, ‘Packet Formats for the Polling Service’

Chapter 10, ‘Packet Formats for the Pre-Assigned Data Reporting Service’

Volume 2: User Services, Part 2: Application Notes, Page: 32


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Appendix 1: Protocol Implementation

1 Description of Protocols
A full description of the protocols can be found in Volume 1 of the Inmarsat-C SDM. This Appendix
provides a condensed summary of data reports and poll commands. Descriptions of packet contents
and the purposes of each field are contained in Volume 4 of the Inmarsat-C SDM.

1.1 Data Reports

Data reports are a means of quickly sending a small amount of data to the terrestrial user. Since a
data report may only be a maximum of three packets long, the data field may be formatted by the
application into fields having specific purposes. For example, the Inmarsat recommended position
reporting service (see Application Note 2) breaks down the text field into fields for latitude, longitude,
etc.

The MES sends data reports after receiving one of the data transfer polls:

- Send unreserved report (00H);

- Initiate reserved data reporting (02H);

- Initiate unreserved data reporting (05H).

Normally, the MES would be previously programmed, by use of the program polls (01H, 05H), as to
exactly when data reports should be sent.

If the MES is data reporting to an LES associated with one NCS and subsequently tunes or logs in to
another NCS then the MES should cease data reports until the MES tunes back to the original NCS.
Normal data reporting and polling functions would be allowed with the new NCS.

If the LES is operating in demand-assigned mode, then the MES sends data reports to the LES via
the NCS on an NCS signalling channel.

For unreserved data reporting, polls are sent to the MES on the NCS Common Channel because the
MES in an ocean region is permanently tuned to this channel whilst it is idle. Terrestrial users wishing
to send polls (as part of their application) do so through their local LES who forward the poll packet to
the NCS for transmission.

1.2 Polls

1.2.1 Types of Polls

Polls can be directed to MESs using one of the following methods:

(i) individually directed, for polling to individual MESs;

(ii) group directed, for polling to MESs with a particular DNID (see section A3), or

(iii) area directed, for polling to MESs with a particular DNID and in a given area (see section A3).

These methods of polling are described in the Volume 1, Chapter 6.

1.2.2 Polling Commands

The command field is an important part of the poll. The basic Inmarsat defined commands are shown
in the following table.

Volume 2: User Services, Part 2: Application Notes, Page: 33


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Command Type Meaning Poll Type

00H Send Unreserved Report as required in [Response] Any

01H Program Reserved Data Reporting Individual

02H Initiate Reserved Data Reporting Any

03H Stop Reserved Data Reporting Any

04H Program Unreserved Data Reporting Any

05H Initiate Unreserved Data Reporting Any

06H Stop Unreserved Data Reporting Any

07H Define Macro Encoded Message* Any

08H Macro Encoded Message* Any

09H Data Transmission Any

0AH Download DNID Individual

0BH Delete DNID Individual/Group

0C-3FH Reserved

40-7FH User Defined Any

The MES does not have to be able to process all the above commands. As a minimum, it would have
to be able to support the commands: Send Unreserved Report (00H); Download DNID (0AH); and
Delete DNID (0BH). This means that it would be able to:

(i) Be configured as part of a closed network by use of the Download DNID (0AH) command;

(ii) Send a single data report whenever it receives a Send Unreserved Report (00H) command (or,
indeed, a message instead of a report). Any number of these commands can be received and
acted upon;

(iii) Be de-configured from the closed network by use of the Delete DNID (0BH) command. The
MES would no longer be able to respond to Send Unreserved Report polls to that DNID as it
would not be a member of the network and would not hold the DNID in its memory (see section
A3).

The flowcharts in section A15 describe the actions that the MES should take when it has received a
poll command.

2 Schedule of Operation
The chart below shows valid schedules of polls that may be acted upon by a MES when setting up the
MES to send regular data reports. Normally, the sequence 1 through to 6 would be followed
consecutively (as shown by the thick line) but variations in this schedule are allowed.

* These commands are available to support Inmarsat defined applications. See other Application
Notes, e.g. Application Note 2.
Volume 2: User Services, Part 2: Application Notes, Page: 34
Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

If the MES receives a poll that is allowed to vary from the consecutive schedule 1 to 6 then the
schedule moves to the varying stage and then continues. For example, after a program poll has been
received the MES is allowed to act on a stop poll. Subsequently, the MES would be at stage 5 and
could expect any of the four polls that it is allowed to act upon after stage 5.

Also, for example, after a program poll has been received and a second program poll is then received,
then the MES will overwrite (update) the information stored already.

If the MES receives a poll that is not allowed by the below schedule diagram then this poll is ignored
even if all the poll parameters are valid.

The schedule chart applies to a single DNID-LES ID pair. MESs capable of handling multiple DNID-
LES ID pairs would implement a separate sequence chart for each.

Figure A-1: Schedule Chart

1) Download DNID poll (0AH)

2) Program DNID poll (04H, 01H)

3) Initiate data reports poll (05H, 02H) Delete DNID poll (0BH)
OR Program DNID poll (04H, 01H)
4) Data reports sent by MES OR Stop poll (06H, 03H)

5) Stop poll (06H, 03H)

6) Delete DNID poll (0BH)


Program DNID poll (04H)
OR Initiate data reports poll (05H, 02H)
OR Delete DNID poll (0BH)

The MES does not have to send data reports as shown above; alternatively, the MES could be
programmed to send store-and-forward messages at regular intervals.

Additionally, the MES may act upon any of the below polls without disturbing the state of the MES.
Because the polls listed below are addressed to a specific DNID-LES ID pair, the MES should act
upon any of the below polls at any time in the schedule after stage 1 (Download DNID poll).

- download DNID (0AH) (an update poll, see section A6);

- send unreserved data report (OOH)

- define MEM (07H);

- MEM (08H);

- data transmission (09H);


- others (40H-7FH).

Volume 2: User Services, Part 2: Application Notes, Page: 35


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3 The DNID-LES pair


As the terrestrial user has to set up a local arrangement with an LES in order to configure a closed
network, the MES should only send data reports to that LES (other LESs will not know the destination
of the data report from the DNID). Similarly, the MES should only accept polls addressed to a DNID-
LES ID pair that it holds if it has previously received a download DNID poll from the same LES. This
requirement is in place to prevent unauthorised access to a MES.

For this reason the MES should only act on polls having the correct DNID and LES ID. Every poll
received should be checked for DNID-LES pair validity.

4 Download and Delete DNID Polls


Purpose:

The download and delete DNID polls configure and de-configure the MES in a closed network.

Non-Volatile Memory:

When a Download DNID poll is received, the MES must store the DNID-LES pair in the DCE in non-
volatile memory. This store is required so that the MES is always aware of the closed networks that it
is a member of, even if the MES is turned off for a period of time.

Additionally, the MES must save in non-volatile memory the following parameters:

- Member Number (so that the MES can format data reports correctly);

- the first 25 characters of the text field (so that the terrestrial user can be identified to the MES
user) as an IA5 coded text string. This section of the text field does not have to be passed to
the application;

- Sub-address (see section A8) for configuration I terminals only.

For pre-assigned data reporting, the following are also stored:

- Start Frame

- Slot Number

- Logical Channel Number

- Number of Packets Per Report

- Duration

- Signalling Channel

- LES TDM

- Interval

The MES should be able to save a minimum of 64 DNID-LES pairs in non-volatile memory.

Because the network identifications are stored as DNID-LES pairs, an MES can be a member of
closed network 0001H from LES 143 and simultaneously a member of closed network 0001H from
LES 144. Each closed network 0001H could be connected to separate terrestrial users at each LES.

Volume 2: User Services, Part 2: Application Notes, Page: 36


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Member Number:

Similarly, the member number is stored to identify individual MESs within the closed network. An MES
can not be a member of a closed network more than once, neither can it share its’ member number
with other MESs. As the member number is used by the terrestrial user to identify the source of data
reports it would be confusing to duplicate or split member numbers between MESs.

Therefore, if an MES receives a second download poll with a DNID-LES pair that it has already saved,
then the MES should also check the member number saved with the DNID-LES pair. If the member
number is new, then the poll is treated as an update poll (see section A6).

The member number should be stored in non-volatile memory along with the DNID-LES pair.

MES User Functions - DNID Inhibit:

An MES user should not be able to set up his own DNIDs nor remove DNIDs from the MES memory.
This function can only be carried out by Download and Delete DNID polls for security and operational
reasons.

However, an MES user may inhibit, i.e. disable, DNID-LES ID pairs stored in the DCE memory. When
a DNID-LES pair is disabled the MES should not transmit data reports. It should respond normally to
all other polls.

The MES user may also be able to re-activate, or enable, any DNID-LES ID pair that has been
inhibited. The terrestrial user can not directly inhibit or activate a DNID-LES pair at an MES.

Memory Capacity:

If the DCE non-volatile memory has reached its capacity for DNID-LES pairs, then any new
downloaded DNID-LES pairs should overwrite a disabled DNID-LES pair. If there are no disabled
DNID-LES pairs then the new download DNID poll should be ignored.

Individual Polls:

An MES should only act upon a Download DNID poll if the poll is of individual type. Group or Area
Download DNID polls should be ignored - this situation is unlikely to occur in practice, but MES
designers should be aware of the possibility of a Group Download DNID poll being transmitted by an
LES.

Delete DNID:

The Delete DNID poll erases the DNID-LES pair and all associated parameters from memory.
Subsequent polls to this DNID-LES pair should be ignored.

A Delete DNID poll can be of any type, Individual, Group, or Area.

5 Download DNID (Update) Polls


A special use of the Download DNID poll is that it may be used to update the parameters associated
with a DNID-LES pair in memory. For example, the Download DNID command may be used to
change the MES’ member number associated with a DNID.

After the MES has initially downloaded a DNID-LES pair, the Download DNID command can be used
to update a DNID-LES pair at any time.

Volume 2: User Services, Part 2: Application Notes, Page: 37


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6 Single and Multiple DNID Operation


An MES may be a member of more than one closed network, i.e. it may hold more than one DNID-
LES pair at a time. In fact, the SDM defines that the MES should be able to hold up to a minimum of
64 DNID-LES ID pairs, see section A5, memory capacity.

The MES can be designed to support single or multiple threading of data reporting activities.

Single Threading:

Some MES designers will require only one DNID-LES pair to be programmed (i.e. programmed to
send data reports) at a time. In this case, an MES will only be able to hold one set of programming
information (start frame, interval, etc.) at a time.

If an MES is engaged in sending data reports as programmed under one DNID-LES pair and then
receives a program for another DNID-LES pair then it should ignore the new poll (but acknowledge if
required) and continue with the current application.

Multiple Threading:

An MES able to support multiple threading of data reporting and polling activities will be able to run
programs and carry out operations relating to different DNID-LES pairs in parallel. E.g. If the MES has
had two different DNID-LES pairs downloaded, programmed to send data reports and initiated, then it
will send concurrent data reports to the respective DNID-LES destinations.

The software processing capability for this feature is greater than for single threading. The flowcharts
showing data reporting and polling operations are applicable to multiple threading as well as single
threading in that they can be viewed as a number of parallel processes, running concurrently, with a
separate process for each DNID-LES pair.

Single and Multiple Threading with Different Configurations:

The implementation of single or multiple threading depends upon several factors, for example:

(i) The configuration of the DCE and sub-addresses (configurations I, II or hybrid);

(ii) Where the data reporting program is stored and controlled from (whether in DCE or with
application).

As the control of data reporting is more of an application matter the implementation possibilities are
not discussed here.

When creating data reports, the function of the DCE is seen as to pack the data provided by
applications into the data field.

7 Sub-Addressing
All polls have a sub-address field to direct the poll command to the application running at that sub-
address. The use of sub-addresses is application dependant, but facilities to process them are
sometimes needed by the DCE.

There are two ways of dealing with the sub-address, depending upon the depth of application into the
DTE and DCE:

(i) Check whether there has been a previously downloaded DNID-LES pair to that sub-address
before directing poll (configuration I MESs).

(ii) Direct the poll to the application at the sub-address;

Volume 2: User Services, Part 2: Application Notes, Page: 38


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Method (i) assumes that the application is running at a level above the sub-addresses, not at the sub-
address itself. The equipment connected to that sub-address would generally have little or no
knowledge of the application program. The sub-address field will therefore be saying ‘carry out a
function on the equipment connected to this sub-address’, e.g. turn the lamp at sub-address x ON.

Method (ii) effectively says that polls will only be acted on if addressed to a correct DNID-LES-sub-
address. The application is running at the sub-address only; there could be different applications at
other sub-addresses.

The use of sub-addresses is application dependant, but facilities to process them are sometimes
needed by the DCE.

Sub-address 00 is always the main DTE. In this case the application would be running at the main
DTE.

When carrying out pre-assigned data reporting, if the MES receives a stop reserved data reporting
poll (03H), then all devices at all sub-addresses are to stop data reporting.

8 Responses
All polls have a response field, indicating the format of any return link data. Three types of response
are defined:

- No response;

- Data report format;

- Message transfer format.

The response generally refers to the data sent after:

- an initiate poll (02H or 05H); OR

- a send unreserved report poll (00H).

The facility for commanding a particular response is available, however the actual response may be
determined by the application. Therefore this field may be ignored.

Responses should not be confused with acknowledgements.

9 Acknowledgements
In order to confirm that a poll has been received by an MES then an acknowledgement is sent (if the
acknowledgement field in the poll indicates that an acknowledgement is required).

The acknowledgement always takes the data report format. The acknowledgement is always
formatted and sent by the DCE. If the poll requires data reports to be sent from an application, then
the acknowledgement is always sent before any data reports.

In some cases, the poll may be invalid or the MES may not be able to act on it for some reason. The
flowcharts in section A15 indicate when an acknowledgement should be sent (if required by the poll
packet).

Volume 2: User Services, Part 2: Application Notes, Page: 39


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

In some cases it is not clear what the member number in an acknowledgement to a poll should be set
to. For example, the MES may receive:

- an individual delete DNID poll (0BH) for a DNID not previously downloaded; OR

- an individual download poll (0AH) when the MES memory is full; OR

- an individual data transfer poll (00H, 02H, 05H) with a DNID not previously downloaded.

In the above cases, the member number in the poll acknowledgement should be set to 00H.

10 Sequence Numbers
Each poll sent by the LES contains a sequence number to be used by the MES to detect duplicate
polls. So that all MESs in a group receive a certain poll command, the LES may repeat the same poll
a number of times. An individual MES receiving the first poll will not need to receive further polls so
the sequence number device is used whereby the MES can filter out duplicate polls.

Sequence numbers are incremented by the LES for each separate DNID. This means that the mobile
should compare each poll it receives with its’ record for the latest sequence number for that DNID-
LES pair. So, allied to each record of a DNID-LES pair, there should be a record of the sequence
number of the latest poll to that DNID-LES pair.

Additionally, sequence numbers are used as a reference as to whether a poll acknowledgement was
successfully sent.

For each DNID-LES pair, the MES should store the following:

- The “current” (last valid received) sequence number;

- The date and time that the poll with the above sequence number was received;

- 256 flags, two flags for each of the last 128 sequence numbers from (current sequence number
- 127) to current sequence number.

In the last item, above, one flag indicates whether a poll has been received for the particular
sequence number and the other flag indicates (in the case when a poll was received for the poll
sequence number) whether an acknowledgement data report was successfully sent (if one was
requested).

There is no need to store any of the above in non-volatile memory. The 128 by 2-bit flags require 32
bytes of RAM. In addition, the date and time need to be stored (e.g. the time could be stored as the
frame number in which the poll was received).

On receipt of a valid poll addressed to the MES:

The sequence number arithmetic is modulo 256 so that the test:

(new sequence number - “current” sequence number) > 128

determines whether the sequence number of the new poll is either ahead, or behind, of the currently
stored sequence number. Polls with the sequence number that are ahead of the stored sequence
number are to be accepted as new polls, while polls with sequence numbers behind the stored
sequence number are checked to see if a poll with that sequence number has already been received.

The flowchart Figure A-8 shows the poll sequence number logic that the MES should follow.

Volume 2: User Services, Part 2: Application Notes, Page: 40


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

11 Randomising Interval (Unreserved Data Reporting Only)


Any data reports sent as a response to a group or area poll are liable to collide with data reports from
other MESs in the same group. For this reason, the MES should wait for a random interval before
sending its response. In all group and area polls the LES sends the MES a randomising interval field
indicating a window of frames over which the MES should respond. The MES should randomise a
new time period within the window before sending a data report.

Poll Acknowledgements should be randomised if the poll is a group or area poll for the same reasons.

The randomised time period that the MES calculates before sending a data reports should be taken
from a seed unique to that MES. When programmed data reporting, the mobile should calculate the
next frame number for transmission of a data report by use of the following sequence:

1) Take the Start Frame as Base Frame;

2) Wait until Base Frame is reached;

3) Randomise;

4) Transmit data report;

5) Add Interval to Start Frame to obtain next Base Frame;

6) Continue to stage (2) unless data reporting program over.

While randomising, the MES should remain tuned to the NCS Common Channel until a few frames
before it is due to send the data report.

12 Permanent and Demand Assigned TDM Operation.


If the LES is operating in demand-assigned mode, then the MES sends data reports to the NCS on
the NCS signalling channel, not to the LES on the LES signalling channel.

In demand assigned mode, there is no difference to the reception of polls as the MES is permanently
tuned to the NCS TDM.

13 Action on Distress Alerts, EGCs and Messaging.


As a general rule, all other MES functions take precedence to data reporting and polling. In particular,
the following functions must take priority to the data reporting and polling:

- Distress alerting (maritime terminals);

- Distress messaging (maritime terminals);

- EGC reception;

- Land mobile alerting;

- Store and forward messaging (transmit and receive);

If the MES user initiates a higher level activity, or if the MES receives an announcement or EGC, then
the MES should abort any data reporting and polling function immediately. The MES should abort
even if it is currently receiving a poll, randomising, transmitting a response or tuning.

Volume 2: User Services, Part 2: Application Notes, Page: 41


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

It is up to the MES designer to decide whether the aborted operation will continue after successful
completion of a higher level activity. The MES does not have to re-randomise if it was randomising
when aborted; a response can be transmitted immediately.

14 Poll Command Flowcharts


The flowcharts contained in this section provide an overview of the actions that the MES should take
on receiving the particular polls:

- Download DNID (0AH);

- Program DNID (04H, 01H);

- Initiate data reports (05H, 02H);

- Stop data reports (06H, 03H);

- Delete DNID (0BH);

- Send unreserved data report (00H).

These flowcharts are not definitive in the same way as a System Definition Language is, neither do
they describe a software floorplan. The division of operations between DCE and DTE is not shown,
neither is the level to which the application carries out operations.

Volume 2: User Services, Part 2: Application Notes, Page: 42


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure A-2: Flowchart for MES Action on Receipt of a DOWNLOAD DNID Poll

Download DNID Command: 0AH

Poll: Download
DNID
PQ730

Is
N
individual
poll?
PQ650
Y

Read DNID-LES
pair in poll

Is LES ID valid for this OR?


N
LES ID valid
PQ 715
?
PQ714 Ignore poll - do not
Y PQ715 accept download.
PQ637 PQ708
PQ642 PQ719
PQ662 PQ721 Check sequence End Download DNID
Randomise.
number.
PQ665 PQ744
PQ676 PQ766 Acknowledge.
PQ680 PQ779
PQ682
PQ683
Y DNID - LES pair
in memory
N
(at sub-address)
?
PQ664
N

N Y
DNID N
Are any DNIDs
memory
disabled
full ?
?

N Y

New DNID-LES pair replaces


a disabled DNID-LES pair

Ignore poll - do not


Save DNID-LES pair in accept download.
memory at sub-address.

Poll parameters are: Save poll parameters


with DNID-LES pair PQ685 End Download DNID
Response;
Member number;
Text field. PQ636, PQ641,
PQ730, PQ734.
* LES TDM End Download DNID
* Logical channel number

* Pre-assigned data reporting


only.
PQ656, PQ630, PQ756

Volume 2: User Services, Part 2: Application Notes, Page: 43


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure A-3: Flowchart for MES Action on Receipt of a PROGRAM DNID Poll

Program DNID Command: 01H or 04H

Poll: Program
DNID

Is N
Y Individual
command :
01H? poll
PQ650 ?
N Y

Is Y Is N
area mobile in
poll? area ?
PQ666
N Y PQ668
PQ678
PQ726
Read DNID-LES PQ751
pair in poll PQ791

Is LES ID valid for this OR?


LES ID valid N
PQ 715 ?
PQ714
Y PQ715

Y Individual
poll
? PQ661
N
PQ634
PQ660
LES TDM N
valid
? (Is LES TDM in range
Y allowed for TDMs?)

DNID - LES pair N N


in memory Individual poll
(at sub-address) ?
PQ664 PQ721
?
PQ754 PQ766
Y Y

PQ637 PQ708
Check sequence
Randomise. PQ642 PQ719
number.
PQ662 PQ721
Acknowledge.
PQ665 PQ744
Poll parameters are: PQ676 PQ766
Response; PQ680 PQ779
Member number; PQ682
Randomising interval; PQ683
Ignore poll - do not
PQ636, PQ641, PQ730,
accept program.
PQ734. Save poll parameters
* LES TDM; with DNID-LES pair.
* Slot number;
* Logical channel number;
* Packets per report; End Program DNID End Program DNID
* Signalling channel;
* Start frame, interval and duration.
(PQ659)

* Pre-assigned data reporting only.


PQ656, PQ630, PQ756

Volume 2: User Services, Part 2: Application Notes, Page: 44


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure A-4(i): Flowchart for MES Action on Receipt of an INITIATE DNID Poll

Initiate data reporting Com m and 02H or 05H

Polll: Initiate
data report

Y N
Is Is
area m obile in
poll? area?
PQ666 PQ668
PQ678
Y PQ726
N PQ751
PQ791

Read DNID-
LES
pair in poll

Is LES ID valid for this OR?

LES ID valid N
PQ715
?
PQ714
PQ715
Y

Y Individual
poll

PQ661

LES TDM
valid
N
? (Is LES TDM in range
PQ634
allowed for TDM s?)
PQ660 Y

DNID - LES pair N


in memory Individual poll
N
(at sub-address)
PQ721
PQ766
Y Y

PQ637 PQ708
Poll param eters are:
PQ642 PQ719
Responses
PQ662 PQ721
M em ber num ber:
Check PQ665 PQ744
Random ising interval
sequence PQ676 PQ766
Text field, PQ636, PQ641,
num ber. PQ680 PQ779
PQ730,PQ734
Acknowledge PQ682
. LES TDM ;
PQ683
. Slot num ber;
. Logical channel num ber;
Ignore poll - do not
. Packets per report;
initiate program .
. Signalling channel;
. Start fram e, interval and
duration
(PQ659)

. Pre-assigned data reporting Save poll param eters


only. with DNID-LES pair
PQ656, PQ630, PQ756
.

End initiate data


report

Volume 2: User Services, Part 2: Application Notes, Page: 45


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure A-4(ii): Flowchart for MES Action on Receipt of an INITIATE DNID Poll

Stop DNID Command: 03H or 06H

PQ660
Poll: Stop DNID PQ684
PQ706

Is Y Is N
area mobile in
poll? area ?
PQ666 PQ668
N Y PQ678
PQ726
PQ751
Read DNID-LES PQ791
pair in poll

Is LES ID valid for this OR?


LES ID valid N
PQ 715 ?
PQ714
Y PQ715

Y Individual
poll
?
PQ661
N
Group/area poll

LES TDM N
valid
? (Is LES TDM in range allowed
Y for TDMs ?)
PQ634, PQ660
End Stop DNID

DNID - LES pair N N


in memory Individual poll
(at sub-address) ?
? PQ721
PQ766
Y Y

DNID = 0 N
(Pre-assigned
only)
? PQ776
PQ637
PQ642 Y
PQ708
PQ662 Check sequence
PQ719 Randomise.
PQ665 number.
PQ721
PQ676 Acknowledge.
PQ744
PQ680 PQ766
PQ682 PQ779
PQ683
Are
data reports N
being sent from
this DNID-LES
PQ688 pair?

Stop sending data Note: If sub-address=0, then


Poll parameters are: all devices are to stop
reports from defined
Response; reporting at that DNID-LES
DNID-LES pair.
Member number; pair. PQ 750.
Randomising interval;
PQ636, PQ641, PQ730,
Save poll parameters
PQ734. PQ656
with DNID-LES pair.
* LES TDM;
* Slot number;
* Logical channel number;
End Stop DNID
* Packets per report;
* Signalling channel;

* Pre-assigned data reporting only.


PQ656, PQ630, PQ756

Volume 2: User Services, Part 2: Application Notes, Page: 46


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure A-5: Flowchart for MES Action on Receipt of a STOP DNID Poll

Stop DNID Command: 03H or 06H

PQ660
Poll: Stop DNID PQ684
PQ706

Is Y Is N
area mobile in
poll? area ?
PQ666 PQ668
N Y PQ678
PQ726
PQ751
Read DNID-LES PQ791
pair in poll

Is LES ID valid for this OR?


LES ID valid N
PQ 715 ?
PQ714
Y PQ715

Y Individual
poll
?
PQ661
N
Group/area poll

LES TDM N
valid
? (Is LES TDM in range allowed
Y for TDMs ?)
PQ634, PQ660
End Stop DNID

DNID - LES pair N N


in memory Individual poll
(at sub-address) ?
? PQ721
PQ766
Y Y

DNID = 0 N
(Pre-assigned
only)
? PQ776
PQ637
PQ642 Y
PQ708
PQ662 Check sequence
PQ719 Randomise.
PQ665 number.
PQ721
PQ676 Acknowledge.
PQ744
PQ680 PQ766
PQ682 PQ779
PQ683
Are
data reports N
being sent from
this DNID-LES
PQ688 pair?

Stop sending data Note: If sub-address=0, then


Poll parameters are: all devices are to stop
reports from defined
Response; reporting at that DNID-LES
DNID-LES pair.
Member number; pair. PQ 750.
Randomising interval;
PQ636, PQ641, PQ730,
Save poll parameters
PQ734. PQ656
with DNID-LES pair.
* LES TDM;
* Slot number;
* Logical channel number;
End Stop DNID
* Packets per report;
* Signalling channel;

* Pre-assigned data reporting only.


PQ656, PQ630, PQ756

Volume 2: User Services, Part 2: Application Notes, Page: 47


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure A-6: Flowchart for MES Action on Receipt of a DELETE DNID Poll

Delete DNID Command: 0BH

Poll: Delete DNID PQ660


PQ684
PQ695

Is Y
area
poll?
PQ666
N

Read DNID-LES
pair in poll

Is LES ID valid for this OR?


LES ID valid N
PQ 715
?
PQ714
Y
PQ715

Y Individual
poll
?
N PQ661
Group/area poll
PQ634
PQ660 N
LES TDM
valid
(Is LES TDM in range
?
Y allowed for TDMs?)

DNID - LES pair N N


in memory Individual poll
(at sub-address) ?
PQ721
? PQ766
Y Y
PQ637
PQ642 PQ708
Check sequence
PQ662 PQ719 Randomise.
number.
PQ665 PQ721
Acknowledge.
PQ676 PQ744
PQ680 PQ766 End Delete DNID
PQ682 PQ779
PQ683 Are data
reports currently Y
being sent from this
DNID-LES pair
PQ664
?
PQ728
N
Stop DNID
Use same poll parameters
PQ684
PQ695 as in this Delete DNID poll.

Delete DNID-LES
pair from memory
(at sub-address)
and all associated
parameters

End Delete DNID

Volume 2: User Services, Part 2: Application Notes, Page: 48


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure A-7: Flowchart for MES Action on Receipt of a SEND UNRESERVED Poll

Send Unreserved Command: (00H)


data report

Poll: Send
Unreserved data
report PQ660

Is Y Is N
area mobile in
poll? area ?
PQ666 PQ668
N Y PQ678
PQ726
PQ751
Read DNID-LES PQ791
pair in poll

Is LES ID valid for this OR?


LES ID valid N
PQ 715 ?
PQ714
Y
PQ715

Y Individual
poll
?
PQ661
N Group/area poll

LES TDM N
valid
PQ634
? (Is LES TDM in range
PQ660
Y allowed for TDMs?)

DNID - LES pair N N


in memory Individual poll
(at sub-address) ?
? PQ721
PQ766
Y Y
PQ637
PQ642 PQ708
PQ662 Check sequence Check sequence
PQ719 Randomise.
PQ665 number. number.
PQ721
PQ676 Acknowledge. Acknowledge.
PQ744
PQ680 PQ766
PQ682 PQ779
PQ683 PQ633
Randomise
PQ662
PQ683

Send response, as PQ662


defined in PQ665
[response] field. PQ667
PQ719

End Send Unreserved


data report

Volume 2: User Services, Part 2: Application Notes, Page: 49


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure A-8: Sub-Flowchart for MES Handling of Sequence Numbers

New valid Individual/Group/Area Poll


received

START

yes stored
date & time
> 24 hrs old
?
no
Clear all flags,
update "current" PSN (new PSN no
and date and time. -current PSN)
<128?
yes

update "current" PSN


and date and time
no yes
PSN received
before?

Process
Poll
yes Individual
Poll?
Set poll received
flag no
for this PSN
no
Ack previously
sent OK?
Ack no yes
requested?

yes

Send
Acknowledgement

yes
Ack sent
OK?

no
Set Ack sent OK
flag

END

Volume 2: User Services, Part 2: Application Notes, Page: 50


Application Note 3: Application Developers Guide to Data Reporting and Polling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Application Note 4: Guide To Development of a


Mobile To Mobile Reporting Service

Contents

1 Scope ..................................................................................... 4

2 Introduction ............................................................................ 4
2.1 Aims of Mobile-Mobile Reporting ......................................................................4

3 General Description ................................................................ 5


3.1 System Concepts ..............................................................................................5
Figure 1: Conceptual Communications Model for Mobile-Mobile Reporting............5
3.2 Outline Process .................................................................................................5
Figure 2: Inmarsat-C Network Architecture Supporting Mobile-Mobile Reporting ...5
3.3 Service Variants ................................................................................................6
3.3.1 Base Oriented Communications.....................................................................6
3.3.2 Generic Mobile-Mobile Communications ........................................................6
3.4 Service Elements ..............................................................................................6
3.5 System Constraints ...........................................................................................7
3.5.1 System Components ......................................................................................7
3.5.2 Compatibility with Existing Application Notes .................................................7
3.5.3 Addressing .....................................................................................................7
3.5.4 Network Architecture ......................................................................................7

4 Packet Definitions ................................................................... 7


4.1 Packet formats for non-interpreted transactions ...............................................8
4.1.1 Data Report Packet Format ...........................................................................8
Figure 3: Non-Interpreted Data Report Format .......................................................9
4.1.2 Polling Packet Format ....................................................................................9
Figure 4: Group Poll Format for Non-Interpreted Data Reports ..............................9
4.1.3 Packet Formats for Interpreted Transactions ............................................... 10

Volume 2: User Services, Part 2: Application Notes, Page: 1


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.1.3.1 Data Report Packets ............................................................................................................ 10

4.1.3.1.1 Use of category and extended category fields.................................................................. 10

Table 1: Extended Category Bit Interpretations for Mobile-Mobile Reporting ....... 10


4.1.3.1.2 Data Report Packet Contents ........................................................................................... 10

Figure 5: Data Report Format for Base-Mobile Transactions Using Group Polls .. 11
Figure 6: Data Report Format for Base-mobile Transactions Using Individual Polling
11
4.1.3.1.3 Internal Checksum Format ................................................................................................ 11

4.1.3.2 Poll Contents ........................................................................................................................ 12

4.1.3.2.1 Sub-address Field ............................................................................................................. 12

4.1.3.2.2 Command Field ................................................................................................................. 12

4.1.3.2.3 Sequence Number ............................................................................................................ 12

4.1.3.2.4 Response Field ................................................................................................................. 12

5 Server Implementation .......................................................... 12


5.1 Functionality .................................................................................................... 12
5.2 Architecture ..................................................................................................... 13
Figure 7: LES Server Application Block Diagram .................................................. 13
5.2.1 LES Interfaces ............................................................................................. 13
5.2.1.1 Interface to LES to Support Data Reporting ........................................................................ 13

5.2.1.2 Interface to LES to Support Polling ...................................................................................... 13

5.2.1.3 Security ................................................................................................................................ 14

5.2.1.4 Billing .................................................................................................................................... 14

5.2.1.5 Error Handling ...................................................................................................................... 14

5.2.2 Mobile-Mobile Protocol Engine .................................................................... 14


5.2.3 Database Architecture.................................................................................. 14
Table 2: Example Database Architecture .............................................................. 15

6 Base Oriented Communications ............................................. 16


6.1 Overview ......................................................................................................... 16
6.2 Single Ocean Region Operation ..................................................................... 16
6.2.1 Setting up the Server ................................................................................... 16
6.2.2 Configuring the Mobiles ............................................................................... 16

Volume 2: User Services, Part 2: Application Notes, Page: 2


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6.2.3 Communications Process Description.......................................................... 16


6.3 Multiple Ocean Region Operation ................................................................... 16
6.3.1 Setting up the Server ................................................................................... 16
6.3.2 Configuring the Mobiles ............................................................................... 17
Figure 8: Network Architecture for Mobile-Mobile Operation Between Mobiles and
Base Stations Distributed Across Multiple Ocean Regions...................................... 17
6.3.3 Communications Process Description.......................................................... 17
6.3.4 Support for Large Groups of Mobiles ........................................................... 17
6.4 Base Station Implementation .......................................................................... 17
Figure 9: Base Station Architecture for Operation with Large Groups of Mobiles . 19
6.5 Base Station MES DTE Application ................................................................ 19
6.5.1 DTE Architecture .......................................................................................... 19
6.5.2 Mobile-Mobile Protocol Engine .................................................................... 19
6.5.3 DNID and Member Number Management .................................................... 19
6.5.4 MES DCE Interfaces .................................................................................... 19

7 Generic Mobile-Mobile Communications ................................ 20


7.1 Overview ......................................................................................................... 20
7.2 Single Ocean Region Operation ..................................................................... 20
7.2.1 Setting up the Server ................................................................................... 20
7.2.2 Configuring the Mobiles ............................................................................... 20
7.2.3 Communications Process Description.......................................................... 20
Figure 10: Example Data Report Format for Generic Mobile-Mobile Reporting .... 21
Figure 11: Example Group Poll Format for Generic Mobile-Mobile Reporting ...... 21
7.3 Multiple Ocean Region Operation ................................................................... 22

8 References ............................................................................ 22
Figure 12: LES Server SDL, Mobile-Mobile Reporting, Sheet 1 of 4..................... 23
Figure 12: LES Server SDL, Mobile-Mobile Reporting, Sheet 2 of 4..................... 24
Figure 12: LES Server SDL, Mobile-Mobile Reporting, Sheet 3 of 4..................... 25
Figure 12: LES Server SDL, Mobile-Mobile Reporting, Sheet 4 of 4..................... 26

Volume 2: User Services, Part 2: Application Notes, Page: 3


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Scope
This Application Note describes a facility for provision of mobile to mobile communications using the
Inmarsat-C data reporting and polling protocols, and presents guidelines for development of
application software to support the facility. Familiarity with the data reporting and polling protocols is
assumed, and the previous related application notes; Application Note 2: Position Reporting Protocol
and Application Note 3: Developers Guidelines for the Polling Protocols, are referred to within this
Application Note.

2 Introduction
There is a general market requirement for fast and cost effective delivery of small amounts of data
such as position reports between mobiles within a closed network. The store and forward messaging
protocols, while extremely robust, are inefficient for delivery of small amounts of data due to the
additional transmission overheads, and are correspondingly slow. Combining the Inmarsat-C data
reporting and protocols can result in a delivery mechanism which is faster and more efficient than
store and forward messaging for delivering small amounts of data. It should be noted however that the
messaging protocols are significantly more robust, as they include multiple automatic retransmissions
of data.

This document describes a means by which the existing Inmarsat-C data reporting and polling
protocols can be used to construct a variety of applications of differing complexity. This Section
describes the aims of the mobile-mobile reporting protocol, Section 3 provides a general description
of the system concepts, including an outline of the process and the service elements. Section 4
defines the contents of packet structures, and Section 5 describes a method of implementation for the
service, outlining the architecture of a server. Section 6 describes the provision of a base-oriented
service, with possible implementations for a base station being described. Section 7 describes the
provision of a generic mobile-mobile service which includes new capabilities, and outlines the
functionality required within the mobile earth station DTE software to access these capabilities.

2.1 Aims of Mobile-Mobile Reporting


The primary aim of mobile-mobile reporting is to provide a fast and flexible means of delivering small
amounts of data to and from mobile terminals. There are a number of additional requirements, which
can be considered to be either essential or desirable;

a) Primary Requirements:

(i) Support for both mobile-base and base-mobile transactions

(ii) Use of standard unmodified DCEs

(iii) Use of unmodified DTE software in mobile terminals should be supported

(iv) Support for existing polling application software in customers’ base stations (terrestrial
link to be replaced by an Inmarsat-C link)

(b) Secondary Requirements:

(i) Support for multiple ocean region operation

(ii) Support for validation of data transmitted by the LES at the source mobile

(iii) Support for end-end acknowledgements

(iv) Support for general mobile-mobile transactions

Volume 2: User Services, Part 2: Application Notes, Page: 4


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3 General Description

3.1 System Concepts


The mobile-mobile reporting service involves the transfer of information between MESs via an LES
which supports the mobile-mobile reporting service. Any transaction therefore involves a source and
destination mobile and the Inmarsat-C LES network. The mobile-mobile process is controlled by
application software located at the MES and LES. To simplify the implementation and reduce the
difficulties associated with introduction of the service, these applications are described within this
Application Note as being situated within the DTE of the MES and within a separate server attached
to the LES. The conceptual model [1] for mobile-mobile reporting communications is shown in the
following diagram:

Figure 1: Conceptual Communications Model for Mobile-Mobile Reporting

End User Application End User


Application Interworking Application
Function
OSI 7 OSI 7 OSI 7

Inmarsat-C Inmarsat-C
Network Network

Source DTE Server Destination DTE

3.2 Outline Process


The communications process consists of two distinct operations via the Inmarsat-C system. Each
mobile to mobile transaction involves the transmission of a data report, consisting of between one and
three packets, to the LES, the reformatting of the data into a polling packet by the server, and the
transmission of this polling packet to the destination MES on the NCS common channel TDM.

Figure 2: Inmarsat-C Network Architecture Supporting Mobile-Mobile Reporting

Volume 2: User Services, Part 2: Application Notes, Page: 5


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Mo
Po bile-M
llin
g P obile
ack Sp
rd rts ets ecif
da epo Mo ic

Data Re
n lls b
a
St ta R Po Da ile-M
ta
D a r d Re obile
da po
rts Spec
t an ific

po
S

Po
rts

lls
HQ Base Station

ISL

Closed User Group of Mobiles


LES NCS

Server

3.3 Service Variants

3.3.1 Base Oriented Communications


Figure 2 illustrates the use of a base station with mobile-mobile reporting. A base station would
normally be at a fixed location and provide the functionality of a hub, collecting data about the
condition of a customer’s mobiles and presenting this to an operator. The base station may be
connected directly to an LES via a terrestrial network, but in cases where the terrestrial network
connection is unavailable or unreliable, mobile-mobile reporting can be used. In this configuration the
functionality normally available to the base station should be the same as that normally available via
the terrestrial network when assembling polling packets. However, the mobile terminals should not
need to behave any differently to the case when the base terminal is connected to the LES via the
terrestrial network, and may not contain any software specific to mobile-mobile reporting. There is
therefore an asymmetry in the communications, with the server having to interpret the information in
the data reports from the base station, but not needing to interpret the information in the data reports
from the mobiles. This operating configuration is designed to facilitate the use of existing Inmarsat-C
application software in locations where the terrestrial network is unsuitable. Details of the
implementation of this operating configuration are described in Section 6 of this document.

3.3.2 Generic Mobile-Mobile Communications


Mobile to mobile reporting can support the transfer of information between any two mobiles in a
closed group. To successfully implement this functionality, each mobile needs to contain software
specific to mobile reporting. The server only needs to provide limited functionality to support this
operational configuration, and does not need to interpret the data within the data reports from the
mobiles. A number of additional features then become possible, and these are described in further
detail in Section 7 of this document.

3.4 Service Elements


The two operating configurations defined above illustrate the requirement for two different service
elements; either the information in the data report packets is interpreted by the server providing the
service, or the information is not interpreted, but is simply forwarded using a default set of parameters
for the polling packet. This is an essential part of the definition of the service, and therefore Section 4
which defines the packet structures reflects this dichotomy.

Volume 2: User Services, Part 2: Application Notes, Page: 6


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.5 System Constraints

3.5.1 System Components


The Inmarsat-C communication components; the MES DCE, LES and NCS do not need to be
modified or enhanced to support mobile-mobile reporting, provided that these already support the
standard polling and data reporting protocols.

3.5.2 Compatibility with Existing Application Notes


Application Notes 2 and 3 define the contents of data report packets for different services and
applications, for example, position reporting packets for maritime and land-mobile terminals are
defined, as are acknowledgement polls. This identification of the service type is performed by means
of the category and extended category fields within the data report, and this application guide utilises
a number of the reserved values within the extended category fields to identify the information
contained within the data report further. The use of the extended category fields allows a number of
variations to the basic service to be implemented, depending upon the capabilities of the mobile
terminals and the functionality required by the application.

3.5.3 Addressing
Mobile-mobile reporting is distinguished from other polling and data reporting protocols using DNIDs
selected from a separate range of values. The DNID values used for mobile-mobile data reporting
must be within the previously reserved range 32768 to 49151, DNID values within the range 49152 to
65535 remain reserved for future use. This is essential because mobile to mobile reporting is distinct
from the standard polling and data reporting protocols in that the charging is based upon the entire
mobile-mobile transaction instead of the independent processes.

During the provision of a mobile-mobile service to a new customer, it is necessary to determine the
service elements which the customer requires. Separate DNIDs need to be assigned for base station
and mobile transactions. Information sent to the server using the base station DNID is forwarded to
the destination mobiles using the mobile earth station DNID, and vice-versa. Information in the data
reports from the mobiles is not interpreted by the server at the LES, and the DNID for these
transactions must be in the range 32768 through 40959. The information in the data reports
originating from the base station is interpreted by the LES server, and the DNID for these transactions
must be in the range 40960 through 49151. For the generic mobile-mobile transactions, one DNID is
adequate, this being in the same range as for other mobile originated calls, ie in the range 32768
through 40959. This is explained in further detail in Section 8 below.

3.5.4 Network Architecture


The polling packets described in this application note are normal Inmarsat-C polling packets, and are
delivered via the NCS TDM common channel, this being the normal operation as described in Volume
5 of the SDM. In future it may be possible to modify the network architecture in such a way that the
mobiles login to their preferred LES, and in this case, the polls would be delivered on the LES TDM
channel. This would not affect the implementation of application software using mobile to mobile
reporting, as the existing services supported by the data reporting and polling protocols would still be
available. Improved delivery performance may be achievable in the future if mobile-mobile software is
enhanced to take advantage of this feature.

4 Packet Definitions
The mobile to mobile data reporting and polling protocols use the currently defined data reporting and
polling packets. There is a considerable amount of flexibility in the way these packets can be used,
and this Section describes methods by which the relevant packet structures can be utilised to provide
the necessary service elements. The information in the data reporting packets can be ignored by the
server acting as an Application Inter-Working Function [1], with a default delivery mechanism being

Volume 2: User Services, Part 2: Application Notes, Page: 7


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

used, or the information in the packets can be interpreted by the server, in which case the defaults are
only relevant for those fields which are not specified.

4.1 Packet formats for non-interpreted transactions


For the case where transactions originate from mobile terminals, the information in the data reporting
packets is not interpreted by the server.

4.1.1 Data Report Packet Format


The data field within the data reports which originate from the mobile terminals are considered as only
being formatted as described in the definition of data reports in Volume 4, Chapter 4 of the SDM, from
the perspective of the mobile-mobile application software at the LES server.

Volume 2: User Services, Part 2: Application Notes, Page: 8


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 3: Non-Interpreted Data Report Format

Bit No. Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
1 P C Type 1 P C Type 1 P C Type
2 2 2
DNID
3 3 3
4 LES ID 4 4
5 Source Member No. 5 5
6 6 6
7 7 7
Byte

Byte

Byte
8 Data 8 Data 8 Data
9 9 9
10 10 10
11 11 11
12 12 12
13 13 13
14 14 14
CRC CRC CRC
15 15 15
Standard Data Report Packet First Continuation Packet Second Continuation Packet
(Optional) (Optional)

4.1.2 Polling Packet Format


The data reports which are not interpreted by the Application Inter-Working Function server are all
delivered using group polling, with the DNID/LES ID combination set to the value specified in the
server database. The source mobile member number is placed in the first byte of the data field,
followed by the remainder of the information in the data field of the data report packets.

The sequence number is not specified by the server, but is incremented by the LES. The command
field is set to a value of 10H, indicating the presence of the source mobile member number within the
data. The sub-address field is set to a value of zero, and the response field is also set to zero.

Figure 4: Group Poll Format for Non-Interpreted Data Reports

Bit No.
8 7 6 5 4 3 2 1
1 P Type
2
Length
3
4
DNID
5
6 LES ID
7
LES TDM
Byte

8
9 Sub-Address
10 Randomising Interval
11 Resp Spare
12 Command
13 Sequence No.
14 Source Member No.
15
16
Text/ Data

CRC

Volume 2: User Services, Part 2: Application Notes, Page: 9


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.1.3 Packet Formats for Interpreted Transactions


For base-to-mobile transactions, the data reports which originate from the base station contain a
description for the construction of the polling packet to the mobile terminals, and these are interpreted
by the Application Inter-Working Function software within the server.

4.1.3.1 Data Report Packets

4.1.3.1.1 Use of category and extended category fields

Certain applications such as position reporting for land mobile and maritime terminals have packet
structures which are already defined within Application Note 2, ‘ Position Reporting’. It is important
that any information from the base station is interpreted correctly by the server application software,
and to minimise the potential for erroneous action, compatibility with the existing application notes is
maintained within the definition of the interpreted data report formats for mobile-mobile reporting.

The means by which the information within the data reports is interpreted is with the aid of the
extended category fields within the data report packet. The existing reserved values are to describe
the construction of the polling packet for mobile to mobile reporting. The category field is set to the
value of 10B for all interpreted mobile-mbile data report.

Table 1: Extended Category Bit Interpretations for Mobile-Mobile Reporting

Bit number Interpretation (Bit = 0) Interpretation (Bit = 1)

5 Mobile/Mobile Data Report Other use (reserved or user defined)


4 Individual Poll Group Poll
3 No sub-address specified Sub-address specified in data field
2 No command field specified Command specified in data field
1 No sequence number specified Sequence number specified
0 No response field specified Response field specified

4.1.3.1.2 Data Report Packet Contents

It is possible to specify a number of fields within the polling packet using the interpreted data report
format. If these fields are not specified, the following values are used as defaults; the sub-address
field is set to zero, the command field to 09, the sequence number is incremented by the LES and the
response field is set to zero.

The format of data report packets used to specify delivery of information from a base terminal to the
group of mobiles is shown in Figure 5.

Volume 2: User Services, Part 2: Application Notes, Page: 10


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 5: Data Report Format for Base-Mobile Transactions Using Group Polls

Bit No. Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
1 P C Type 1 P C Type 1 P C Type
2 2 2
DNID
3 3 3
4 LES ID 4 4
5 Source Member No. 5 5
6 Cat. Extended Cat. 6 6
7 (Sub-Address) 7 Data 7 Data
Byte

Byte

Byte
8 (Command) 8 8
9 (Sequence No.) 9 9
10 (Rsp) Spare 10 10
11 11 11
12 Data 12 12
13 13 13 (DataField-Checksum)
14 14 14
CRC CRC CRC
15 15 15
Base-Mobile Data Report Packet First Continuation Packet Second Continuation Packet
for delivery using Group Polls (Optional) (Optional)

The format of data report packets used to specify delivery of information from the base terminal to an
individual mobile is shown in Figure 4.4 below. Note the use of Inmarsat-C Mobile Number to identify
the destination mobile when individual polls are used for delivery.

Figure 6: Data Report Format for Base-mobile Transactions Using Individual Polling

Bit No. Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
1 P C Type 1 P C Type 1 P C Type
2 2 (Rsp) Spare 2
DNID
3 3 3
4 LES ID 4 4
5 Source Member No. 5 5
6 Cat. Extended Cat. 6 6
7 7 Data 7 Data
Inmarsat-C
Byte

Byte

Byte

8 8 8
Mobile
9 Number 9 9
10 10 10
11 (Sub-Address) 11 11
12 (Command) 12 12
13 (Sequence No.) 13 13 (DataField-Checksum)
14 14 14
CRC CRC CRC
15 15 15
Base-Mobile Data Report Packet First Continuation Packet Second Continuation Packet
for delivery using Individual Polls (Optional) (Optional)

The absence of any of the fields causes the subsequent fields to be placed earlier in the packets. For
example, if the destination sub-address is not specified, then the command field is placed immediately
after the extended category field in the group polling case, and immediately after the MES ID in the
individual polling case.

4.1.3.1.3 Internal Checksum Format

The data reporting protocol is based upon a random access channel, and it is possible for collisions
between packets to occur, resulting in the loss of data. When continuation packets are used with the
data reporting it is possible, under certain circumstances, for information from one mobile being

Volume 2: User Services, Part 2: Application Notes, Page: 11


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

appended to that transmitted from another mobile. To reduce the potential for the invalid interpretation
of data, it is necessary to apply an additional checksum when using multiple packet reports, where
this checksum is generated using the entire data field within the data report packets. This can be
done as an end-end process, or in the case of mobile-mobile reporting, a check can be performed by
the server after the initial transfer of information from the source MES, such that the information is not
forwarded if it is invalid. An application layer process at the MES or base station can then request the
repetition of the information.

If server validation of multiple packet reports is required, then this needs to be stipulated at the time
the service is initiated, and the server software is configured to check all multiple packet reports for a
particular DNID. The internal checksum which can be used for validation purposes is generated by an
one’s complement addition (Modulo 256) operation on all of the bytes within the data field of the data
report packets to be transmitted (if this extends to more than one packet). This algorithm results in a
single byte field which is placed at the end of the last data report packet of the multiple-packet
transmission.

4.1.3.2 Poll Contents

Two types of polling packet are relevant for the interpreted base-mobile transactions; group and
individual polls. Both polls are completely standard, as defined in Volume 4, and discussed in detail in
Volume 2 Part 2, Application Note 3, Developer’s Guide to Data Reporting and Polling. The following
fields can be specified using the interpreted data reports.

4.1.3.2.1 Sub-address Field

The sub-address field for base-mobile polling packets defaults to zero, unless specified by the base
station within the data report packet structure. This facility allows the base station to remotely access
application specific software within the DCE or DTE of the mobile.

4.1.3.2.2 Command Field

The command field for base-mobile polling packets is set to 09H unless specified by the base station
within the data report packet structure. The facility for specification of the command field within the
data report allows the base station to remotely program DCE software, and facilitates more elaborate
applications to be developed.

4.1.3.2.3 Sequence Number

The sequence number for base-mobile polling packets increments automatically after each
transmission, unless specified as a particular value within the data report packet structure from the
base station. This facility, which may only be available at certain LESs, allows a base station to poll
the entire group of mobiles, with repeated attempts being made to contact those mobiles which have
not initially responded, and is used mainly when programming of mobile DCE or DTE application
software.

4.1.3.2.4 Response Field

This is set to zero in all base-mobile polling packets unless specified within the data report packet.

5 Server Implementation
Guidelines for the development of the application within the server are described within this section.

5.1 Functionality
The server application provides the functionality of translating the contents of data reports into polling
packets, based upon information related to the population of mobiles for which information is stored in
the database. The server should be capable of redirecting the polling packets to the appropriate LES.

Volume 2: User Services, Part 2: Application Notes, Page: 12


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Facilities for setting up and modifying information about a customer in the database are required, as
discussed in detail below. Facilities for recording the traffic generated by the mobiles within a group,
and producing summary reports on request, are also required for billing purposes.

5.2 Architecture
The architecture of the application server centres around the database and mobile-mobile protocol
engine. Interface modules facilitate the connection of the protocol engine to the appropriate LES. A
user interface facility allows direct update and control of the database facilities. Other modules, such
as interfaces to billing systems and printers may be required for full service operation, as illustrated in
Figure 7 below.

Figure 7: LES Server Application Block Diagram

To LES To billing system

LES interface Logging/ billing/


modules monitoring module
Alarms

Mobile-mobile Database
Protocol Engine Engine
Application Server

User Interface Storage


Modules

Printer Console

5.2.1 LES Interfaces


The LES interface modules translate the data report and polling information between the proprietary
description languages used by the various LESs to a standard form which can be accessed by
application software, such as the mobile-mobile protocol engine. From the perspective of the LES, the
server is a single customer with its own PIN, and the bills for all mobile-mobile transactions are
addressed to the server. The server monitors and records the traffic generated by the individual
customers’ user groups.

5.2.1.1 Interface to LES to Support Data Reporting

The data report data must be transferred from the LES to the server immediately upon reception of a
data report with a mobile-mobile DNID. The data report should be formatted as described in
Application Note 2 of Volume 2 of the SDM, with the contents of the report transferred either as a
binary or hex-coded ASCII file.

5.2.1.2 Interface to LES to Support Polling

The poll data should be transferable into the LES using a file transfer mechanism, with the contents of
the poll being transferred either as a binary or hex-coded ASCII file. The facilities that are required
are:

Volume 2: User Services, Part 2: Application Notes, Page: 13


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

a) specification of group poll or individual poll for delivery

b) specification of DNID/member number (and Inmarsat-C Mobile Number for individual polls)

c) specification of sub-address field

d) specification of command field

e) specification of response field

f) specification of sequence number (optional)

The development of the LES interfaces has already been undertaken as part of the development of
the Inmarsat-C API programme. These provide a standard interface for development of application
software which can communicate successfully with all LESs. The development of mobile-mobile
application software which is resident in the LES server is much simpler if the LES API is used by the
application.

5.2.1.3 Security

The transactions between the server and the LES need to be protected by a PIN which only the LES
operator and service provider are aware. End-user customers do not need access to this PIN. Some
protection against fraudulent use is provided in that all DNIDs are down-loaded over the Inmarsat-C
network, and the first DNID needs to be downloaded by the service provider.

5.2.1.4 Billing

The server behaves as a customer operating many DNIDs. This simplifies both the administrative
overhead, in terms of assigning PINs, and the billing. The end customer is not billed directly from the
LES with the standard charges for data reporting and polling protocols, but the traffic associated with
each end-customer is monitored by the server and traffic summary information is generated for each
end-customer by the server on request by the operator.

5.2.1.5 Error Handling

If the server cannot deliver the poll, for example, if it is refused by the LES then the server print an
error report and generate a console message. The server should not attempt to deliver the failure
code using a polling packet, unless the reason for failure is that the destination mobile is not logged
in, when the server may generate a group poll to the base station using a command value of 11H
followed by the Inmarsat Mobile Number.

5.2.2 Mobile-Mobile Protocol Engine


The mobile to mobile protocol engine provides a mapping from the received data reports to polls
based upon the type of service required, and the contents of the data reports. The protocol engine
does not provide facilities for retransmission of polling packets, and therefore does not require a
complex state machine within the implementation. The SDL shown in Annex 1 provides an indication
of the level of complexity required. This SDL is split into three parts; the first part extracts the data
from the data reports and determines the service required; the second part deals with groups of
mobiles which reside on the same TDM, and the third part deals with groups of mobiles which are
distributed across TDMs.

5.2.3 Database Architecture


This section describes an architecture which could be used within the LES server to support the
mobile-mobile service. An example of the structure for the information within the database is shown in
Table 2 (additional information may be needed, depending upon the requirements of LES operators).

Volume 2: User Services, Part 2: Application Notes, Page: 14


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Each mobile-mobile service customer can own a number of groups of mobiles, each with its own LES
ID/ DNID pair. Each mobile, which has a unique Inmarsat-C Mobile Number, is owned by a customer
and can communicate in one or more of the groups owned by the customer.
Table 2: Example Database Architecture

Customer Entity Records

Customer Entity ID

Customer Name

Customer Address

Customer Billing Records (etc.)

Group Entity IDs (n)

Mobile Entity IDs (n) (optional)

Group Entity Records

Group Entity ID

Receive (LES ID / DNID) combination

Transmit (LES ID / DNID) combination

Base station Inmarsat-C Mobile Number for default delivery (optional)

Interpret data within polls? (Y/N) (receive DNID in range 40960 to 49151)

Server Validation of base station data? (Y/N)

No of successful single packet data reports for this group

No of successful double packet data reports for this group

No of successful triple packet data reports for this group

No of failed data reports from this group (optional)

Mobile Entity Records (optional)

Mobile Entity ID

Inmarsat-C Mobile Member Number

(Group ID/ Member Number) (n)

Active Group ID (optional)

No of successful single packet data reports from this mobile

No of successful double packet data reports from this mobile

No of successful triple packet data reports from this mobile

No of failed data reports from this mobile

Volume 2: User Services, Part 2: Application Notes, Page: 15


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6 Base Oriented Communications

6.1 Overview
The base oriented mobile-mobile communications provides an alternative means of connecting a
base station to an LES, in that the Inmarsat-C system can provide the connection instead of a
terrestrial connection such as the PSDN or PSTN. All of the facilities that would normally be available
when sending a poll from the base station if this were connected via the terrestrial line are supported
by the Inmarsat-C mobile-mobile connection between the base station and the server providing the
Application Inter-Working Function. The mobile earth station DCE and DTE are unmodified, and
existing application polling and data reporting software will work using mobile to mobile reporting.

6.2 Single Ocean Region Operation

6.2.1 Setting up the Server


The service is provided by setting up two LES-ID/DNID pairs within the server database for the
customer. The Inmarsat Mobile Number for the base station is also programmed into the database of
the server. For the first LES-ID/DNID pair, which will be used by the base station, the DNID is in the
range 40960 through 49152, and the server will interpret the data reports. If the base station can
support the facility, usually the server will be instructed that multiple packet data reports originating
from the base station will be protected with an internal single byte checksum. The second LES-
ID/DNID pair is in the range 32768 through 40959, and is used for transactions with the mobiles. The
server will not interpret the contents of these data reports, and usually no checksum will be present.

6.2.2 Configuring the Mobiles


The service provider instructs the LES to transmit a poll to the base station programming it with the
LES-ID / DNID and member number it will use for communication. The customer can then use the
standard programming poll functions to place each of the mobiles within the closed user group that
will be used for mobile-mobile communications.

6.2.3 Communications Process Description


Data reports transmitted by the base station using the first DNID are interpreted by the server and
translated to polls which are delivered to the mobiles using the second DNID. Information transmitted
by the mobiles using the second DNID are mapped directly into a group poll without being interpreted
and transmitted to the base station using the first DNID.

6.3 Multiple Ocean Region Operation

6.3.1 Setting up the Server


A multiple ocean region service is provided by setting up an LES-ID/DNID pair within the server
database for an LES in each region the customer wishes to operate for the mobile terminals. Each of
these LES-ID/ DNID pairs for the mobile terminals has a corresponding LES-ID/ DNID pair for
communications with the base station on the LES which the base station will use. The Inmarsat
Mobile Number for the base station is also programmed into the database of the server. For the first
set of LES-ID/DNID pairs, which will be used by the mobiles, the server is told not to interpret the data
reports, but to deliver these to the base station using a group poll with the corresponding LES-ID/
DNID combination. For the second set of LES-ID/DNID pairs which the base station will use (all on the
same LES), the server is told to interpret the contents of the data report, and to deliver these using the
corresponding LES-ID /DNID pair using the appropriate LES.

Volume 2: User Services, Part 2: Application Notes, Page: 16


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6.3.2 Configuring the Mobiles


This is handled as for operation within a single region, with the customer programming his mobiles
with the appropriate DNIDs using the mobile to mobile protocol. Provision needs to be made for
retuning and logging-in of the mobiles to each ocean region to allow this setup-process to occur, and
it is easier to complete the configuration in a controlled environment.

Figure 8: Network Architecture for Mobile-Mobile Operation Between Mobiles and


Base Stations Distributed Across Multiple Ocean Regions
OR A Satellite OR B Satellite

Mobile-Mobile Specific
Polling Packets
Standard
Data Reports

ISL
Base station

LES in OR A LES in OR B OR B NCS

Server

6.3.3 Communications Process Description


Data reports transmitted by the base station using one of the base station DNIDs are interpreted by
the server and translated to polls which are delivered to the mobiles using the corresponding DNID
via the appropriate LES. Information transmitted by an MES is mapped directly into a group poll
without being interpreted and transmitted to the base station using the corresponding DNID via the
appropriate LES. The base tracks the location of the MESs in the following way; after moving to a new
Ocean Region, an MES must indicate to the base station the Ocean Region in which it is operating,
using a mobile-base transaction using the new LES ID/ DNID combination. The base station updates
its mobile location database accordingly, and echoes a response to the mobile indicating that it has
received the information that the mobile has moved to the new region.

6.3.4 Support for Large Groups of Mobiles


Closed user groups with more than 255 mobiles can be supported by a variation of this service, where
multiple LES-ID /DNID pairs are provided for mobiles operating to the same LES. For each LES-ID/
DNID pair used for mobile communication, there is a corresponding DNID used for the base station.

6.4 Base Station Implementation


The architecture selected for implementation of the base station will depend mainly upon the
regularity of reports sent by the mobiles. For small populations of mobiles, where the reports are
either sent on a regular, but infrequent basis, or are only sent in response to a polling packet from the
mobile, the MES DCE at the base station can support both transmission of data reports and reception
of polling packets. If the base station needs to support the Inmarsat-C messaging protocol, then this
also has an implication, as the information is delivered to the base station using group polls and the
NCS does therefore not wait for the base station to be in an idle condition before delivering the polling
packet.

Volume 2: User Services, Part 2: Application Notes, Page: 17


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

For situations where a base station supports large or multiple groups of mobiles, or where the mobiles
are reporting frequently, it is more appropriate to implement the base station architecture using
separate MES DCEs for transmission and reception. This eliminates the risk of data reports from
mobiles being lost by the base station. The architecture of such a base station is illustrated in Figure
9.

Volume 2: User Services, Part 2: Application Notes, Page: 18


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 9: Base Station Architecture for Operation with Large Groups of Mobiles
Data Reports Polling Packets
to LES from NCS

Tx MES DCE Rx MES DCE

DTE

If this configuration is implemented, and the base station needs to support the Inmarsat-C messaging
protocol, then the transmit DCE should be used for this purpose to ensure that information transferred
from the mobiles is not lost.

6.5 Base Station MES DTE Application


The software within the Base station MES DTE provides facilities for formatting and controlling the
transmission of data reports, and for interpreting polling packets passed to the application by the
DCE.

6.5.1 DTE Architecture


The user’s application software uses the mobile-mobile protocol engine to initiate and monitor the
transfer of information to the remote mobile. The user’s application would be specific to the user’s
requirements, and could for instance contain a form driven user interface, an automated stock
monitoring facility, or a user-defined macro-encoded message interface. The mobile-mobile protocol
engine would interface with the DCE(s) used for transmission of data reports and reception of polling
packets.

6.5.2 Mobile-Mobile Protocol Engine


It may be necessary to support the concurrent operation of several polling processes for particular
user applications, and the mobile-mobile protocol engine software should accommodate this multi-
threading requirement. The function of the protocol engine software is to initiate data reports and to
monitor and interpret the polling packets that are received. Retransmission of data reports is
performed by the protocol engine if required by the application software, and the retransmission can
be based on the absence of a group poll constructed by the server and forwarded by the LES (in
which case the base station also needs to be a member of the mobile DNID), or on the absence of an
acknowledgement poll from the mobile within a specified timeout.

6.5.3 DNID and Member Number Management


The base station must perform several functions related to the DNID management for mobile-mobile
operation. Facilities for programming the mobiles with the respective DNIDs and member numbers
must be provided, and the mapping information should be stored in a database for reference when
communicating with a particular mobile. If the mobiles are operating via several ocean regions, then
the base station needs to track the location of the mobiles in order to maintain communications when
the mobiles move to a new Ocean Region.

6.5.4 MES DCE Interfaces

Volume 2: User Services, Part 2: Application Notes, Page: 19


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The base station would normally send polls and received data reports via a terrestrial line which is
connected to the LES. The use of the Inmarsat-C API simplifies the development of application
software and also has the benefit of improving the reusability of the code.

7 Generic Mobile-Mobile Communications

7.1 Overview
Mobile-mobile reporting supports the concept of generic mobile-mobile. For satisfactory operation of
this service, mobile-mobile reporting specific software is required in the DTE of each mobile within the
group. The information is not interpreted by the server at the LES, but is mapped into a group poll
using the same LES-ID/ DNID pair for transmission as for reception.

7.2 Single Ocean Region Operation

7.2.1 Setting up the Server


The service is provided by setting up a single LES-ID/DNID pair for base-mobile communications and
a single LES-ID pair for mobile-mobile communications within the server database for the customer.
The Inmarsat Mobile Number for the base station is also programmed into the database of the server.
For the first LES-ID/DNID pair, the server is told to interpret the data reports, and if the base station
can support the facility, usually the server will be instructed that multiple packet data reports from the
base station will be protected with an internal single byte checksum. For the second LES-ID/DNID
pair, the server is told not to interpret the contents of the data report, and usually no checksum will be
present.

7.2.2 Configuring the Mobiles


The service provider instructs the LES to transmit a poll to the base station programming it with the
LES-ID / DNID and member number it will use for communication. The customer can then use the
standard programming poll functions to firstly place the base station within the mobile closed user
group used for mobile-mobile operation, and then each of the other mobiles within the closed user
group.

7.2.3 Communications Process Description


After the initial configuration the base station does not perform a function in the communications
process. Information transmitted by the mobiles using the mobile-mobile DNID are mapped directly
into a group poll without being interpreted and are transmitted to all mobiles within the group using the
mobile-mobile DNID. The base station can be used to monitor and log all calls if necessary.

Figure 10 illustrates the format of the data report when used for generic mobile to mobile reporting,
where the destination member number and category/ extended category fields are optional.

Volume 2: User Services, Part 2: Application Notes, Page: 20


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 10: Example Data Report Format for Generic Mobile-Mobile Reporting

Bit No. Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
1 P C Type 1 P C Type 1 P C Type
2 2 2
DNID
3 3 3
4 LES ID 4 4
5 Source Member No. 5 5
6 Cat. Extended Cat. 6 6
7 Dest. Member No. 7 Data 7 Data
Byte

Byte

Byte
8 8 8
9 9 9
10 Data 10 10
11 11 11
12 12 12
13 13 13 (DataField-Checksum)
14 14 14
CRC CRC CRC
15 15 15
Data Report Packet for general First Continuation Packet Second Continuation Packet
Mobile-mobile data delivery (Optional) (Optional)

The optional category and extended category fields, shown in the above example, may be used by
the application to distinguish between different services which are operating, for example to indicate
that a single destination member number is included. The group poll would then have the following
format (see Figure 11):

Figure 11: Example Group Poll Format for Generic Mobile-Mobile Reporting

Bit No.
8 7 6 5 4 3 2 1

1 P Type
2
Length
3
4
DNID
5
6 LES ID
7
LES TDM
Byte

8
9 Sub-Address
10 Randomising Interval
11 Resp Spare
12 Command
13 Sequence No.
14 Source Member No.
15 Cat. Extended Cat.
16 Dest. Member No.

Text/ Data

CRC

All of the DCEs within the group accept the poll and pass this to the DTE, where the mobile-mobile
specific software will check the destination member number and process the packet if applicable.
Other service variations are possible, such as multiple mobile addressing, and it is to base a
retransmission scheme upon observation of the contents of the forwarded polling packet by the

Volume 2: User Services, Part 2: Application Notes, Page: 21


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

source mobile. This latter service variation is particularly valuable when the source mobile is
stationary, such as is the case with a base station terminal.

7.3 Multiple Ocean Region Operation


Generic mobile-mobile communications across multiple Ocean Region operation is not straight-
forward. The main difficulty is that the mobiles themselves, because they are operating in blocked
channels, will not receive every poll transmitted. When a mobile moves between ocean regions, it
could broadcast to all mobiles its new status, and those mobiles could then redirect the information
appropriately. However, those mobiles which have not received the redirection poll will be unable to
communicate with the mobile which has moved to the new Ocean Region. One way this can be
resolved is to use the base station as a router, either redirecting all calls to a the appropriate LES, or
only those which are mis-directed. An alternative is to send the information in both Ocean Regions.
Both mechanisms are expensive to operate and require a large number of LES-ID / DNID pairs to be
set up at the server, and are therefore not generally recommended.

8 References
[1] CCITT Blue Book: Volume VIII.6. Data Communication Networks; Inter-Working Between
Networks: Recommendation X.300.

Volume 2: User Services, Part 2: Application Notes, Page: 22


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 12: LES Server SDL, Mobile-Mobile Reporting, Sheet 1 of 4

1.
IDLE

Data
Report LES interface

Get Source_
DNID from
Data Report
In : Source_DNID
Get Dest_ Out: Dest_DNID
DNID from Interpret_D
Database Validate_D
DNID_Valid

No DNID_Valid
== True?
Store
Data Report
Yes

Generate Validate_D No
Console
Error Report == True ?

Yes
Accumulate In: Result = Fail
Statisitcs
Validate
Out: Result
Data Field
1.

No Result
= Ok ?
Store
Data Report Yes

Generate Interpret_D No
Console
Error Report == True ?

Accumulate Yes In: Data_Field


In: Result = Fail Type =Group
Statisitcs Out: Type Seq No = None
Extract Poll fields Seq No Set Default
Command = 10H
from Data Report Command Poll fields
Response = 0
1. Response Sub-Addr = 0
Sub-Addr Poll Data =
Poll Data =
Source Member
Remaining Data
+ Data_Field

In: Type
Les ID
Dest_DNID
Send Seq No
Poll Command
Response
Sub-Addr
Poll Data
Accumulate Out: Result
In: Result
Stats LES Server SDL
Mobile-mobile reporting
Sheet 1 of 4
1. 14 March 1995
Issue 1

Volume 2: User Services, Part 2: Application Notes, Page: 23


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 12: LES Server SDL, Mobile-Mobile Reporting, Sheet 2 of 4

In : Source DNID
Get DNID Out: Dest_DNID
from databse Interpret_D
Validate_D
DNID_Valid

n = 0;

n == Total Yes
DNIDS?

No
DNID_Valid
= False
DB[n].DNID Yes
== Source_
DNID?
Dest_DNID = DB[n].Dest_DNID
No Set Values Validate_D = DB[n].Validate_D
Interpret_D = DB[n].Interpret_D
n++;

DNID - Valid
= True;

Validate Out: Results


Data_Field In : Data [ ]
Datalen

No
Data_length
>8?

Yes
Result = Ok

Count = 0;
Sum = 0;

Count Yes
== Data_length
- 1?

No Sum = No
Data [Count]
Sum = |Sum +
?
Data [Count]|256
Yes
Result = Fail
Result = Ok
Count ++;

LES Server SDL


Mobile-mobile
reporting
Sheet 2 of 4
14 March 1995
Issue 1

Volume 2: User Services, Part 2: Application Notes, Page: 24


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 12: LES Server SDL, Mobile-Mobile Reporting, Sheet 3 of 4

In: Data_Field
Extract Poll Out: Type
fields from Seq No
Data report Command
Response
Sub-Addr

Data_field.Cat No
==individual
?
Yes
Get MRN
from
Data_Field

Type =
Individual

Sub_Addr No
specified?

Yes Sub Addr


=0
Get Sub_Addr
from Data_Field

Command
specified?

Command
=9
Get Command
from Data_Field

Seq_No
specified?

Seq_No
= None
Get Seq_No
from Data_Field

Response
specified?

Response
Get Response =0
from Data_Field LES Server SDL
Mobile-mobile reporting
Sheet 3 of 4
14 March 1995
Issue 1

Volume 2: User Services, Part 2: Application Notes, Page: 25


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 12: LES Server SDL, Mobile-Mobile Reporting, Sheet 4 of 4

In: Type
LES ID
Seq_No
Send Command
Poll Response
Sub_Addr
Poll_Data[]
Out: Result

Type == No
Group?

Yes Format
Individual
Format
Poll
Group
Poll

Get LES
location from LES_ID
database

Remote No
LES
?

Yes Send Poll Local LES

Get LES LES_ID


number

Result Local LES

Send Poll Remote LES

Update
Records
Result Remote LES

Update
Records

LES Server SDL


Mobile-mobile reporting
Sheet 4 of 4
14 March 1995
Issue 1

Volume 2: User Services, Part 2: Application Notes, Page: 26


Application Note 4: Guide To Development of a Mobile To Mobile Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 1: CMC Extensions

Contents

Preface ........................................................................................ 8

Trade Marks ................................................................................. 8

Referenced Documents ................................................................ 8

Abbreviations .............................................................................. 8

Glossary Of Terms ..................................................................... 10

1 Introduction .......................................................................... 11

2 Application Programming Interface ....................................... 12


2.1 Issues Affecting Application Developers ......................................................... 12
2.2 Hiding Interface Differences and Complexity .................................................. 12
Figure 1: Applications Using the Inmarsat-C API .................................................. 13
2.3 Common Messaging Call API ......................................................................... 13

3 Mapping CMC onto Inmarsat-C .............................................. 14


3.1 Introduction ..................................................................................................... 14
3.2 CMC Messages and Attachments ................................................................... 14
3.2.1 General ........................................................................................................ 14
3.2.2 Inmarsat-C EGC and Messaging ................................................................. 15
3.2.3 Data Reporting and Polling .......................................................................... 16
3.2.4 Land Mobile Alerting .................................................................................... 17
3.2.5 Message Transfer Reports........................................................................... 17
3.2.6 Delivery and Non-Delivery Reports .............................................................. 18
3.2.7 Receipt and Non-Receipt Reports................................................................ 23
3.2.8 EGC Cancellation Message ............................................................................ 24
3.2.9 Protocol Indications and Alarms ................................................................... 24
3.2.10 Errors ......................................................................................................... 25

Volume 2: User Services, Part 3: CMC Extensions, Page: 1


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.3 Addressing of CMC Messages ........................................................................ 25


3.3.1 General Addressing of Messages ................................................................ 25
3.3.2 Inmarsat-C Messaging ................................................................................ 26
3.3.3 Telex, Public Switched Packet Data Network (X.25), Public Switched
Telephone Network (Voice-Band Modem), Facsimile (FAX) and Special Access
Code Messaging ...................................................................................................... 30
3.3.4 Data Reporting, Polling, and DNID Message Addressing ............................ 31
3.3.4.1 Sending a Poll ...................................................................................................................... 34

3.3.4.2 Receiving a Poll ................................................................................................................... 36

3.3.4.3 Sending a Data Report or a From-Mobile DNID Message .................................................. 37

3.3.4.4 Receiving a Data Report or a From-Mobile DNID Message................................................ 38

3.3.4.5 Mobile to Mobile Reporting .................................................................................................. 39

3.3.5 Enhanced Group Calls ................................................................................ 40


3.3.5.1 Sending an Enhanced Group Call ....................................................................................... 42

3.3.5.2 Receiving an Enhanced Group Call ..................................................................................... 43

3.3.6 Land Mobile Alerting .................................................................................... 43


3.3.7 X.400 Messaging ......................................................................................... 46
3.3.8 Message Transfer Reports........................................................................... 46
3.3.8.1 Receiving a Message Transfer Report ................................................................................ 46

3.3.9 Delivery and Non-delivery Reports............................................................... 46


3.3.10 Receipt and Non-Receipt Reports.............................................................. 46
3.3.11 Protocol Indications and Alarms ................................................................. 46
3.3.12 Errors ......................................................................................................... 46
3.4 Message Types .............................................................................................. 48
3.5 Message Subject ........................................................................................... 49
3.5.1 Inmarsat-C Messages .................................................................................. 49
3.5.2 Inmarsat-C EGCs ......................................................................................... 49
3.5.3 Receiving Data Reports ............................................................................... 49
3.5.4 Receiving Polls............................................................................................. 49
3.5.5 Land Mobile Alerts ....................................................................................... 50
3.5.6 Message Transfer Reports........................................................................... 50
3.5.7 Delivery Reports........................................................................................... 50
Volume 2: User Services, Part 3: CMC Extensions, Page: 2
Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.5.8 Receipt Reports ........................................................................................... 51


3.6 Message Reference Numbers ........................................................................ 51
3.7 Address Book ................................................................................................. 51
3.8 Off-Line Working ............................................................................................ 51

4 CMC Extensions .................................................................... 52


4.1 Introduction ..................................................................................................... 52
4.2 Additional Data Types ..................................................................................... 52
4.2.1 CMC_X_IMS_channel_number................................................................... 52
4.2.2 CMC_X_IMS_geographical_coordinates .................................................... 52
4.2.3 CMC_X_IMS_keyword_value_pair_list ....................................................... 53
4.2.4 CMC_X_IMS_land_mobile_alert .................................................................. 53
4.2.5 CMC_X_IMS_mes_number ........................................................................ 54
4.2.6 CMC_X_IMS_message_transfer_report ..................................................... 55
4.2.7 CMC_X_IMS_ncs_information .................................................................... 56
4.2.8 CMC_X_IMS_network_id ............................................................................ 56
4.2.9 CMC_X_IMS_network_information .............................................................. 57
4.2.10 CMC_X_IMS_pvt_result ............................................................................. 57
4.2.11 CMC_X_IMS_station_id ............................................................................. 58
4.2.12 CMC_X_IMS_timestamped_geographical_coordinates ............................. 58
4.3 Additional Functions ........................................................................................ 58
4.3.1 X_Set_Configuration....................................................................................... 58
4.4 Extension Sets ................................................................................................ 60
4.4.1 General Extensions (CMC_XS_IMS_GEN) ................................................. 60
4.4.1.1 CMC_X_IMS_GEN_HEADERS ........................................................................................... 60

4.4.1.2 CMC_X_IMS_GEN_IP_REFERENCE ................................................................................ 61

4.4.1.3 CMC_X_IMS_GEN_LAND_MOBILE_ALERT_DATA ......................................................... 61

4.4.1.4 CMC_X_IMS_GEN_LES_ID ................................................................................................ 62

4.4.1.5 CMC_X_IMS_GEN_MESSAGE_HEADERS ....................................................................... 63

4.4.1.6 CMC_X_IMS_GEN_MESSAGE_TRANSFER_REPORT .................................................... 64

4.4.1.7 CMC_X_IMS_GEN_MSG_RECEIVED ............................................................................... 65

Volume 2: User Services, Part 3: CMC Extensions, Page: 3


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.4.1.8 CMC_X_IMS_GEN_MSG_STATUS_ENQUIRY ................................................................. 66

4.4.1.9 CMC_X_IMS_GEN_PRESENTATION ................................................................................ 66

4.4.1.10 CMC_X_IMS_GEN_PRIORITY ......................................................................................... 67

4.4.1.11 CMC_X_IMS_GEN_REQUEST_DELIVERY_REPORT.................................................... 68

4.4.1.12 CMC_X_IMS_GEN_REQUEST_MESSAGE_TRANSFER_REPORT .............................. 69

4.4.1.13 CMC_X_IMS_GEN_REQUEST_RECEIPT_REPORT ...................................................... 70

4.4.1.14 CMC_X_IMS_GEN_REQUEST_REPLY ........................................................................... 71

4.4.1.15 CMC_X_IMS_GEN_YOUR_IP_REFERENCE .................................................................. 71

4.4.2 MES Extensions (CMC_XS_IMS_MES) ......................................................... 72


4.4.2.1 CMC_X_IMS_MES_ABORT_CURRENT_OPERATION ..................................................... 72

4.4.2.2 CMC_X_IMS_MES_AVAILABLE_MES_MEMORY............................................................. 73

4.4.2.3 CMC_X_IMS_MES_BB_ERROR_RATE ............................................................................. 73

4.4.2.4 CMC_X_IMS_MES_CLEAR_WAITING_MESSAGES ........................................................ 74

4.4.2.5 CMC_X_IMS_MES_CURRENT_ACTIVITY ........................................................................ 74

4.4.2.6 CMC_X_IMS_MES_CURRENT_CHANNEL ....................................................................... 75

4.4.2.7 CMC_X_IMS_MES_CURRENT_FRAME_NUMBER .......................................................... 76

4.4.2.8 CMC_X_IMS_MES_CURRENT_NCS ................................................................................. 77

4.4.2.9 CMC_X_IMS_MES_ENID_LIST .......................................................................................... 78

4.4.2.10 CMC_X_IMS_MES_ENID_MGMT..................................................................................... 78

4.4.2.11 CMC_X_IMS_MES_GEOGRAPHICAL_COORDINATES................................................. 79

4.4.2.12 CMC_X_IMS_MES_LOGIN_FLAG ................................................................................... 80

4.4.2.13 CMC_X_IMS_MES_MESSAGE_TRANSFER_STATUS .................................................. 80

4.4.2.14 CMC_X_IMS_MES_NAV_EQUIPMENT ........................................................................... 81

4.4.2.15 CMC_X_IMS_MES_NCS_TDM_CHANNEL_LIST ............................................................ 82

4.4.2.16 CMC_X_IMS_MES_NCS_TDM_CHANNEL_MGMT ........................................................ 82

4.4.2.17 CMC_X_IMS_MES_NETWORK_INFORMATION ............................................................ 83

4.4.2.18 CMC_X_IMS_MES_PREFERRED_NCS .......................................................................... 84

4.4.2.19 CMC_X_IMS_MES_PRINTER_MANAGEMENT .............................................................. 85

4.4.2.20 CMC_X_IMS_MES_PVT_REPORT .................................................................................. 86

4.4.2.21 CMC_X_IMS_MES_PVT_TEST ........................................................................................ 86

4.4.2.22 CMC_X_IMS_MES_SCAN ................................................................................................ 87

4.4.2.23 CMC_X_IMS_MES_SIGNAL_STRENGTH ....................................................................... 87

4.4.3 Data Reporting and Polling Extensions (CMC_XS_IMS_DRP) .................... 88

Volume 2: User Services, Part 3: CMC Extensions, Page: 4


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.4.3.1 CMC_X_IMS_DRP_DNID_LIST .......................................................................................... 88

4.4.3.2 CMC_X_IMS_DRP_DNID_MGMT ...................................................................................... 89

4.5 MES CMC API Implementation Profiles .......................................................... 90


4.5.1 Simple MES ................................................................................................. 90
4.5.2 MES with DRP Support ................................................................................ 90
4.6 Terrestrial CMC API Implementation Profiles .................................................. 90
4.6.1 General ........................................................................................................ 90
4.6.2 X.25 Terrestrial Station ................................................................................ 90
4.6.3 PSTN Terrestrial Station .............................................................................. 91
4.7 Suggested User Configurable Defaults ........................................................... 91
4.7.1 “From” Address ............................................................................................ 91
4.7.2 Presentation Code for Text Only Messages................................................. 91
4.7.3 LES(s) .......................................................................................................... 91
4.7.4 Message Header Keywords ......................................................................... 91
4.7.5 Port Configuration ........................................................................................ 91
4.7.6 LES Access Numbers, Accounts and Passwords ........................................ 91
4.8 Suggested User Interface Functions ............................................................... 91
4.8.1 MES Status Information ............................................................................... 92
4.8.2 CMC Implementation Configuration ............................................................. 92
4.8.3 Message Status Enquiry .............................................................................. 92
4.8.4 EGC Cancellation......................................................................................... 92
4.9 C-Declaration Summaries ............................................................................... 92

5 Inmarsat-C Message Headers................................................. 97


5.1 Introduction ..................................................................................................... 97
5.2 Headers and Inmarsat-C ................................................................................. 97
5.3 Syntax ............................................................................................................. 97
5.3.1 Formal Structure .......................................................................................... 97
5.3.2 General Rules .............................................................................................. 98
5.4 Keywords, Parameters, and Abbreviations ..................................................... 99
5.4.1 Addressing Syntax ..................................................................................... 102

Volume 2: User Services, Part 3: CMC Extensions, Page: 5


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

5.4.2 Attachments (ATTACH) ............................................................................. 104


5.4.3 Content and Body Types............................................................................ 104
5.4.3.1 Interpersonal Messages..................................................................................................... 104

5.4.3.2 Receipt and Non-Receipt Notifications .............................................................................. 105

5.4.3.3 Other Content Types .......................................................................................................... 105

5.4.4 Delivery Times ........................................................................................... 105


5.4.5 Importance Indication (IMPORTANCE)...................................................... 106
5.4.6 Encryption (Body Part) (ENCRYPTION) .................................................... 106
5.4.7 Forward Indication (FORWARD) ................................................................ 106
5.4.8 Sensitivity Indication (SENSITIVITY) ......................................................... 106
5.4.9 IP-Reference Numbers .............................................................................. 106
5.5 Delivery, Receipt and Reply Requests .......................................................... 107
5.5.1 Delivery Report Requests .......................................................................... 107
5.5.2 Receipt Report Requests ........................................................................... 107
5.5.3 Reply Requests .......................................................................................... 107

6 Examples ............................................................................ 108


6.1 Discussion of Examples from the CMC Specification.................................... 108
6.1.1 Query Configuration, Logon and Logoff Example ...................................... 108
6.1.2 Send and Send Documents Functions Example ........................................ 108
6.1.3 List, Read, and Delete the First Unread Message Example ....................... 109
6.1.4 Lookup a Specific Recipient and Get its Details Example .......................... 109
6.1.5 Use of Extensions Example ....................................................................... 109
6.2 Examples Using Inmarsat-C Extensions ....................................................... 109
6.2.1 cmc_logon() with Inmarsat-C Extensions ................................................... 109
6.2.2 MES logon to the IOR ................................................................................ 110
6.2.3 Using CMC to Send a Message with no API Header ................................. 111
6.2.4 Sending a Data Report............................................................................... 111
6.2.5 Receiving a Data Report ............................................................................ 112
6.2.6 Sending a Poll ............................................................................................ 112
6.2.7 Receiving a Poll ......................................................................................... 113

Volume 2: User Services, Part 3: CMC Extensions, Page: 6


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6.2.8. Sending a Land Mobile Alert ..................................................................... 114


Appendix 1: Elements of Service ........................................................................ 116
1 Descriptions ..................................................................................................... 127
Appendix 2: An Introduction to Inmarsat-C ......................................................... 131
1 The Inmarsat Communications System ........................................................... 131
1.1 Space Element ......................................................................................................................... 131

1.2 Network Co-ordination Station ................................................................................................. 132

1.3 Land Earth Station ................................................................................................................... 132

1.4 Mobile Earth Station ................................................................................................................. 132

2 Inmarsat-C Services......................................................................................... 132


2.1 Store and Forward Data and Messaging ................................................................................. 133

2.2 Distress Alerting ....................................................................................................................... 133

2.3 Enhanced Group Calls (EGC).................................................................................................. 134

2.4 Data Reporting ......................................................................................................................... 134

2.5 Polling....................................................................................................................................... 135

2.6 Mobile to Mobile Reporting ...................................................................................................... 135

Volume 2: User Services, Part 3: CMC Extensions, Page: 7


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Preface
This document describes a set of extensions to the CMC (Common Messaging Call) API to enable
application programmers to easily integrate the messaging and data services provided by Inmarsat's
global mobile communications system, Inmarsat-C.

The content of this specification has been developed in collaboration with Inmarsat business partners.
The specification is maintained by Inmarsat on behalf of its business partners. Any comments relating
to the material contained in this document may be submitted to Inmarsat.

This document is intended for application developers, and manufacturers of Inmarsat-C satellite
communication equipment and network service providers who might wish to support CMC. The
header structure defined in this document may also benefit application developers or users wishing to
send and receive messages over Inmarsat-C independent of the CMC API.

Trade Marks
Inmarsat is a trade mark of Inmarsat

Referenced Documents
This section identifies other documents on which this document relies:

[1] Common Message Call API Version 1.0, 1993, X.400 API Association.

[2] Inmarsat-C System Definition Manual Release 2.0, Volumes 1 - 5.

[3] Inmarsat-C/Basic X.400 Interworking Specification, Inmarsat-C System Definition Manual


Release 2.0, Volume 3, Part 1, Chapter 4.

[4] Guide to Development of a Mobile to Mobile Reporting Service, Inmarsat-C System Definition
Manual Release 2.0, Volume 2, Part 2, Application Note 4.

Abbreviations
ACK Acknowledgement

ADMD Administration Management Domain

API Application Programming Interface

ASCII American Standard Code for Information Interchange

CCITT Comite Consultatif International Telegraphique et Telephonique

CMC Common Messaging Call

DCE Data Circuit Terminating Equipment

DNID Data Closed Network Identity

DTE Data Terminal Equipment

EGC Enhanced Group Call

Volume 2: User Services, Part 3: CMC Extensions, Page: 8


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ENID EGC Closed Network Identity

GMDSS Global Maritime Distress and Safety System

IA5 International Alphabet No. 5

IM Interpersonal Messaging

IPM Interpersonal Message

INMARSAT International Maritime Satellite Organisation

ITA2 International Telegraph Alphabet No. 2

LES Land Earth Station

MES Mobile Earth Station

MHS Message Handling System

MS Message Store

MT Message Transfer

MTA Message Transfer Agent

NCS Network Co-ordination Station

NOC Network Operation Centre

O/R Originator/Recipient

PSPDN Packet Switched Public Data Network

PSS Packet Switched Service

PSTN Packet Switched Telephone Network

RCC (Maritime) Rescue Co-ordination Centre

SCADA Supervisory Control and Data Acquisition

SCC Satellite Control Centre

SDM System Definition Manual

SES Ship Earth Station

TDM Time Division Multiplex

UA User Agent

UI User Interface

XAPIA X.400 Application Program Interface Association

XMHS API X/Open Application Program Interface to Electronic Mail (X.400)

XMS API X/Open Message Store Application Program Interface

Volume 2: User Services, Part 3: CMC Extensions, Page: 9


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

XOM API X/Open OSI - Abstract Data Manipulation Application Program Interface

Glossary Of Terms
Application

The computer software program, or programs, designed for a specific task.

Application Programming Interface (API)

A set of functions and/or procedures used by an application to access particular services provided by
another program(s) or operating system.

Data Circuit Terminating Equipment (DCE)

Equipment located at either end of a data circuit providing all the functions necessary to establish,
maintain and terminate a connection. The equipment also carries out all signal conversion and
coding between the DTE and the link.

Data Reporting

A short data packet transmitted in burst mode on the signalling channel as a result of a polling
command or at the initiative of the MES application or operator.

Data Terminal Equipment (DTE)

Equipment at which a communication path begins or ends - for example, a keyboard and display or
teletype.

Distress Alert

A data reporting type packet transmitted to an NCS or LES on a signalling channel by an MES in a
maritime distress situation.

Distress Priority Message

A message sent within the system having a distress priority. Generally for communication with
RCC's.

From Mobile

The inbound calling direction. Also called Ship to Shore in maritime technology.

Land Earth Station (LES)

Also Coast Earth Station (CES). An LES/CES provides the gateway between the Inmarsat mobile
network and the terrestrial networks. All calls, including Mobile-to-Mobile calls, are made through the
LES.

Mobile Earth Station (MES)

The term Mobile Earth Station refers to the Inmarsat-C mobile user terminal consisting of a DCE and
DTE, whether maritime or land based.

Network Co-ordination Station (NCS)

Volume 2: User Services, Part 3: CMC Extensions, Page: 10


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The Network Co-ordination Station provides network managerial functions in each satellite ocean
region. NCS's also transmit EGC messages on the NCS common channel.

Originator

The party initiating communications.

Packet

A self contained component of a message, comprising address, control and data signals, that can be
transferred as an entity within a data network.

Polling

An Inmarsat-C satellite service whereby selected groups of MESs are interrogated. The selected
MESs respond in a predetermined manner, either with a data reporting message or by initiating a
mobile-to-ground message transfer.

Protocol

The rules for communication system operators which must be followed if communication is to be
possible. The complete interaction of all possible series of messages across an interface.

Signalling Channel

Random access TDMA channel used for signalling and data reporting in the From-Mobile direction.

System Message (EGC)

An EGC message type defined for supporting system operations. System messages are transmitted
only by LES operator, NCS operators and the Inmarsat NOC.

To Mobile

The outbound calling direction. Also called Shore to Ship in maritime terminology.

Type Acceptance

The process of acceptance of MES models by National Licensing Authorities.

Type Approval

Approval by Inmarsat of an MES model as a design suitable for use in Inmarsat system after
satisfactory completion of tests which demonstrate that the design meets Inmarsat requirements.

1 Introduction
Common Messaging Call (CMC) API defines a standard programming interface for applications to
access services supported by most messaging systems, but it also provides the capability to extend
the interface to support additional messaging features. This document defines a set of extensions to
version 1.0 of the CMC API [1] to provide support for the full range of Inmarsat-C services (excluding
certain maritime safety related services) and also specifies how particular CMC API features should
be implemented using Inmarsat-C. Inmarsat-C is one of a variety of services available using Inmarsat
satellites and provides mobile store and forward messaging and data services.

Appendix 2 contains a brief introduction to Inmarsat-C.

Volume 2: User Services, Part 3: CMC Extensions, Page: 11


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2 Application Programming Interface

2.1 Issues Affecting Application Developers


An application developer may wish to write applications that use Inmarsat-C services. The developer
will want to do this in a way that:

a) minimises development cost

b) minimises the knowledge required of the Inmarsat-C system

c) maximises the robustness of the application

d) offers the greatest degree of flexibility in terms of the MES equipment and LESs that can be
used

There are many different manufacturers who provide LES and MES equipment, and, whilst the
Inmarsat-C protocols are standard and allow communication between all LES and MES types, the
interfaces available to application developers for connection to and from MESs and LESs differ. The
result is that application developers writing programs that use the MES and LES defined external
protocols have to support many such protocols if they wish the program to be able to use many
different MESs and LESs. The external protocols can be complex and writing applications for many
considerably adds to the cost.

The MES external protocols for application developers are also at a low level and may require the
developer to consider some low level aspects of the Inmarsat-C network, such as the Inmarsat-C
login function. Whilst wishing to have access to these functions when required, the necessity of using
these in some cases adds to the cost of otherwise simple applications, both because of the additional
programming required and also the knowledge of the Inmarsat-C system that the developer must
acquire.

2.2 Hiding Interface Differences and Complexity


An application programming interface hides complexity from the application developer and allows
many different types of underlying equipment and systems to be used in the same way. Figure 1
illustrates the place of the application programming interface in a typical Inmarsat-C application.

Volume 2: User Services, Part 3: CMC Extensions, Page: 12


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: Applications Using the Inmarsat-C API

User System
(MES DTE) DCE LES User System

Application Application

Application Application

Inmarsat-C
Network API
API

Transport Transport
Service Service
Provider Provider

Terrestrial
Network

Appropriate transport service providers can be used by application developers who are now no longer
required to know the details of particular equipment interfaces and instead have a single programming
interface independent of MES or LES type.

2.3 Common Messaging Call API


The recommended standard API for Inmarsat-C is the Common Messaging Call (CMC) API version
1.0 [1] with the Inmarsat-C extensions. Adopting a standard API enables all "off-the-shelf"
applications written to use this API to access the Inmarsat-C network, and providing extensions to the
standard API allows an application developer access to functions that are specific to Inmarsat-C.

The CMC API is a set of 10 functions with supporting data type definitions. Using the API to send a
message, with attachments if required, is very simple requiring just a single program call.

CMC is a standard messaging API and therefore makes certain assumptions on the functionality, or
service elements, of the underlying messaging system. Where the standard service elements
assumed by CMC exceed the functionality of the normal Inmarsat-C store and forward messaging
service, this document recommends how the service elements should be supported over the
Inmarsat-C system. Examples of such service elements are message subject and message
attachments. The additional service elements are supported by adding a header to the start of a
message which can then be understood by an application at the destination.

This document also covers addressing formats for all Inmarsat-C services (excluding maritime
distress which is not supported through the API), reporting of Inmarsat-C errors and failure codes via
CMC, and provision of additional service elements not described in CMC version 1.0. Various
recommendations on the functionality that should or can be provided by CMC API implementations for
Inmarsat-C are also made.

Some applications developers will find it sufficient to use the CMC API calls without the extensions but
almost all Inmarsat-C services and capabilities can be accessed through the API if required. Where
no API implementation exists for the platform the developer is using, he/she may still find the defined

Volume 2: User Services, Part 3: CMC Extensions, Page: 13


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

header formats useful as a standard way of carrying common service elements over Inmarsat-C.
Adoption of the header will enable future inter-working with applications developed using the API.

3 Mapping CMC onto Inmarsat-C

3.1 Introduction
This chapter describes how the CMC functions relate to the Inmarsat-C services. Details of CMC
extensions for Inmarsat-C are given in Chapter 4. The Chapter is primarily concerned with specifying
how some aspects included in the CMC specification should be mapped onto Inmarsat-C.
Consideration has been given to the following:

a) The implementation of CMC for Inmarsat-C services must not require applications that use
CMC for messaging to know Inmarsat-C. "Off-the-shelf" messaging applications that use CMC
should be able to use Inmarsat-C services and function without change.

b) The CMC implementation should conform to the CMC specification with defined extensions.

c) The CMC implementation for Inmarsat-C should be capable of supporting all the service
elements given in the Appendix.

d) The specification should be "tight" enough to enable an application that uses CMC to access
Inmarsat-C services to be used with a variety of Inmarsat-C equipment and API
implementations without change.

3.2 CMC Messages and Attachments

3.2.1 General
CMC provides an interface for sending and receiving messages. Messages can optionally have one
or more attachments and can be multiply addressed.

Inmarsat-C messages, data reports, polls, enhanced group calls (EGCs) and land mobile alerts are all
regarded as being messages in the CMC sense. Although some data relating to a particular
Inmarsat-C service may be held in extension structures, the intention is to allow the main data sent
with a service to be carried in the body of the message and therefore available to the widest range of
applications. The CMC API implementations can also (optionally) generate Message Transfer
Reports which are also messages in a CMC sense. Message Transfer Reports include information
on the successful transfer of messages to the LES and should not be confused with delivery reports.

The CMC message structure contains a text note (which may be zero bytes in length) and can contain
one or more attachments. When sending a message, the text note in the message structure (and
attachments of type CMC_ATT_OID_TEXT) should have the appropriate line terminator for the
platform (CR, LF, CR/LF). Applications can expect the correct line termination when reading a
message text note (see Common Messaging Call API Section 3.9). Attachments of any type other
than CMC_ATT_OID_TEXT are sent as is, and neither the Inmarsat-C system nor the CMC API
implementation shall make any changes to the data.

Each Inmarsat-C message and EGC has a presentation code which affects both the addressing and
the encoding of messages over the Inmarsat-C network. In general, the appropriate presentation
code is chosen by the CMC implementation and hidden from the user. This section and subsections
include the presentation code mapping that a CMC implementation performs both on sending and
receiving Inmarsat-C messages and EGCs. Inmarsat-C messages (From-Mobile to addresses other
than X.400, and To-Mobile) with purely text content may use one of three presentation codes: IA5,
ITA2 and Data. The ITA2 presentation code results in smaller, and therefore probably cheaper,
messages, but support from LESs and MESs for the ITA2 presentation code is not guaranteed and
the character set is smaller than that used for IA5. The conversion between text messages in ASCII,

Volume 2: User Services, Part 3: CMC Extensions, Page: 14


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

contained in the CMC message, and ITA2 for transmission over Inmarsat-C is a CMC implementation
matter. It is recommended that a CMC implementation for Inmarsat-C has a default presentation
code (of IA5, ITA2, or Data) to be used when sending messages with text only content. The default
may be on a per CMC user basis and can be overridden using CMC extensions.

Inmarsat-C EGCs and messages may have a Basic X.400 or Inmarsat-C Message Header added to
their start. The two headers are very similar so CMC API implementations should support the sending
and receiving of Basic X.400 messages. Basic X.400 headers are defined in the Basic
X.400/Inmarsat-C Interworking specification (Volume 03, Part 01, Chapter 05) and Inmarsat-C
Message Headers are defined in Section 5 of this document. Inmarsat-C EGCs and messages
received without an API or Basic X.400 header will generate a text note (with the appropriate end of
line termination) if the presentation code is ITA2 or IA5, but messages with a Data presentation code
shall be presented to the application with a NULL text note and the data in the first attachment.
Messages received with an API or Basic X.400 header shall only put the first, or only, body part in the
text note if the body is of type IA5; other body types1 must result in the data being left unchanged and
are therefore stored as the first attachment. The Inmarsat-C Message or Basic X.400 header may
determine what is to be included in the text note and what is to be included in attachments. Any LES
header at the start of the message (preceding the Inmarsat-C Message Header) may contain useful
information and should be included at the start of the text note.

Any application with a requirement to send data without changes may do so by one of the following:

1 A NULL text note, the data to be transferred in the first attachment, and a Data Reporting
(From-Mobile), Polling (To-Mobile) or Land Mobile Alerting (From-Mobile) address. The Data
Reporting, Polling and Land Mobile Alerting protocol can only transfer relatively small
amounts of data (see sections below for details).

2 A message attachment with a message type other than CMC_ATT_OID_TEXT,


and
one of the following address types:
DNID: (with the PROTOCOL=MESSAGE keyword and value), EGC:, INMC:, PSPDN:,
PSTN:, SAC:, or X400:,
and
Inmarsat-C Headers enabled.

3.2.2 Inmarsat-C EGC and Messaging


This section applies to CMC messages that are sent and received using the Inmarsat-C messaging or
EGC protocols. This includes messages sent from an MES to a DNID address, and with either the
PROTOCOL=MESSAGE keyword and value in the address line or greater than 32 bytes of user data to
send.

The presentation code that the CMC implementation shall use when sending Inmarsat-C EGCs and
messages is dependent on the data to be sent and the message address. The following rules apply:

1 The first body part is considered binary if:


( the message is a Basic X.400 message and
( CONTENTTYPE: is present and does not have a value of IPM84 or IPM88 or
EIT: is present and has a value other than IA5 or
BODYTYPE: is present and has a value other than IA5
)
) or
( the message is not a Basic X.400 message and
the received presentation code was Data and
ATTACH: is not present
)

Volume 2: User Services, Part 3: CMC Extensions, Page: 15


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 X.400 addresses shall be sent with the Basic X.400 presentation code.

2 If the address or addresses are not X.400 and one or more attachments exist with a message
type other than CMC_ATT_OID_TEXT, the presentation code of the EGC(s) or message(s)
shall be Data.

3 If the address or addresses are not X.400 and, either, no attachments are present, or all
attachments have a message type of CMC_ATT_OID_TEXT, then the presentation code of the
EGC(s) or message(s) shall be determined by the CMC_X_IMS_GEN_PRESENTATION
extension or set to the default presentation code for messages with purely text content (one of
ITA2, IA5 or Data).

CMC text notes and attachments are packaged together into a single Inmarsat-C EGC or message by
concatenating the text note and attachments, starting by appending the first attachment to the end of
the text note and then appending each subsequent attachment to the end. A header can be added
containing sufficient information to split the message up into text note and attachments on receipt (see
Section 5). The header is optional, and an application or user may, in order to reduce message size
or for other reasons, disable the attachment message header keyword. In this case the text note and
attachments are still packaged together into one Inmarsat-C EGC or message but any receiving
Inmarsat-C CMC implementation will not be able to split the message into text note and attachments
on receipt. The data will, however, be available to the destination application in concatenated form.

The following notes apply to receiving messages or EGCs:

1 If the message received has the ATTACH keyword present in the header, the first body part
shall be put in the text note and subsequent body parts contained in attachments.

2 If no ATTACH keywords are present in the header (or if no header exists) and the message
received has a presentation code of Data, it can be assumed that the message was sent with
the ATTACH keyword disabled. The message (after any header has been removed) shall be in
the first CMC message attachment and the text note shall be NULL (or contain a header for
user information, see Section 3.6).

3 If no ATTACH keywords are present in the header (or if no header exists) and the message
received has a presentation code of IA5 or ITA2, the message shall be contained in the CMC
text note.

4 If the message received has a presentation code of Basic-X.400, the first body part can be
stored in the text note if EIT and BODYTYPE have a value of IA5 and CONTENTTYPE has a
value of either IPM84 or IPM88, otherwise the text note shall be NULL (or contain the header
added by the LES, if present) and the first attachment shall contain the first body part.

3.2.3 Data Reporting and Polling


The Inmarsat-C Data Reporting and Polling protocols are intended for sending relatively small
amounts of data From and To-Mobile respectively. Each data report can contain up to 32 bytes of
user data and each poll can contain at least 250 bytes of user data (the exact amount of user data
allowed is dependent on the type of Poll packet). Because of the relatively small volumes of data, the
Inmarsat-C Message Headers defined in Section 5 are not appropriate and shall not be added to the
start of polls and data reports. This section does not apply to From-Mobile messages sent to DNID
addresses using the Inmarsat-C messaging protocol.

Both data reports and polls support the transfer of binary user data, but, unlike the Inmarsat-C EGC
and messaging protocols, they do not have an Inmarsat-C presentation code. When sending data
reports and polls, the text note and any attachments are concatenated together without any Inmarsat-
C headers (text note first, then first attachment etc.). Additional data for mobile to mobile reports may
be added to the start of the data field by the CMC API implementation (see section 3.3.4.5). On
receiving data reports and polls, the text note shall be NULL and the data contained in the first

Volume 2: User Services, Part 3: CMC Extensions, Page: 16


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

attachment. The first byte of the data field for certain mobile to mobile reporting poll packets is
interpreted as the member number and not included in the first attachment (see section 3.3.4.5).

3.2.4 Land Mobile Alerting


The Inmarsat-C Land Mobile Alerting protocol can support the sending of 8 bytes of user data.
Because of the relatively small volumes of data, the Inmarsat-C Message Headers as defined in
Section 5 are not appropriate and shall not be added to the start of the message. A format for the
data to be sent is defined which includes position information, nature of alert, a flag to indicate
automatic or manual initiation, age of position information, and speed and direction of travel (see the
Inmarsat-C System Definition Manual). The satellite protocol could, however, be used to support any
user data. The Land Mobile Alerting service requires routing and billing arrangements to be made
with a particular LES or LESs.

When sending a Land Mobile Alert, the CMC text note and attachments are concatenated together
(as for sending data reports), additional bytes added to take the total number of bytes to 8 with any
additional bytes filled with zeroes, and the resulting data sent in the Land Mobile Alert. Applications
which wish to make use of the Land Mobile Alert data format as defined in the SDM can use the
CMC_X_IMS_GEN_LAND_MOBILE_ALERT_DATA extension. If this extension is present on a
message to be sent and the message address is a land mobile alerting address (prefix LMA:), the
contents of the text note and any attachments will be ignored and the values given in the extension
used for the land mobile alert contents. If the extension is present with an address other than a land
mobile alerting address, the extension will be ignored.

When receiving a Land Mobile Alert, the CMC text note shall be NULL and the first attachment shall
contain the alert data. The alert data will always by 8 bytes in length. Applications can request that
Land Mobile Alert messages received have the CMC_X_IMS_GEN_LAND_MOBILE_ALERT_DATA
extension.

Parameters can be included in the Land Mobile Alert address to alter the contents of the Land Mobile
Alert data. If these are present, they simply overwrite the data extracted from the text note and
attachments, or contained in the CMC_X_IMS_GEN_LAND_MOBILE_ALERT_DATA extension.
MESs may also have positioning equipment from which the position fields in the defined format may
be set. If the MES provides such facilities, it is an MES and CMC API implementation matter what
mechanisms, if any, are provided to enable or disable the automatic insertion of such data into Land
Mobile Alert packets.

3.2.5 Message Transfer Reports


Message Transfer Reports are generated by the CMC API implementation and refer to the details of a
message transfer between either an MES and an LES, or a terrestrial node and an LES. Message
Transfer Reports can refer to EGCs, Inmarsat-C messages, land mobile alerts, polls and data reports.
A single CMC message may result in several Message Transfer Reports if the message is multiply
addressed.

A bespoke application may access the relevant information through the message extension
CMC_X_IMS_GEN_MESSAGE_TRANSFER_REPORT. For the benefit of users with off-the-shelf
applications, an implementation should also include the information in the text note of the message.
The information should appear in the form of a block of text formatted as a series of lines consisting
of:

[keyword]:[value]

with optional white space between : and [value]. The first line shall be:

TITLE:Message Transfer Report

Volume 2: User Services, Part 3: CMC Extensions, Page: 17


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Other lines have keywords which correspond to members of the data structure
CMC_X_IMS_message_transfer_report data extension, described in Section 4.2.3, according to the
following table:

Keywords CMC_X_IMS_message_transfer_report members

ADDRESSES addresses
LES les
MSGREFERENCE message_reference_number
MSGSIZE size
MSGPACKETS message_packets
REPEATEDMSGPACKETCOUNT repeated_message_packet_count
RETRANSMISSIONCOUNT retransmission_count
SUBMISSIONTIME submission_time
STARTTRANSMITTIME start_transmit_time
ENDTRANSMITTIME end_transmit_time

The order in which the keywords appear (other than TITLE which shall be first) is dependent on the
CMC implementation. The TITLE, ADDRESSES, MSGSIZE, SUBMISSIONTIME,
STARTTRANSMITTIME, ENDTRANSMITTIME, MSGREFERENCE (for messages and EGCs), and LES
keywords shall be supported. For EGCs, MSGREFERENCE reflects the EGC message reference
number returned by the LES when the EGC is submitted; the Inmarsat-C data reporting, polling and
land mobile alert protocols do not have a message reference number. The MSGPACKETS,
REPEATMSGPACKETCOUNT, and RETRANSMISSIONCOUNT values are only applicable for From-
Mobile transmissions and may not be supported by particular CMC implementations or particular
MESs. If information items are not available, the relevant keywords and values will not appear in the
message transfer reports. The format of submission, start and end times should follow that defined
for Inmarsat-C Headers (see Section 5) and all numbers should be in decimal.

The ADDRESSES value shows the intended recipients of this message transfer. Each address shall
be in the format defined in Section 3.2 with multiple addresses separated by a comma. If a message
addresses to several destinations requires more than one LES transfer (e.g. message sent via a AOR
East LES and a POR LES) a message transfer report should be generated for each LES transfer and
the addresses shown in each report shall reflect the intended recipients of the particular LES transfer
rather than all the recipients of the message.

It is recommended that the original text note is appended to the above, the two being separated by a
single line of equals signs (“=”), and that the message transfer report has any attachments of the
original messages attached. Application programs that parse message transfer report messages
should only assume that the first character in the line separating the message transfer report
information from the original text note is an equals sign (“=”).

3.2.6 Delivery and Non-Delivery Reports


A CMC non-delivery report corresponds to failures where a successfully submitted message has not
been successfully delivered to the destination. A CMC delivery report indicates successful delivery
(under certain situations where the address is another store and forward unit, a positive delivery
message may indicate delivery to the store and forward unit rather than delivery to the final
destination).

Under certain situations, a delivery or non-delivery report sent by an LES may not be received by an
MES (e.g. if the MES was unable to “see” the satellite when the report was sent. For this reason, a

Volume 2: User Services, Part 3: CMC Extensions, Page: 18


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

CMC implementation for an Inmarsat-C MES could automatically use the Inmarsat-C Message Status
Enquiry service to determine the status of a previously sent message on behalf of the user. Because
the Message Status Enquiry is a service which the user has to pay for, if a CMC implementation is
able to automatically send Message Status Enquiries, the user should be able to disable this function
and also specify the timeout after which the enquiry should be sent. The enquiry result is very similar
to a delivery or non-delivery report and so is subject to the same possible losses and delays as an
ordinary delivery report. The enquiry result will not, however, wait for the success or failure of the
message and can give a “transfer in progress” result.

The time_sent field in the delivery or non-delivery message structure should indicate the time that the
CMC implementation received or generated the report.

Delivery reports should have the text note and attachments of the original message (if possible) with
the following lines added to the start of the text note (there may be spaces or tabs after “:”):

TITLE:Delivery Report
ADDRESS:[destination address]
LES:[LES ID]
MSGREF:[reference number]
LESATTEMPTS:[number of attempts]

where [reference number], [LES ID] and [number of attempts] are decimal numbers, and [destination
address] is a string in the format defined in Section 3.3 with multiple addresses separated by
commas. The value [number of attempts] reflects the number of attempts made by the LES to deliver
the message to the destination address. The format of the lines is identical to that used for message
transfer reports.

Non-delivery reports should have the following:

TITLE:Non-delivery Report
ADDRESS:[destination address]
LES:[LES ID]
MSGREF:[reference number]
LESATTEMPTS:[number of attempts]
REASON:[non-delivery reason code] [non-delivery reason string]

where [reference number], [LES ID], [number of attempts] and [destination address] are as above,
[non-delivery reason code] is a four digit decimal code (with leading zeroes if necessary) and [non-
delivery reason string] is a user readable string identifying the cause of failure. [non-delivery reason
code] and [non-delivery reason string] are separated by a single space. If particular information is not
available, for example if the LES could not be reached and so a message reference number was not
allocated, the relevant line should be omitted from the start of the text note.

Errors 0101-0112 correspond to Inmarsat-C request status errors and should be generated by the
MES implementation of CMC.

Errors 0201-0209 correspond to Inmarsat-C force clear errors and may be generated by MES and
LES implementations of CMC.

Errors 0301-0383 correspond to Inmarsat-C confirmations and message status enquiries to MESs,
and non-delivery reports to terrestrial destinations.

Errors 0400-0447 correspond to Inmarsat-C Basic X.400 error codes (see also [3]).

Errors 0501-0502 are DTE errors applicable to both MES and LES implementations of CMC.

Errors 0601-0616 are errors applicable to LES implementations of CMC.

Errors 0701-0704 and 0717-0718 are errors applicable to MES implementations of CMC.

Volume 2: User Services, Part 3: CMC Extensions, Page: 19


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Errors greater than 1000 are implementation dependent.

The following table gives a list of possible values of [non-delivery reason code] with the associated
values of [non-delivery reason string]. Where appropriate one of the following should be used but
implementations are free to append additional text or add additional error codes (error numbers
greater than 1000).

Request Status Error Codes (From-Mobile messaging only)

0101 LES message store full


0102 Requested destination not served
0103 Satellite congestion
0104 Terrestrial congestion
0105 Requested service not provided
0107 Request barred
0108 MES not logged in
0109 MES not commissioned
0110 Waiting TDM assignment
0111 Illegal request
0112 LES not in service.

Force Clear Error Codes (To and From-Mobile messaging)

0201 LES timeout


0202 MES protocol error detected
0203 LES fatal hardware detected
0204 Operator Forced Clear
0205 MES Forced Clear
0206 LES protocol error detected
0207 MES hardware error detected
0208 MES timeout
0209 Unrecognised Presentation Code

Confirmation Error Codes (To and From-Mobile messaging)

0301 ABS Absent subscriber


0302 ACB Access barred
0303 ADR Addressee refuses
0304 ATD Attempting to deliver the message
0305 BK Aborted
0306 BMC No end of message or end of transmission received
0307 BUS Busy
0308 CCD Call cut or disconnected
0309 CIE The LES ran out of processing/communications capacity
0310 CNS Call not started
0311 DER Out of order
0312 DTE Remote DTE clearing
0313 EOS Element of service not described (X.400)
0314 FAU Faulty
0315 FMT Format error
0316 FSA Fast select acceptance not subscribed
0317 IAB Invalid answerback
0318 IAM Was unable to process the address information in the following message
0319 IDS Invalid data from ship
0320 IDT Input data timeout
0321 IFR Invalid facility request
0322 IMS Message size is invalid
0323 INC Inconsistent request (X.400)

Volume 2: User Services, Part 3: CMC Extensions, Page: 20


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

0324 IND Incompatible destination


0325 INF Call the network information centre
0326 INH Was unable to establish the type of message from the following header
0327 INV Invalid call
0328 ISR Invalid ship request
0329 ITD Awaiting delivery
0330 JFE Office closed because of holiday
0331 LDE Maximum message length exceeded
0332 LEF Local equipment failure
0333 LPE Local procedure error
0334 MBB Message broken by higher priority
0335 MCC Message channel congestion
0336 MCF Message channel failure
0337 MKO Message killed by operator
0338 MOM Wait/waiting
0339 NA Access barred
0340 NAL No address line is present
0341 NDA There was not delivery attempted
0342 NC Network congestion
0343 NCH Subscriber’s number has been changed
0344 NFA No final answerback
0345 NI No line identification available
0346 NIA No initial answerback
0347 NOB Not obtainable
0348 NOC No connection
0349 NP No party/not obtainable
0350 NRC Reverse charging acceptance not subscribed
0351 NTC Network congestion
0352 OAB Operator aborted
0353 OCC Telex occupied/number busy
0354 OOO Out of order
0355 P Stop your transmission
0356 PPR Paper
0357 PRC Premature clearing
0358 PRF Protocol failure
0359 RCA Reverse charging acceptance not subscribed
0360 RDI Redirected call
0361 REF There was a failure in the remote equipment
0362 RIS Recipient improperly specified (X.400)
0363 RLE Resource limit exceeded
0364 RPE Remote procedure error
0365 RPO RPOA out of order
0366 RSB Retransmission still being attempted
0367 SCC Call completed successfully
0368 SHE MES hardware error
0369 SNF The satellite network has failed
0370 SPE MES protocol error
0371 SSSS Change of alphabet
0372 SUC Test results being delivered
0373 TBY Trunks busy
0374 TGR TDM group reset
0375 THRU You are in communication with a telex position
0376 TIM Timeout
0377 TMD Maximum number of addresses exceeded
0378 TPR Teleprinter
0379 UNK Unknown status
0380 W Words
0381 WFA Wrong final answerback
0382 WIA Wrong initial answerback

Volume 2: User Services, Part 3: CMC Extensions, Page: 21


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

0383 XXX Error

Basic X.400 Error Codes (From-Mobile messaging)

The following Basic X.400 error code strings may have additional diagnostic reasons appended:

0400 Transfer failure


0401 Unable to Transfer
0402 Conversion not performed
0403 Physical rendition not performed
0404 Physical delivery not performed
0405 Restricted delivery
0406 Directory operation unsuccessful

Additional diagnostic reasons (may be appended to above error codes):

- Unrecognised O/R name


- Ambiguous O/R name
- MTS congestion
- Loop detected
- Recipient unavailable
- Maximum time expired
- Encoded information types unsupported
- Content too long
- Conversion impractical
- Implicit conversion prohibited
- Implicit conversion not subscribed
- Invalid arguments
- Content syntax error
- Size constraint violation
- Protocol violation
- Content type not supported
- Too many recipients
- No bilateral agreement
- Unsupported critical function
- Conversion with loss prohibited
- Line too long
- Page split
- Pictorial symbol loss
- Punctuation symbol loss
- Alphabetical character loss
- Multiple information loss
- Recipient reassignment prohibited
- Redirection loop detected
- DL expansion prohibited
- No DL submit permission
- DL expansion failure
- Physical rendition attributes not supported
- Undeliverable mail physical address incorrect
- Undeliverable mail physical delivery office incorrect or invalid
- Undeliverable mail physical delivery address incomplete
- Undeliverable mail recipient unknown
- Undeliverable mail recipient deceased
- Undeliverable mail organization expired
- Undeliverable mail recipient refused to accept
- Undeliverable mail recipient did not claim
- Undeliverable mail recipient changed address permanently
- Undeliverable mail recipient changed address temporarily
- Undeliverable mail recipient changed temporary address

Volume 2: User Services, Part 3: CMC Extensions, Page: 22


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

- Undeliverable mail new address unknown


- Undeliverable mail recipient did not want forwarding
- Undeliverable mail originator prohibited forwarding
- Secure messaging error
- Unable to downgrade

CMC Implementation Error Codes

0501 Insufficient memory to complete operation


0502 Port error

LES Access and Request Error Codes (To-Mobile messaging, EGC and Polling)

0601 LES message store full


0602 Requested destination not served
0603 Satellite congestion
0604 Terrestrial congestion
0605 Requested service not provided
0607 Request barred
0608 MES not logged in
0609 MES not commissioned
0610 Waiting TDM assignment
0611 Illegal request
0612 LES not in service
0613 LES number invalid
0614 LES not answering
0615 LES not responding
0616 LES access protocol error
0617 LES not known or not in ocean region

MES Access and Request Error Codes (From-Mobile messaging, land mobile alerting and data
reporting)

0701 MES not responding


0702 Too many actions queued
0703 MES cannot access LES
0704 No response from LES
0717 LES not known or not in ocean region
0718 Login to new ocean region failed

It is recommended that the original text note is appended to the above, the two being separated by a
single line of equals signs (“=”), and that the delivery or non-delivery report has any attachments of
the original messages attached. Application programs that parse delivery and non-delivery report
messages should only assume that the first character in the line separating the delivery report
information from the original text note is an equals sign (“=”).

3.2.7 Receipt and Non-Receipt Reports


Receipt and non-receipt reports have no direct Inmarsat-C equivalents. Generation of receipt reports
may be done by either the CMC API implementation or an application program. Because the user
receiving the original message will pay for any receipt reports sent, CMC API implementations that
support the automatic generation of receipt reports should provide the user with a configuration option
to provide this service or not. The receipt report will have an IP reference number (given by the
YOURREF keyword in the header and the CMC extension
CMC_X_IMS_GEN_YOUR_IP_REFERENCE) which corresponds to the OURREF keyword (and the
CMC extension CMC_X_IMS_GEN_IP_REFERENCE) used for sending the message. The text note
of the receipt reports should have the following lines added to the start of the text note:

TITLE:Receipt Report

Volume 2: User Services, Part 3: CMC Extensions, Page: 23


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

IPREF:[IP reference number]

Non-receipt reports should have the following:

TITLE:Non-receipt Report
IPREF:[IP reference number]
REASON:[non-receipt reason code] [non-receipt reason string]

where [reference number] and [LES ID] are decimal numbers, [non-receipt reason code] is a four digit
decimal code (with leading zeroes if necessary) and [non-receipt reason string] is a user readable
string identifying the cause of failure. [non-receipt reason code] and [non-receipt reason string] are
separated by a single space.

The following table gives a list of possible values of [non-receipt reason code] with the associated
values of [non-receipt reason string]. Where appropriate one of the following should be used but
implementations are free to append additional text or add additional error codes (error numbers
greater than 1000).

General Codes

0001 Message auto-forwarded


0002 Message deleted
0003 User mailbox deleted

It is recommended that the original text note is appended to the above, the two being separated by a
single line of equals signs (“=”), and that the receipt or non-receipt report has any attachments of the
original messages attached. Application programs that parse receipt and non-receipt report messages
should only assume that the first character in the line separating the receipt report information from
the original text note is an equals sign (“=”).

3.2.8 EGC Cancellation Message


When an EGC is cancelled (by sending a message with the EGC: prefix and the CANCEL keyword),
the CMC implementation should generate an EGC cancellation message. This should be of type
CMC: IPM and should have a text note with the following lines:

TITLE: EGC Cancellation


LES: [LES ID]
MSGREF: [Message Reference Number]

If the EGC could not be cancelled, the text note should have the following:

TITLE: EGC Cancellation Failure


LES: [LES ID]
MSGREF: [Message Reference Number]
REASON: [Reason Code] [Reason String]

where [Reason Code] and [Reason String] are one of the error codes and error strings given for non-
delivery (see section 3.2.6), an implementation specific error code (with a number greater than 1000),
or the following:

0701 No EGC with Message Reference Number

3.2.9 Protocol Indications and Alarms


An MES DCE can send protocol related messages to the DTE (see Section 2.7.2 of Chapter 4 of
Volume 3, Part 2 of the Inmarsat-C System Definition Manual). These messages will be passed to
the application via the CMC API as CMC:IPM messages that can be listed using cmc_list() and read
using cmc_read(). The text note will be a protocol-related message.

Volume 2: User Services, Part 3: CMC Extensions, Page: 24


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The format of the text note should conform to the

[keyword]:[value]
syntax and the first line should be a title of the form
TITLE: [title string]

A suggested value of [title string] is Protocol Indication but the CMC implementation is free to
use others.

The rest of the text note is CMC implementation dependent but should typically contain a user
readable description of the protocol or alarm related message.

3.2.10 Errors
If the data to be sent (including any Attachments) exceeds the maximum message size for the
Inmarsat-C protocol, cmc_send() shall return the error CMC_E_TEXT_TOO_LARGE.

Failures to transmit a message to or from the MES (for example if the MES is blocked and so unable
to “see” the satellite) shall result in a non-delivery report and shall not result in CMC error codes.

3.3 Addressing of CMC Messages

3.3.1 General Addressing of Messages


Calls to cmc_send() must either have at least one valid “To”, “CC” or “BCC” (if supported) recipient, or
must enable UI (see cmc_send() in Common Messaging Call API Section 4.1.1). Recipients may
have values in either the name field, the address field, or both name and the address fields. If the
address field has a value, this shall be used for addressing the message. If the name field has a
value and the address field does not, the implementation shall attempt to resolve the name to an
address using an address book (if implemented). Applications may call cmc_look_up() to attempt to
resolve a friendly name to an address (although full address book functionality may not be supported
by the CMC API implementation).

Messages sent using cmc_send() may also contain a “From” recipient structure. The address field of
this structure (if not NULL) shall be used in the FROM: line in the Inmarsat-C Message Header (if
header and FROM: line are enabled). If the “From” recipient is not present a user defined default
value shall be used in the header if the header line is enabled.

Received messages may have values in either the name field, the address field, or both the name and
the address fields. In some cases the CMC implementation may not have any information as to the
originator of the message in which case the “From” recipient should still be included but both the
address and name fields shall be NULL. In general, any address field value should conform to the
Inmarsat-C addressing conventions in this section (and its subsections) whereas the name field value
can be a friendly name. However, if the originator network is known but not the address, the address
field should contain the appropriate prefix for the network. There are three possible sources of
originator information available to the CMC API implementation when receiving a message:

− the LES via terrestrial interfaces when receiving a from MES message

− an LES specific header added to the start of a message

− the Inmarsat-C Header added to the start of the message (see Section 5)

This section and its subsections defines where the CMC implementation should obtain the originator
address and what the name and address fields should contain.

Volume 2: User Services, Part 3: CMC Extensions, Page: 25


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

In many cases an application will be able to reply to a message by using the “From” recipient as the
“To” recipient for a message to send.

In order to maintain consistency across CMC implementations for Inmarsat-C, all addresses shall
start with a prefix to indicate the destination network. The prefix is also used to determine the
Inmarsat-C service being used.

The following are valid prefixes (underline indicates abbreviation):

DNID: (data reporting and polling ID, and messages to DNIDs)


EGC: (Enhanced Group Call)
FAX: (fax -- from mobile only)
INMC: (Inmarsat-C MES)
LMA: (land mobile alert)
PSPDN: (public switched packet data network)
PSTN: (public switched telephone network)
SAC: (special access code)
TELEX: (telex)
X400: (X.400 messaging network)

The prefix can be either upper or lower case (or a mixture of both) and white space may be added
before the prefix or after the colon (but not between the prefix and the colon). Addresses can also
contain parameters introduced by a semicolon and a keyword. Many parameters require a value
which should be separated from the keyword by an equals sign. White space can appear before or
after any keyword, value, or semicolon but it is strongly recommended that addresses created by the
CMC implementation do not contain additional spaces before or after the destination network prefix,
nor before or after any keyword, values or semicolon (this will reduce the size of the address for
display purposes and make programmed parsing of the address string easier).

In most cases, the application or user may abbreviate prefixes, parameters and values. Allowed
abbreviations are shown in the keyword tables. To improve user readability, and aid programmed
parsing of address strings, it is strongly recommended that CMC implementations use the
unabbreviated form for addresses presented to the application through CMC.

Some parameters have equivalent extensions. Where there is a conflict between extensions and
address line parameters (and their values), the address line parameters take precedence.

More than one recipient may be selected via a User Interface, or returned via a User Interface as an
expansion of a distribution list. Such recipients and distribution lists may be contained within the
directory provided by the CMC messaging service. Multiple recipients may result in multiple
messages over the Inmarsat-C network.

3.3.2 Inmarsat-C Messaging


An Inmarsat-C mobile address is introduced by the INMC: prefix. The INMC: prefix is used in the
From-Mobile direction to address another Inmarsat-C mobile. It is also used to address a store-and-
forward message to an Inmarsat-C mobile from a terrestrial application.

An INMC address consists of the prefix, an address, and, optionally, a set of address parameters
separated by semicolons. The following are the parameter keywords that can follow the INMC:
prefix:

Keyword(=) Value

DR -

LES= [LES Identity]

MTR -

Volume 2: User Services, Part 3: CMC Extensions, Page: 26


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

NAME= [Name String]

NOHEADERS= -

RANDOM= [Randomizing Interval]

REGION= natural number where:-

0 is Atlantic West
1 is Atlantic East
2 is Pacific
3 is Indian
all other numbers are (currently) undefined

REPLY -

RR -

[LES Identity] an LES identifier represented as a 3 digit decimal number. The


first digit is the ocean region code and the second and third
digits are the LES identifier.

[Name String] user defined string

[Randomizing Interval] the number of frames over which the MES will randomise the
timing of its response, in range 0-255 (one frame is 8.64
seconds).

(Note: underlined characters are the minimum abbreviations)

The following notes apply to user, or application, generated INMC: addresses:

1 [Name String] is a user defined, free format string. If the TO: Inmarsat-C Header keyword is
enabled, the NAME keyword and value will be included in the Header and can therefore be
available to an application, or user, receiving the message. The NAME keyword could be used
by a gateway application built on CMC to indicate a mail system user.

2 The DR, RR and REPLY keywords request positive (and negative) delivery reports, receipt (and
non-receipt) reports and reply respectively. Non-delivery reports are provided by default.

3 The NOHEADERS keyword switches all Inmarsat-C headers off for this message.

4 Any keywords present in the address of a message to be sent override any corresponding
defaults or extensions.

5 If both the REGION and the LES keywords are included, the REGION keyword value will
determine the Ocean Region if this is required in the address (for example, in From-Mobile
addressing to another Inmarsat-C MES), and the LES keyword value will determine the LES
through which the call is made. If the MES is not accessible via the LES, a non-delivery report
will be returned without call attempts through other LESs.

6 The MTR keyword requests the CMC implementation to send a Message Transfer Report when
the message has been successfully delivered to the LES.

7 An address may specify a randomizing interval, using the RANDOM keyword. Applications
developer’s writing applications to run simultaneously on many MESs are strongly advised to
use the RANDOM keyword in addresses if the nature of the application will cause the MESs to
respond at the same time (e.g. if the application results in a message being sent at the same
time each hour from 20 MESs). As a guide, the randomizing interval should be set at the

Volume 2: User Services, Part 3: CMC Extensions, Page: 27


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

number of mobiles divided by 2 although in certain cases lower randomizing intervals may be
acceptable. CMC API implementations should do the necessary randomizing (ensuring that the
random number seed will not be the same across all MESs running the application) if the MES
does not support this operation

The following notes apply to message addresses generated by the CMC implementation for
messages received from an MES:

1 If the Inmarsat-C Message Header is present, contains the FROM: or TO: keyword and the
FROM: or TO: keyword value contains an address with a valid prefix, then:

- this address, including all parameters and their values, shall be used as the value of the
address field in the “From” or “To” recipient structure, and

- the name field in the “From” or “To” recipient structure shall be set to the value of the
NAME parameter if present in the FROM: of TO: line of the Inmarsat-C Header. If the
NAME parameter is not present, the name field shall be set to the same value as the
address field.

2 If the Inmarsat-C Header is not present or does not contain the FROM keyword, the CMC
implementation should set the address field of the “From” recipient structure if this information
is available from the communications protocol or LES specific header. The REGION parameter
should be included if possible. If the originator is not available, the address field shall be NULL.
In both cases the name field shall be set to the same value as the address field.

3 If the Inmarsat-C Header is not present or does not contain the TO: keyword, the CMC
implementation should set the address and name fields of the “To” recipient structure to NULL..

Example cmc_send() “To” or “CC” addresses:

INMC: 492340227

To-Mobile: This address, when used by a terrestrial application will cause the message to be sent to
the MES 492340227 via the current default LES. If the MES is logged in to another Ocean Region not
covered by the default LES, the CMC API implementation will attempt to deliver the message through
the default LES for that region (several attempts may be necessary if the current MES ocean region is
not available to the CMC API implementation when trying through the default LES).

Mobile-To-Mobile: This address, when used from a MES application, will cause the message to be
sent to the MES with the sending MESs ocean region code2. If the destination MES is not in the
same Ocean Region, and if the LES does not have any special arrangements for forwarding
messages sent to a different ocean region, a non-delivery report will be generated.

INMC:492340227;REGION=2

To-Mobile: This address, when used from a terrestrial application will cause the message to be sent
to the MES 492340227 via the default LES for Pacific Ocean Region messages. If the MES cannot
be contacted through this default LES, a non-delivery report will be generated (the default LES may
deliver the message to the MES even if the MES is not currently located in the Pacific Ocean Region
but no alternative LESs will be tried).

Mobile-To-Mobile: This address, when used from a MES application, will cause the message to be
2
sent over the Inmarsat-C network with the Pacific Ocean Region identification . The current default
LES would be used.

2 The from-MES addressing structure currently requires the ocean region identification. In future this may not be
required.

Volume 2: User Services, Part 3: CMC Extensions, Page: 28


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

INMC:492340227; LES=202

To-Mobile: This address, when used from a terrestrial application will cause a message to be sent to
the MES 492340227 via the Pacific Ocean Region LES 202 (Perth). If the MES cannot be contacted
through this LES, a non-delivery report will be generated (the LES may deliver the message to the
MES even if the MES is not currently located in the Pacific Ocean Region but no alternative LESs will
be tried).

Mobile-To-Mobile: This address, when used from a MES application, will cause the CMC API
implementation to attempt to send the message through LES 202, logging in to the Pacific Ocean
Region if required3. If the login should fail, for any reason, the current MES Ocean Region and login
status should remain unchanged and a non-delivery report generated. The MES address will contain
the Ocean Region of the sending MES before the sending MES logs in to the new region.

INMC:492340227;LES=312;REGION=0

To-Mobile: This address, when used from a terrestrial application will cause the CMC implementation
to attempt to send the message to MES 492340227 via the Indian Ocean Region LES 312 (Burum). If
the MES cannot be contacted through this LES, a non-delivery report will be generated (the LES may
deliver the message to the MES even if the MES is not currently located in the Atlantic West Ocean
Region but no alternative LESs will be tried).

Mobile-To-Mobile: This address, when used from a MES application, will cause the CMC API
implementation to attempt to send the message through LES 312, logging in to the Indian Ocean
Region if required. If the login should fail, for any reason, the current MES Ocean Region and login
status should remain unchanged and a non-delivery report generated. The MES address will contain
the Atlantic West Ocean Region.

Two recipient addresses:

INMC:492340227

and

INMC:492340228

To-Mobile: These addresses, when used from a terrestrial application will cause the message to be
sent to the two MESs 492340227 and 492340228.

Mobile-To-Mobile: These addresses, when used from a MES application, will cause a single multiply
addressed message to the two MESs, both addresses being prefixed by the Ocean Region that the
sending MES is logged into.

Two recipient addresses:

INMC:492340227;LES=131

and

INMC:492340228;LES=302

To-Mobile: These addresses, when used from a terrestrial application, will cause the message to be
sent to the two MESs 492340227 and 492340228. The message will be sent to MES 492340227 via
LES 131 (Blåvand) and to MES 492340228 via LES 302 (Perth). If one of the message transfers fails
because an MES is not logged into an Ocean Region covered by the LES, no alternative LES will be
tried for that destination.

3 The login procedure cannot be activated on GMDSS MESs from additional DTEs. Implementations connected
to such MESs should send an non delivery report if the LES is not within the current Ocean Region.

Volume 2: User Services, Part 3: CMC Extensions, Page: 29


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Mobile-To-Mobile: These addresses, when used from a MES application, will cause the message to
be transmitted twice, to MES 492340227 via LES 131 and to MES 492340228 via LES 302. The MES
will attempt to login to the appropriate Ocean Region(s) in order to send the messages as required.

3.3.3 Telex, Public Switched Packet Data Network (X.25), Public Switched
Telephone Network (Voice-Band Modem), Facsimile (FAX) and Special Access
Code Messaging
Telex, PSPDN, PSTN, fax and Special Access Code addresses are introduced by the TELEX:,
PSPDN:, PSTN:, FAX: and SAC: prefixes respectively. Each address consists of the appropriate
prefix, a numeric addresses (alphanumeric addresses of up to six IA5 characters for Special Access
Codes), and a set of address parameters separated by semicolons.

The following are the parameter keywords that can follow TELEX:, PSPDN:, PSTN:, FAX: and
SAC: prefixes. When the implementation generates an address (i.e. when PSTN or PSPDN network
messages are received at a mobile) the keywords should not be abbreviated.

Keyword(=) Value

DR -

LES= [LES Identity]

MTR -

NAME= [Name String]

NOHEADERS= -

RANDOM [Randomizing Interval]

REPLY -

RR -

[LES Identity] an LES identifier represented as a 3 digit decimal number. The


first digit is the ocean region code and the second and third
digits are the LES identifier.

[Name String] user defined string

[Randomizing Interval] the number of frames over which the MES will randomise the
timing of its response, in range 0-255 (one frame is 8.64
seconds).

[Name String] is a user defined, free format string. If the TO: Inmarsat-C Header keyword is
enabled, the NAME keyword and value will be included in the Header and can therefore be available to
an application, or user, receiving the message. The NAME keyword could be used by a gateway
application built on CMC to indicate a mail system user.

The DR, RR and REPLY keywords request positive (and negative) delivery report, receipt (and non-
receipt) report and reply respectively. Non-delivery reports are provided by default.

The MTR keyword requests the CMC API implementation to generate a Message Transfer Report
when the message has been successfully delivered to the LES.

An address may specify a randomizing interval, using the RANDOM keyword. Applications developer’s
writing applications to run simultaneously on many MESs are strongly advised to use the RANDOM
keyword in addresses if the nature of the application will cause the MESs to respond at the same time

Volume 2: User Services, Part 3: CMC Extensions, Page: 30


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(e.g. if the application results in a message being sent at the same time each hour from 20 MESs).
As a guide, the randomizing interval should be set at the number of mobiles divided by 2 although in
certain cases lower randomizing intervals may be acceptable. CMC API implementations should do
the necessary randomizing (ensuring that the random number seed will not be the same across all
MESs running the application) if the MES does not support this operation.

Where conflict arises between address parameters, extensions and system defaults, address
parameters override both the extensions and system defaults.

Addresses generated by the CMC implementation shall follow the guidelines for Inmarsat-C
Messaging addresses in Section 3.3.2.

Example cmc_send() “To” or “CC” addresses:

TELEX: 51297201; LES = 112

This is the address of the telex machine (297201) in the United Kingdom (51) via LES 112 (Burum,
AOR East). If the MES is not logged into the Ocean Region with LES 112 (the Atlantic East Ocean
Region), the MES will attempt to login to the region. If the login is not successful a non-delivery report
will be returned and the MES should be left in the original login state.

PSPDN: 2350000755

This is a PSPDN address. The message will be sent via the current default LES.

PSTN: 44717281283; LES = 112

This is the address of a voice band modem (071 7281283) in the United Kingdom (44). The message
will be sent via LES 112 (Burum, AOR East).

FAX: 44717281625

This is the address of a fax machine (071 7281625) in the United Kingdom (44). The message will be
sent via the current default LES.

SAC: CA5798; LES=112

This is the address of a Special Access code at LES 112. The message will be sent to LES 112. If
the MES is not logged into the Ocean Region with LES 112 (the Atlantic East Ocean Region), the
MES will attempt to login to the region. If the login is not successful a non-delivery report will be
returned and the MES should be left in the original login state.

3.3.4 Data Reporting, Polling, and DNID Message Addressing


Data reporting (From-Mobile service), polling (To-Mobile service), mobile to mobile reporting, and
messages to DNIDs (a from-MES service) all have addresses introduced by the DNID: prefix.
Section 3.3.4.5 describes address lines for the mobile to mobile reporting service. Sections 3.3.4.1 to
3.3.4.4 describe sending a poll, receiving a poll, sending a data report or from MES DNID Message,
and receiving a data report or from MES DNID Message respectively.

The behaviour of the API implemention is dependent on the DNID ID; IDs in the range 32768 to
49151 are allocated for the mobile to mobile reporting service. For IDs outside of this range, and for
from-MES messages, the value following the PROTOCOL keyword contained in the address
determines whether the data is sent using the data reporting polling or as a message to the DNID
address. If the PROTOCOL keyword is not present, the size of the data to be sent is used to determine
whether a message or a data report is sent.

For To-Mobile messages the prefix is used for sending a poll. Information associated with polls and
data reports is carried in the address line. The address may have a number of address parameters
separated by semicolons.

Volume 2: User Services, Part 3: CMC Extensions, Page: 31


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The following parameter keywords are applicable to the DNID: prefix for sending and receiving data
reports (and Inmarsat-C messages to DNID addresses). Other parameter keywords only applicable
to polls may also be included (to allow polls to be easily replied to) but will be ignored.

Keyword(=) Value

DR -

ID= [Data Network ID]

LES= [LES Identity]

MEMBER= [DNID Member Number]

MTR -

NAME= [Name String]

NOHEADERS -
PROTOCOL= DATAREPORT
| MESSAGE
| NORESPONSE
(If the PROTOCOL keyword is not present, DATAREPORT is
assumed).

RANDOM= [Randomizing Interval]

REPLY -

RR -

[Data Network ID] a closed network address, represented as an integer in range


0-65535.

[LES Identity] an LES identifier represented as a 3 digit decimal number. The


first digit is the ocean region code and the second and third
digits are the LES identifier.

[DNID Member Number] number in range 1-255 that uniquely identifies an MES within
the group defined by a DNID and LES identifier

[Randomizing Interval] the number of frames over which the MES will randomise the
timing of its response, in range 0-255 (one frame is 8.64
seconds)

[Name String] user defined string

The following parameter keywords are applicable to the DNID: prefix for sending and receiving polls.
Other parameters only applicable to data reports and messages to DNIDs may be included but will be
ignored.

Keyword(=) Value

ACKNOWLEDGEMENT -

ADDRESS= [MES Number]


| [Area]

COMMAND= [Command Number]

Volume 2: User Services, Part 3: CMC Extensions, Page: 32


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

DUPLICATE -

FRAME= [Frame Number]

ID= [Data Network ID]

INTERVAL= [Interval]

LES= [LES Identity]

MEMBER= [DNID Member Number]

MTR -

NAME= [Name String]

NOHEADERS -
PROTOCOL= DATAREPORT
| MESSAGE
| NORESPONSE
(If the PROTOCOL keyword is not present, DATAREPORT is
assumed).

RANDOM= [Randomizing Interval]

SEQNUM= [Sequence Number]

SUBADDRESS= [Subaddress Number]

[MES Number] 9 digit mobile number

[Area] ::= [Rectangular Address]


| [Circular Address]
(If the ADDRESS keyword is not present, a group poll is
assumed).

[Rectangular Address] ::= R[Latitude][North or South]


[Longitude][East or West]
[Latitude Extent]X[Longitude Extent]

[Circular Address] ::= C[Latitude][North or South]


[Longitude][East or West][Radius]

[North or South] ::= N|S

[East or West] ::= E|W

[Latitude] Latitude of point in degrees (natural number)

[Longitude] Longitude of point in degrees (natural number)

[Latitude Extent] Extent of the rectangle in degrees North (natural number)

[Longitude Extent] Extent of the rectangle in degrees East (natural number)

[Radius] the radius of the circle in nautical miles (0 to 32676)

[Command Number] integer in range 0 to 127:

Volume 2: User Services, Part 3: CMC Extensions, Page: 33


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

0 Send Unreserved Report


1 Program Reserved Data Reporting
2 Initiate Reserved Data Reporting
3 Stop Reserved Data Reporting
4 Program Unreserved Data Reporting
5 Initiate Unreserved Data Reporting
6 Stop Unreserved Data Reporting
7 Define Macro Encoded Message
8 Macro Encoded Message
9 Data Transmission
10 Download DNID
11 Delete DNID
12-63 Reserved
64-127 User Defined

(If the COMMAND keyword is not present, a value of 9 (Data


Transmission) is assumed).

[DNID Member Number] number in range 1-255 that uniquely identifies an MES within
the group defined by a DNID and LES identifier

[Frame Number] absolute frame number in range 0-9999 (each day is divided
into 10000 equal frames, 0 corresponds to 00:00 UTC). It is
used to define the start frame in a "Program Unreserved Data
Reporting" poll.

[Data Network ID] a closed network address, represented as an integer in range


0-65535.

[Interval] a frame count that gives the interval between data reporting
transmissions. It is a number that has been derived by
multiplying a number in range 0-63 by 1, 10, 100 or 1000 and is
used to define the interval in a "Program Unreserved Data
Reporting" poll.

[LES Identity] an LES identifier represented as a 3 digit decimal number. The


first digit is the ocean region code and the second and third
digits are the LES identifier.

[Name String] user defined string

[Randomizing Interval] the number of frames over which the MES will randomise the
timing of its response, in range 0-255 (one frame is 8.64
seconds)

[Sequence Number] a number in the range 0 to 255. Repeated polls have the same
sequence number.

[Subaddress Number] a number in the range 0 to 255 (if the SUBADDRESS keyword is
not present in the address, a sub address value of 0 is
assumed).

3.3.4.1 Sending a Poll

The following notes are applicable to message addresses for sending polls using the CMC API:

1 The address must start with the DNID: prefix.

Volume 2: User Services, Part 3: CMC Extensions, Page: 34


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2 The address may specify the poll command type, using the COMMAND keyword. If this keyword
is not present in the address then a command type of Data Transmission (09H) is assumed.

3 An address may specify the MES number (for an individual poll) or an area (for area polls)
using the ADDRESS keyword. If this keyword is not present in the address a group poll is assumed.

4 An address must include the Data Network ID using the ID keyword and the LES using the LES
keyword. The address is invalid if either of these keywords is not present.

5 An address may specify a subaddress, using the SUBADDRESS keyword. If this keyword is not
present in the address, a subaddress of zero is assumed.

6 An address may specify the type of response required using the PROTOCOL keyword. If this
keyword is not present in the address, a response value DATAREPORT is assumed.

7 Including the ACKNOWLEDGEMENT keyword in an address requests an automatic


acknowledgement (sent as a data report).

8 An address may specify the message sequence number, using the SEQNUM keyword. If the
SEQNUM keyword is not present in the address, the sequence number is left to the LES or CMC
API implementation. Even if the SEQNUM keyword is present, it may be ignored by the
implementation.

9 An address may specify, using the DUPLICATE keyword, that the poll is a duplicate and so
should be sent with the same sequence number as the last poll to the same ID and LES. An
application that wishes to send a duplicate poll should use the DUPLICATE keyword and should
not rely on specifying the same sequence number twice using the SEQNUM keyword. The
DUPLICATE keyword takes precedence over the SEQNUM keyword.

10 If the command type is "Program Unreserved Data Reporting" (04H), the address must specify
the start frame and interval, using the FRAME and INTERVAL keywords. These keywords must
not be used for other command types. There are 10,000 frames in a day with frame 0
corresponding to 00:00 UTC The interval value is the number of whole frames between
repeats.

11 Only particular interval values (specified using the INTERVAL keyword) can be included in
Inmarsat-C Polls. Valid values are in the range 0-63 multiplied by 1, 10, 100 or 1000. For
example, the intervals 21, 210, 2100, and 21000 can be included but not 211, 2101 and 21001.
The CMC implementation will silently round intervals that cannot be included in a Poll to the
closest possible interval number.

12 If the command type is "Download DNID" (0AH), it must specify the DNID member number
using the MEMBER keyword. This keyword must not be used for other command types.

13 The DR, RR and NOHEADERS keywords, if present, will be ignored.

Example cmc_send() “To” or “CC” addresses:

DNID: ID=12345; LES=112; ACK

This addresses the group of MESs with DNID 12345, LES 112. A single group Poll will be sent with
the default Command “Data Transmission”. MESs identifying this Poll as addressed to them will send
a data report acknowledgement.

DNID: ID=54321; LES=131; COMMAND=0

This addresses the group of MESs with DNID 54321, LES 131. A single group Poll will be sent with
the Command “Send Unreserved”. No acknowledgement is requested. The protocol to be used for
the response defaults to “Data Report”.

Volume 2: User Services, Part 3: CMC Extensions, Page: 35


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

DNID: ID=54321; LES=131; COMMAND=0; DUP

This addresses the group of MESs with DNID 54321, LES 131. A single group Poll will be sent with
the Command “Send Unreserved”. No acknowledgement is requested. The Poll will have the same
sequence number as the previous poll sent to this DNID, LES pair so only MESs that have not already
received it will respond.

DNID: ID= 10101; ACK; ADDRESS=R30N20W3X4; COMMAND=0; PROTOCOL=MESSAGE;


LES=102;

This addresses the group of MESs with DNID 10101, LES 102 within the rectangular area 30-
33°N,20-24°W. A single area Poll will be sent with the Command “Send Unreserved”. The poll
requests MESs that identify the poll as being addressed for them (i.e. with the DNID 10101, LES 102
and within the specified area) to acknowledge the poll with a data report. The protocol to be used for
the response (which is in addition to the Acknowledgement data report and probably under application
control) will be the Inmarsat-C messaging protocol.

3.3.4.2 Receiving a Poll

Both the name and the address fields of the “From” and “To” recipient structures should all contain the
poll address. The following notes are applicable to message addresses for polls received using the
CMC API:

1 The address must start with the DNID: prefix.

2 The Data Network ID will be given, using the ID keyword.

3 The LES Identity will be given, using the LES keyword.

4 The DNID member number, if present in the poll (download DNID command only), will be given,
using the MEMBER keyword.

5 Other fields in the poll for which there are keywords, and to which the CMC API implementation
has access via the MES interface, will be given in the address with the appropriate keyword
and value.

6 The DUPLICATE keyword will not be present.

Although the DCE has all the information required to set up the address field this information may not
all be available via the DCE interface. CMC API implementations may therefore not be able to provide
all information in the address field. The documentation supplied with each implementation must state
what keywords will be present.

Example addresses for received polls:

DNID: ID=12345; LES=102; COMMAND=0; PROTOCOL=DATAREPORT; ACK;


ADDRESS=499999999

This address line indicates that an individual poll was received addressed, had DNID 12345, LES
102, a command type of “Send Unreserved” with a response of “Data Report” and an
Acknowledgement was requested. The Acknowledgement will be sent automatically by the MES but
the Poll requests a data report response which is under application control.

DNID: ID=222; LES=131; COMMAND=9; PROTOCOL=NORESPONSE; RANDOM=10

This address line indicates that a group poll was received, had DNID 222, LES 131, a command of
“Data Transmission”, no response requested, and a randomizing interval of 10. The randomizing
interval is used for Acknowledgements (which are sent automatically if requested) and application
responses. In this case no response has been requested.

Volume 2: User Services, Part 3: CMC Extensions, Page: 36


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

DNID: ID=14444; LES=131; COMMAND=0; PROTOCOL=MESSAGE; RANDOM=12

This address line indicates that a group poll was received, had DNID 14444, LES 131, a command of
“Send Unreserved”, a message response requested, and a randomizing interval of 12. The
randomizing interval of 12 should be used for the response to avoid all MESs in the group responding
with a message at the same time.

DNID: ID=13212; LES=102; COMMAND=4; PROTOCOL=DATAREPORT; RANDOM=10;


FRAME=6143; INTERVAL=400; ACK

This address line indicates that a group poll was received, had DNID 13212, LES 102, a command of
“Program Unreserved”, data report response, acknowledgement requested (sent automatically by the
MES), and reports requested at 400 frame intervals starting at frame 6143 (a day is divided into
10000 frames with frame 0 at 00:00 UTC).

DNID: ID=13212; LES=102; COMMAND=5; PROTOCOL=DATAREPORT; RANDOM=10

This address line indicates that a group poll was received, had DNID 13212, LES 102, a command of
“Initiate Unreserved”, data report response, no automatic acknowledgement requested. Some MESs
may act on the initiate poll and send data reports at the frame and interval specified by a previous
program poll, other MESs may leave it to the application to respond. Any application responses
should include the RANDOM parameter to ensure that not all members of a group respond at exactly
the same time.

3.3.4.3 Sending a Data Report or a From-Mobile DNID Message

The following notes are applicable to DNID address, From-Mobile, sent using the CMC API:

1 The address must start with the DNID: prefix.

2 An address must specify the Data Network ID, using the ID keyword.

3 An address must specify the LES identity, using the LES keyword.

4 An address may specify the DNID member number using the MEMBER keyword. Some MESs
allow the same DNID at the same LES to be downloaded to an MES more than once, in which
case the only way to distinguish them is with the member number. If the member number is
included, it must match the member number downloaded with the DNID (or the
CMC_E_RECIPIENT_NOT_FOUND error will be returned).

5 An address may specify a randomizing interval, using the RANDOM keyword. Applications
developer’s writing applications to run simultaneously on many MESs are strongly advised to
use the RANDOM keyword in addresses if the nature of the application will cause the MESs to
respond at the same time (e.g. if the application results in a data report being sent at the same
time each hour from 20 MESs). As a guide, the randomizing interval should be set at the
number of mobiles divided by 2 although in certain cases lower randomizing intervals may be
acceptable. CMC API implementations should do the necessary randomizing (ensuring that the
andom number seed will not be the same across all MESs running the application) if the MES
does not support this operation.

6 An address may specify that the data reporting or messaging protocols are to be used by
including the PROTOCOL keyword with a value of DATAREPORT or MESSAGE. If the PROTOCOL
keyword is not present or has the value NORESPONSE, the CMC message will result in a data
report if the data to be sent (text note plus attachments) before addition of any headers is 32
bytes or less. Larger amounts of data are sent as a message to a DNID address.

7 The RR, DR, REPLY, and NOHEADERS keywords are ignored for data reports and only take
effect when sending an Inmarsat-C message to a DNID address.

Example cmc_send() “To” or “CC” addresses:

Volume 2: User Services, Part 3: CMC Extensions, Page: 37


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

DNID: ID=12345; LES=112

This addresses the DNID 12345 at LES 112. If the data to be sent is less than or equal to 32 bytes,
the data will be sent as a data report. If the data to be sent is more than 32 bytes, the data will be
sent as a message. No randomizing interval is specified in this address so the data will be sent as
soon as possible. If more than one DNID with ID 12345, LES 112 has been downloaded to the MES,
the MES will pick any of the member numbers downloaded with these DNIDs for inclusion with the
data report.

DNID: ID=12121; LES=131; MEMBER=61

This addresses the DNID 12121 at LES 131. The data will only be sent if the member number 61 was
downloaded with DNID 12121, LES 131.

DNID: ID=13212; LES=102; RANDOM=100

This addresses the DNID 13212 at LES 102. The data report (or message) will be randomized over
the next 100 frames (approximately 15 minutes).

3.3.4.4 Receiving a Data Report or a From-Mobile DNID Message

Both the name and the address fields of the “From” recipient structure should contain the data report
address. The following notes are applicable to message addresses for data reports received using
the CMC API:

1 The address will start with the DNID: prefix.

2 The Data Network ID will be given, using the ID keyword.

3 The address must specify the LES identity, using the LES keyword.

4 The MEMBER keyword will indicate the DNID member number.

The following notes apply to message recipients generated by the terrestrial CMC implementation for
DNID messages received from an MES:

1 If the Inmarsat-C Message Header is present, contains the FROM: or TO: keyword and the
FROM: or TO: keyword value contains an address with a valid prefix, then:

- this address, including all parameters and their values, shall be used as the value of the
address field in the “From” or “To” recipient structure, and

- the name field in the “From” or “To” recipient structure shall be set to the value of the
NAME parameter if present in the FROM of TO line of the Inmarsat-C Header. If the NAME
parameter is not present, the name field shall be set to the same value as the address
field.

2 If the Inmarsat-C Header is not present or does not contain the FROM: keyword, the CMC
implementation should set the address field of the “From” recipient structure if this information
is available from the communications protocol or LES specific header. If the originator is not
available, the address field shall be NULL. In both cases the name field shall be set to the
same value as the address field.

Volume 2: User Services, Part 3: CMC Extensions, Page: 38


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3 If the Inmarsat-C Header is not present or does not contain the TO: keyword, the CMC
implementation should set the address and name fields of the “To” recipient structure to NULL.
Example address for received data reports:

DNID: ID=19876; LES=102; MEMBER=1

This address indicates that the originator was the MES with member number 1 in DNID 19876, LES
102.

3.3.4.5 Mobile to Mobile Reporting

Mobile to mobile reporting is a service that allows small amounts of data to be sent between mobile
terminals. The data is sent to a server using the data reporting protocol, repackaged by the server
and sent to the destination mobile as a poll. Mobile to mobile reports can be identified by the ID
range 32768 to 49151.

The mobile to mobile reporting IDs are divided into two sub-ranges:

- 32768 to 40959: the server makes no assumptions on the format of the data in the data report,
but places the member number of the mobile sending the data report in the "data field" of the
poll.

- 40960 to 49151: the server interprets the data report structure to define the poll field contents.

The format of the interpreted data report is defined in the Mobile to Mobile Reporting Application Note
- Volume 02, Part 02, Application Note 04.

API implementations that do not support the mobile to mobile service will simply treat all data reports
and polls in the manner described in the preceeding sections but implementations supporting the
mobile to mobile reporting service should behave according to the following table:

DNID Range Sending to a DNID address Receiving a Poll


Data report or DNID message
As defined in Section 3.3.4.2.
0 to 32767 sent as described in Section
3.3.4.3
The MEMBER address line qualifier is
included and is set to the first data byte
Data report or DNID message received in the data field of the poll (any
32768 to 40959 sent as described in Section remaining bytes in the data field will appear
3.3.4.3 in the first attachment). All other address
line qualifiers are as defined in Section
3.3.4.2.
A data report is sent but the data
field in the data report is formatted
as described in [4]. The
ACKNOWLEDGEMENT, ADDRESS,
40960 to 49151 As defined in Section 3.3.4.2.
COMMAND, FRAME, INTERVAL,
PROTOCOL, SEQNUM, and
SUBADDRESS qualifiers affect the
contents of the data report.

Mobile to mobile reporting cannot support area addressing. If area addresses are used, the error
CMC_E_RECIPIENT_NOT_FOUND will be returned (if support for Inmarsat-C extensions has been
requested, the error code CMC_E_IMS_ADDR_ADDRESS will be included in the most significant 16
bits as described in Section 3.3.12).

The mobile to mobile reporting service has limited error handling. Errors returned by the MES DCE
should result in a non-delivery report being returned to the application but any errors detected by the

Volume 2: User Services, Part 3: CMC Extensions, Page: 39


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

mobile to mobile reporting server will result in the data being ignored and a non-delivery report will not
be generated. There is also no provision in the service for the sending of non-delivery reports if the
destination mobile does not receive the data.

3.3.5 Enhanced Group Calls


EGCs can only be sent from terrestrial applications and not From-Mobile. Some EGCs will continue
until cancelled by the user (see the REPEATS and CANCEL keywords below). The CMC
implementation should generate a Message Transfer Report (if enabled) when the EGC message has
been accepted by the LES or a non-delivery report if the EGC message is not accepted by the LES.
An EGC cancellation message should be generated in response to an EGC message with the
CANCEL keyword. EGC addresses are introduced by the EGC: prefix and are followed by one or
more address keywords. Valid address keywords and their values are as follows:

Keyword(=) Value

ADDRESS= [EGC Area]

CANCEL= [Message Reference Number]

ECHO -

EGCINTERVAL= [EGC Interval]

LES= [LES Identity]

MTR -

NAME= [Name String]

NOHEADERS -

REPEATS= [Number of Repeats]

SERVICE= [Service Code]

[EGC Area] ::= [Sysmsg Address]


| [MES Number]
| [Group Address]
| [NAVAREA Address]
| [NAVTEX Address]
| [Rectangular Address]
| [Circular Address]
| [Fixed Address]

[Sysmsg Address] an Inmarsat System Message Address in range 0-255

[MES Number] 9 digit mobile number

[Group Address] ::= E[ENID Number]

[ENID Number] integer between 0 and 65535

[NAVAREA Address] ::= N[NAVAREA Number]

[Coastal warning Address] ::= T[NAVAREA Number]/[B1][B2]


[B1] and [B2] are the two IA5 characters B1 and B2 given in the
message received by the LES.

Volume 2: User Services, Part 3: CMC Extensions, Page: 40


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

[NAVAREA Number] a number in range 0-255 giving the NAVAREA.

[Rectangular Address] ::= R[Latitude][North or South]


[Longitude][East or West]
[Latitude Extent]X[Longitude Extent]

[Circular Address] ::= C[Latitude][North or South]


[Longitude][East or West][Radius]

[North or South] ::= N|S

[East or West] ::= E|W

[Latitude] Latitude of point in degrees (natural number)

[Longitude] Longitude of point in degrees (natural number)

[Latitude Extent] Extent of the rectangle in degrees North (natural number)

[Longitude Extent] Extent of the rectangle in degrees East (natural number)

[Radius] the radius of the circle in nautical miles (integer in range 0 to


32676)

[Fixed Address] F[Fixed Area Number]

[Fixed Area Number] ::= a natural number giving the Chart Correction Service Fixed
Area

[Message Reference Number] The message reference number of the EGC transmission to be
terminated (natural number). The message reference number
(together with the preceding equals sign) may be omitted.

[EGC Interval] indicates the time between repeats in hours. The following are
valid intervals: 1, 2, 3, 4, 5, 6, 12, 18, 24, 30, 36, 48, 60, 72, 96,
120.

[LES Identity] an LES identifier represented as a 3 digit decimal number. The


first digit is the ocean region code and the second and third
digits are the LES identifier.

[Name String] user defined string

[Number of Repeats] ::= NOREPEATS


| ONCE
| TWICE
| UNTILCANCELLED

[Service Code] ::= GENERALCALL


| GROUPCALL
| NAVWARNING
| INMSYSTEMMSG
| COASTALWARNING
| DISTRESSALERT
| EGCSYSTEMMSG
| METNAVWARNING
| DOWNLOADGROUPID
| SARCOORDINATION
| CHARTCORRECTION

Volume 2: User Services, Part 3: CMC Extensions, Page: 41


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

[Name String] is a user defined, free format string. If the TO: Inmarsat-C Header keyword is enabled,
the NAME keyword and value will be included in the Header and will therefore be available to an
application, or user, receiving the message. The NAME keyword could be used by a gateway
application built on CMC to indicate a mail system user.

3.3.5.1 Sending an Enhanced Group Call

When sending an EGC message, the CMC API implementation must have an address in the valid
format. The following notes apply to addresses for EGC messages sent using CMC:

1 The address must start with the EGC: prefix.

2 If the CANCEL keyword is not present in the address, the address must specify the service
code, using the SERVICE keyword.

3 The following table shows the allowed address types for the different SERVICE keyword values:

SERVICE Keyword Value Valid Address Types

GENERALCALL

GROUPCALL [Group Address]

NAVWARNING [Rectangular Address]

INMSYSTEMMSG [Sysmsg Address]

COASTALWARNING [NAVTEX Address]

DISTRESSALERT [Circular Address]

EGCSYSTEMMSG [MES Number]

METNAVWARNING [Circular Address]


[MES Number] and
DOWNLOADGROUPID
[Group Address]
SARCOORDINATION [Rectangular Address]

CHARTCORRECTION [Group Address]

4 The DOWNLOADGROUPID service keyword must have both an MES Number and a Group
Address. The ENID should follow the MES number, e.g.

EGC: SERVICE=DOWNLOADGROUPID; ADDRESS=499999999E1234; LES=131

will send a download group ID EGC with ENID 1234 to MES 499999999 via LES 131.

5 If the LES keyword is omitted then the default LES shall be used. The LES used determines
the NCS TDM that the EGC is transmitted on.

6 The address may disable the generation of Inmarsat-C message headers using the
NOHEADERS keyword.

7 The address may specify that the EGC is to be repeated using the INTERVAL keyword. This
keyword is required if the REPEATS keyword is present.

Volume 2: User Services, Part 3: CMC Extensions, Page: 42


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

8 The address may specify that each time the EGC is sent it should be sent twice with a 6
minutes delay between the repeats by using the ECHO.

9 The address may specify the number of times that the EGC should be repeated (excluding
echoes) using the REPEATS keyword. If this keyword is not present, no repeats are assumed.

10 If the address contains the CANCEL keyword then the EGC referred to by the message
reference number will be cancelled and the contents of the CMC text note and attachments
ignored. If the message reference number is omitted, all continuous transmission EGCs
started from CMC through the particular LES, or default LES, will be cancelled. For each EGC
terminated an EGC cancellation message shall be generated by CMC. If the CANCEL keyword
is present, all other keywords apart from LES are ignored.

3.3.5.2 Receiving an Enhanced Group Call

The following notes apply to EGCs received by a MES:

1 The LES keyword shall be included in the destination address

2 If the Inmarsat-C Message Header is present, contains the FROM:, TO: or CC: keywords
and the keyword values contain an address with a valid prefix, then:

- the address, including all parameters and their values, shall be used as the value of the
address field in the appropriate recipient structure, and

- the name field in the recipient structure shall be set to the value of the NAME parameter if
present in the FROM, TO or CC lines of the Inmarsat-C Header. If the NAME parameter
is not present, the name field shall be set to the same value as the address field

3 If the Inmarsat-C Header is not present or does not contain the FROM keyword, the CMC API
implementation should set the address field of the “From” recipient structure if this information
is available from the communications protocol or LES specific header. If the originator is not
available, the address field shall be NULL. In both cases the name field shall be set to the
same value as the address field

4 If the Inmarsat-C Header is not present or does not contain the TO: keyword, the CMC API
implementation should set the address field of the “To” recipient structure using as much of the
EGC address available from the LES specific header added to the EGC, if present, or the MES
interface.

3.3.6 Land Mobile Alerting


The format of a Land Mobile Alert address is simply the LES ID. For example, the address

LMA: 112

will send a Land Mobile Alert to LES 112. If the mobile is not logged in to the correct ocean region,
the MES will first attempt to login. If the login is not successful, the MES will be returned, if possible,
to its original login region and status.

Routing arrangements for Land Mobile Alerts have to be made with the LES on a per MES basis. In
the From-Mobile direction, one or more optional parameters may define some or all of the contents of
the Land Mobile Alert. These parameters, if present, will overwrite the data extracted by
concatenating the CMC text note and attachments.

The parameters shall also be included on receiving a Land Mobile Alert so that the Land Mobile Alert
data is contained both within the first attachment and also within the originator address. If the Land

Volume 2: User Services, Part 3: CMC Extensions, Page: 43


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Mobile Alert data does not conform to the format defined in the Inmarsat System Definition Manual
then the parameter values on receipt should be ignored.

The following are parameter keywords for use in Land Mobile Alert addresses:

Keyword(=) Value

AUTOMATIC -

DIRECTION= [Direction Of Travel]

EXTRA= [Extra Byte]

MTR -

NATURE= [Nature Of Alert]

POSITION= [Land Position]

RANDOM= [Randomizing Interval]

SPEED= [Speed]

TIMEOFPOSITION= [Time Of Position]

[Nature Of Alert] ::= ACCIDENT


| AMBULANCE
| ATTACK
| BREAKDOWN
| FIRE
| HIJACK
| POLICE
| SEVEREWEATHER
| SPAREA
| SPAREB
| SPAREC
| SPARED
| SPAREE
| SPAREF
| SPILL
| UNSPECIFIED

[Land Position] ::= [LMA Latitude] [North or South]


[LMA Longitude] [East or West]

[LMA Latitude] The numeric format is:

ddmm.mm

where dd is the degrees (with leading zero if necessary) and


mm.mm is the minutes and fractions of minutes (with leading
and trailing zeroes if necessary).

For example,

- 0520.50 is 5º20’30”
- 4600.75 is 46º0’45”

Fractions of minutes will be rounded to the nearest multiple of


0.04 minutes.

[North or South] ::= N|S

Volume 2: User Services, Part 3: CMC Extensions, Page: 44


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

[LMA Longitude] The numeric format is:

dddmm.mm

where ddd is the degrees (with leading zero if necessary) and


mm.mm is the minutes and fractions of minutes (with leading
and trailing zeroes if necessary).

For example,

- 00520.50 is 5º20’30”
- 13200.75 is 132º0’45”

Fractions of minutes will be rounded to the nearest multiple of


0.04 minutes.

[East or West] ::= E|W

[Time Of Position] ::= LT1 -- Less than 1 minute old


|LT5 -- 1 to < 5 minutes old
|LT30 -- 5 to < 30 minutes old
|LT60 -- 30 to < 60 minutes old
|OLD -- 1 hour or older
|NA -- Not Available
|SPARE1 -- corresponds to a field value of 6
|SPARE2 -- corresponds to a field value of 7

[Randomizing Interval] the number of frames over which the MES will randomise the
timing of its response, in range 0-255 (one frame is 8.64
seconds)

[Speed] ::= STOPPED


|SLOW -- < 20 km/h
|MEDIUM -- 20 to 70 km/h
|FAST -- > 70 km/h

[Direction Of Travel] ::= N -- 337.5 to < 22.5 degrees~


|NE -- 22.5 to < 67.5 degrees
|E -- 67.5 to < 112.5 degrees
|SE -- 112.5 to < 157.5 degrees
|S -- 157.5 to < 202.5 degrees
|SW -- 202.5 to < 247.5 degrees
|W -- 247.5 to < 292.5 degrees
|NW -- 292.5 to < 337.5 degrees

[Extra Byte] One or two hexadecimal digits (0 to 9, A to F, case insensitive)


encoding one byte.

If the Land Mobile Alert transmission is not successful, a non-delivery report should be generated.

Example cmc_send() “To” or “CC” land mobile alert addresses:

LMA: 001

This address will send a Land Mobile Alert to LES 001 (logging into if necessary). The contents of the
alert are determined by the contents of the CMC text note and attachments, and possibly by
positioning equipment if available within the DCE.

Volume 2: User Services, Part 3: CMC Extensions, Page: 45


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

LMA: 131; NATURE=BREAKDOWN; POSITION=2312.00N4242.42E;


SPEED=SLOW;DIRECTION=W

This address will send a Land Mobile Alert to LES 131 (logging in if necessary). The contents of the
alert is determined by the contents of the CMC text note and attachments with the parameters given
in the address overwriting the contents of most of the data. Data remaining unchanged by the
address is the automatic/manual activation flag and the extra byte.

3.3.7 X.400 Messaging


Basic X.400 addresses should be prefixed by X400: and followed by the X.400 address as specified
in the Inmarsat-C/Basic X.400 Interworking Specification [3].

3.3.8 Message Transfer Reports


An application may request that a Message Transfer Report be generated by appending the MTR
keyword parameter to a recipient address field (separated by a semicolon). For example, in the from-
mobile direction, the address

TELEX: 5512345; MTR

will generate a Message Transfer Report after the message has been received by the default LES.

3.3.8.1 Receiving a Message Transfer Report

The address field of the “From” recipient structure of message transfer report messages shall be
NULL. The name field of the “From” recipient shall be

Message Transfer Report

3.3.9 Delivery and Non-delivery Reports


Delivery reports and non-delivery reports shall have one of the following “From” addresses:

- CMC

- MES

- LES

- LES Gateway

The message originator should reflect the origin or the delivery or non-delivery report.

3.3.10 Receipt and Non-Receipt Reports


Receipt and non-receipt reports are generated by the receiving party. The rules for “To”, “From” and
“CC” addresses are as for ordinary messages.

3.3.11 Protocol Indications and Alarms


The originator of a protocol indication or alarm message should be MES.

3.3.12 Errors
When cmc_send() is called with an invalid address in the recipients field of the message argument, or
cmc_send_documents() is called with an invalid address in the recipient_addresses argument, the
function will return an error return code. If support for Inmarsat-C extensions has not been requested
then the error return code will be CMC_E_RECIPIENT_NOT_FOUND. If support for Inmarsat-C

Volume 2: User Services, Part 3: CMC Extensions, Page: 46


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

extensions has been requested then the least significant 16 bits of the error return code will be
CMC_E_RECIPIENT_NOT_FOUND and the most significant 16 bits will give more information about
the error. The error return codes derived in this way include the following:

Symbolic Name Meaning

The syntax of the address is invalid. (For


CMC_E_IMS_ADDR_SYNTAX example, the colon that should follow the prefix is
missing.)
CMC_E_IMS_ADDR_PREFIX Invalid prefix.
CMC_E_IMS_ADDR_ACKNOWLEDGEMENT Misuse of the ACKNOWLEDGEMENT keyword.
CMC_E_IMS_ADDR_ADDRESS Misuse of the ADDRESS keyword.
CMC_E_IMS_ADDR_AUTOMATIC Misuse of the AUTOMATIC keyword
CMC_E_IMS_ADDR_CANCEL Misuse of the CANCEL keyword
CMC_E_IMS_ADDR_COMMAND Misuse of the COMMAND keyword.
CMC_E_IMS_ADDR_DIRECTION Misuse of the DIRECTION keyword.
CMC_E_IMS_ADDR_DR Misuse of the DR keyword.
CMC_E_IMS_ADDR_DUPLICATE Misuse of the DUPLICATE keyword.
CMC_E_IMS_ADDR_ECHO Misuse of the ECHO keyword.
CMC_E_IMS_ADDR_EGCINTERVAL Misuse of the EGCINTERVAL keyword.
CMC_E_IMS_ADDR_EXTRA Misuse of the EXTRA keyword.
CMC_E_IMS_ADDR_FRAME Misuse of the FRAME keyword.
CMC_E_IMS_ADDR_ID Misuse of the ID keyword.
CMC_E_IMS_ADDR_INTERVAL Misuse of the INTERVAL keyword.
CMC_E_IMS_ADDR_LES Misuse of the LES keyword.
CMC_E_IMS_ADDR_MEMBER Misuse of the MEMBERS keyword.
CMC_E_IMS_ADDR_MTR Misuse of the MTR keyword.
CMC_E_IMS_ADDR_NAME Misuse of the NAME keyword.
CMC_E_IMS_ADDR_NATURE Misuse of the NATURE keyword.
CMC_E_IMS_ADDR_NOHEADERS Misuse of the NOHEADERS keyword.
CMC_E_IMS_ADDR_POSITION Misuse of the POSITION keyword.
CMC_E_IMS_ADDR_PROTOCOL Misuse of the PROTOCOL keyword.
CMC_E_IMS_ADDR_RANDOM Misuse of the RANDOM keyword.
CMC_E_IMS_ADDR_REGION Misuse of the REGION keyword.
CMC_E_IMS_ADDR_REPEATS Misuse of the REPEATS keyword.
CMC_E_IMS_ADDR_REPLY Misuse of the REPLY keyword.
CMC_E_IMS_ADDR_RR Misuse of the RR keyword.
CMC_E_IMS_ADDR_SEQNUM Misuse of the SEQNUM keyword.
CMC_E_IMS_ADDR_SERVICE Misuse of the SERVICE keyword.
CMC_E_IMS_ADDR_SPEED Misuse of the SPEED keyword.
CMC_E_IMS_ADDR_SUBADDRESS Misuse of the SUBADDRESS keyword.
CMC_E_IMS_ADDR_TIMEOFPOSITION Misuse of the TIMEOFPOSITION keyword.

The above error codes all have the most significant bit clear. An implementation may return other
error codes whose least significant 16 bits are CMC_E_RECIPIENT_NOT_FOUND. The most
significant bit of any such error code will be set. The meanings of such error codes are
implementation-defined.

Volume 2: User Services, Part 3: CMC Extensions, Page: 47


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

A "misuse of keyword" error code (CMC_E_IMS_ADDR_ACKNOWLEDGEMENT etc. in the above


list) is generated when:

- the keyword is supplied but is invalid in the context of the address (for example, the
ACKNOWLEDGEMENT keyword is supplied following the EGC: prefix),

- the keyword is not supplied but is required for the address (for example, the ID keyword is not
present in a poll area address), or

- the keyword is supplied but the contents of the field that it introduces are invalid (for example,
SERVICE = 12).

3.4 Message Types


CMC defines the following message types:

CMC: IPM

Interpersonal message. This is the normal and default message type for Inmarsat-C messaging and
so messages of this type will be sent without the keyword CONTENTTYPE in the Inmarsat-C Message
Header.

CMC: IP RN

Receipt notification (referred to in this document as receipt report) for an interpersonal message. A
receipt report indicates that a message has been read by the recipient. This document describes how
receipt reports can be requested over Inmarsat-C, but it is an implementation matter whether such
requests are responded to. The response, if made, should be a message with this message type.
The MES sending the receipt report (rather than the user requesting receipt notification) will pay for
the receipt report message and so the user should be given some control of receipt reports if they are
implemented.

CMC: IP NRN

Non-receipt notification (referred to in this document as non-receipt report). A non-receipt report


indicates that a message has been removed from the recipient's mailbox without being read (for
instance, the message has been discarded by the user of the service or it has been auto-forwarded to
another recipient). This document describes how non-receipt reports can be requested over
Inmarsat-C, but it is an implementation matter whether such requests are responded to. The
response, if made, should be a message with this message type.

CMC: DR

Delivery report. A delivery report indicates that the service was able to deliver a message to the
recipient. This corresponds to an Inmarsat-C Confirmation of delivery. It is recommended that
delivery notification messages include a copy of the message sent.

CMC: NDR

Non-delivery report. A non-delivery report indicates that the service was not able to deliver a
message to the recipient. This corresponds to an Inmarsat-C Confirmation of non-delivery. It is
recommended that non-delivery notifications include a copy of the message sent.

Other Types

Other message types may be specified in the message_type field of the message structure (see
Common Messaging Call API Section 3.9). The type will be carried over the Inmarsat-C EGC and

Volume 2: User Services, Part 3: CMC Extensions, Page: 48


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

messaging protocols if the CONTENTTYPE message header keyword is enabled. The mapping of
message_type fields to the CONTENTTYPE message header line is described in Section 5 of this
document. All messages sent using the data reporting, polling and land mobile alerting protocols will
be assumed to have type CMC:IPM on reception. These protocols cannot support the end to end
transfer of the message_type field.

3.5 Message Subject


The contents of the message subject for received messages is dependent on the Inmarsat-C protocol
used to transfer the message.

3.5.1 Inmarsat-C Messages


Message subjects can be transferred over the Inmarsat-C messaging service within a header added
to the start of the message (see Section 5). Inmarsat-C messages received without the header
keyword shall have an empty message subject.

3.5.2 Inmarsat-C EGCs


Message subjects can be transferred over the Inmarsat-C EGC service within a header added to the
start of the EGC (see Section 5). Inmarsat-C EGCs received without the header keyword shall have
the following subject text:

EGC: [priority];[service]

where [priority] and [service] are textual descriptions of the EGC priority and service types
respectively. The textual descriptions for the services should be identical to the SERVICE keyword
values used in EGC addressing (see Section 3.3.5). The textual descriptions for PRIORITY are LOW,
NORMAL, URGENT, MARITIMESAFETY, MARITIMEURGENCY, and MARITIMEDISTRESS.

3.5.3 Receiving Data Reports


Received data reports shall have a subject starting with the string:

Data Report

A CMC API implementation can, if desired, include additional information in the subject after the
above.

3.5.4 Receiving Polls


The subject of a received poll shall reflect the command type of the poll. The subject strings for the
different command types are as follows:

Command Subject String

00H Poll: Send Unreserved

01H Poll: Program Reserved

02H Poll: Initiate Reserved

03H Poll: Stop Reserved

04H Poll: Program Unreserved

05H Poll: Initiate Unreserved

Volume 2: User Services, Part 3: CMC Extensions, Page: 49


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

06H Poll: Stop Unreserved

07H Poll: Define MEM

08H Poll: MEM

09H Poll: Data Transmission

0AH Poll: Download DNID

0BH Poll: Delete DNID

All other command types should be shown on the command line as:

POLL: Command [xx]

where [xx] is a two or three digit decimal number corresponding to the command number contained in
the poll.

For example, a poll of command type 0AH would give a subject field of

POLL: Download DNID

and, a poll command type 60H would give a subject field of

POLL: Command 96

3.5.5 Land Mobile Alerts


Received Land Mobile Alerts shall have a subject line of:

Land Mobile Alert

3.5.6 Message Transfer Reports


Message Transfer Reports shall have a subject:

MTR: [message reference number];[subject]

where [message reference number] is the Inmarsat-C message reference number for the call
(Inmarsat-C message sequence number for EGCs) and [subject] is the subject of the message that
has been delivered to the LES.

Polls, data reports, and land mobile alerts do not have message reference numbers in which case the
Message Transfer Report subject will be

MTR: ;[subject]

Messages sent to poll, data report or land mobile alert addresses will not be included in the message
(because these protocols cannot support the Inmarsat-C headers) but the subject line can be used by
applications or users to match messages with their corresponding message transfer reports.

3.5.7 Delivery Reports


Delivery reports shall have the same subject as the original message but prefixed by DR: Non
delivery reports shall be prefixed by NDR:

Volume 2: User Services, Part 3: CMC Extensions, Page: 50


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.5.8 Receipt Reports


Receipt reports shall have the same subject as the original message but prefixed by RR: Non receipt
reports shall be prefixed by NRR:

3.6 Message Reference Numbers


CMC messages have a field message_reference. A CMC implementation should ensure that this
number is unique within a mailbox and may, if desired, encode the Inmarsat-C LES and message
reference number (for EGCs, the message sequence number) within the CMC message reference
number. Some mechanism should be provided to enable the user to determine the LES and
message reference number for both messages sent and received. This information is important for
troubleshooting purposes and enables the messages to be traced from message sending, through the
satellite protocols to reception at the destination. It is recommended that this information is included
in the text note of messages received (before the LES header, if present) at the discretion of the user.
A configuration option for this purpose can be provided. The format of the information at the start of
the text note shall be:

LES:[LES ID]
MSGREFERENCE:[reference number]

where [reference number] and [LES ID] are decimal numbers. The format of these lines is identical to
that used for message transfer reports.
Other information may also be encoded in the same [keyword]:[value] format. A single line of equals
signs should separate the information (if present) from LES header or start of text note.

3.7 Address Book


The level of address book support provided is up to the implementation. The CMC specification does
require, however, that all the CMC functions are present and so, at the very minimum, cmc_look_up()
must return the error code CMC_E_RECIPIENT_NOT_FOUND. cmc_look_up() is designed to
resolve friendly names to addresses, but it is recommended that, in addition to ordinary addresses,
cmc_look_up() be used for an application, or a user, to view the DNIDs available for sending data
reports and receiving polls.

3.8 Off-Line Working


A CMC implementation can, if desired, return CMC_SUCCESS when cmc_send() is called and the
MES is not connected (or cannot see the satellite) and spool such messages until such time as the
MES is able to transmit them. If spooling of messages is allowed by the implementation,
consideration needs to be given as to how such messages are deleted or updated and at what time
they are considered undeliverable.

Messages previously received, may, or may not be readable without the MES connected.

If the CMC implementation does not support any off-line working, it is recommended that the error
code CMC_E_SERVICE_UNAVAILABLE is returned when cmc_logon() is called. An application
receiving an error at this stage can then signal an error to the user, or retry, whichever is appropriate.

Volume 2: User Services, Part 3: CMC Extensions, Page: 51


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4 CMC Extensions

4.1 Introduction
This section describes the additional data types, functions, and extension sets for Inmarsat-C
services. In addition to the extension sets defined here, any of the extensions defined in
CMC_XS_COM may be included. In particular, the following are required:

CMC_X_COM_SUPPORT_EXT
CMC_X_COM_TIME_RECEIVED
CMC_X_COM_PRIORITY

An additional function, cmc_x_set_configuration(), has been defined that allows an application to


change various defaults such as the default LES ID and issue specific commands to an MES.
Defaults can exist within a CMC API implementation that are defined in an initialisation file or implied
by the username usernames (if usernames are implemented). These defaults may be overridden by
an application by adding extensions to cmc_logon(). This document does not, however, describe any
mechanism to change the username or initialisation file defaults -- this is left to the particular CMC API
implementation. All defaults for the session can be overridden using cmc_x_set_configuration() and
some defaults may be overridden when messages are sent by including particular extensions or
address line keywords and parameters.

4.2 Additional Data Types

4.2.1 CMC_X_IMS_channel_number
NAME

Channel Number - the Inmarsat-C Channel Number

C-DECLARATION

typedef CMC_uint16 CMC_X_IMS_channel_number;

DESCRIPTION

A data value of this type is an Inmarsat-C channel number (see Inmarsat-C SDM Volume 1, Chapter
2, Section 6).

4.2.2 CMC_X_IMS_geographical_coordinates
NAME

Geographical Co-ordinates.

C-DECLARATION

typedef struct {
CMC_uint16 longitude_degrees;
CMC_uint16 longitude_minutes;
CMC_uint16 longitude_hundredths;
CMC_uint16 latitude_degrees;
CMC_uint16 latitude_minutes;
CMC_uint16 latitude_hundredths;
CMC_char north_south;
CMC_char east_west;
} CMC_X_IMS_geographical_coordinates;

Volume 2: User Services, Part 3: CMC Extensions, Page: 52


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

DESCRIPTION

A structure for geographical co-ordinates to be passed between the DCE and DTE. If north_south has
value "N" and longitude_degrees has value 180, then the geographical position is unavailable and the
contents of the other fields are meaningless.

north_south Value is either N or S.


east_west Value is either E or W.

4.2.3 CMC_X_IMS_keyword_value_pair_list
NAME

Keyword Value Pair List

C-DECLARATION

typedef struct {
CMC_string keyword_string;
CMC_string value_string;
} CMC_X_IMS_keyword_value_pair_list;

DESCRIPTION

This is a list of keyword and value pairs. The keywords end in a colon (":"), and the value strings can
include any IA5 characters except CR, LF, or null (ASCII zero).

4.2.4 CMC_X_IMS_land_mobile_alert
NAME

Land Mobile Alert - details of an LMA sent from an MES to an LES.

C-DECLARATION

typedef struct {
CMC_uint8 nature_of_alert;
CMC_X_IMS_geographical_coordinates land_position;
CMC_boolean manual_position;
CMC_uint8 time_of_position;
CMC_uint8 speed;
CMC_uint8 direction_of_travel;
CMC_uint8 extra_info;
} CMC_X_IMS_land_mobile_alert;

DESCRIPTION

1 nature_of_alert: This code conveys information on the nature of the alert. The default value is 0.
It should be set according to the following table:

0 Undesignated (default)
1 Ambulance
2 Fire
3 Police
4 Hijack
5 Under attack / Threat of attack
6 Dangerous cargo leak / spill
7 Accident

Volume 2: User Services, Part 3: CMC Extensions, Page: 53


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

8 Vehicle Breakdown
9 Severe Weather
10-15 Spare

2 land_position: The current position of the MES. If the position is invalid (latitude set to 180
degrees North), the current MES position should be used.

3 manual_position: Indicates whether or not the position was manually (DTE) entered. The field
has the following coding:

CMC_FALSE Automatic
CMC_TRUE Manual

4 time_of_position: An indication of when was the land_position last updated. This field can take
the following values:

0 < 1 minute old


1 1 to < 5 minutes old
2 5 to < 30 minutes old
3 30 to < 60 minutes old
4 1 hour or older
5 Not Available

5 speed: The following code should be used:

0 Stopped 0 km/h
1 Slow < 20 km/h
2 Medium 20 to 70 km/h
3 Fast > 70 km/h

6 direction_of_travel: The following codes should be used:

0 N 337.5 to < 22.5 degrees


1 NE 22.5 to < 67.5 degrees
2 E 67.5 to < 112.5 degrees
3 SE 112.5 to < 157.5 degrees
4 S 157.5 to < 202.5 degrees
5 SW 202.5 to < 247.5 degrees
6 W 247.5 to < 292.5 degrees
7 NW 292.5 to < 337.5 degrees

7 extra_info: One byte of application-specific information to be carried in the LMA packet.

4.2.5 CMC_X_IMS_mes_number
NAME

MES Number - Inmarsat assigned Mobile Earth Station number

C-DECLARATION

typedef CMC_uint32 CMC_X_IMS_mes_number;

DESCRIPTION

This is a 9 digit decimal number of the format


X1X2X3X4X5X6X7X8X9
where X1 is 4.

Volume 2: User Services, Part 3: CMC Extensions, Page: 54


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Each MES has a unique MES number.

4.2.6 CMC_X_IMS_message_transfer_report
NAME

Message Transfer Report - details of a message transfer

C-DECLARATION

typedef struct {
CMC_uint32 size;
CMC_sint16 message_packets;
CMC_sint16 repeated_message_packet_count;
CMC_sint16 retransmission_count;
CMC_time submission_time;
CMC_time start_transmit_time;
CMC_time end_transmit_time;
CMC_uint32 message_reference_number;
CMC_X_IMS_station_id les;
CMC_string addresses;
} CMC_X_IMS_message_transfer_report;

DESCRIPTION

A data value of this type is a message transfer report and gives an application information on the
submission of a message over the Inmarsat-C system (i.e. to the LES in from-mobile calls, or to the
MES in to-mobile calls). No information is included on the terrestrial retransmissions or the terrestrial
delivery time. A message transfer report has the following fields:

1 size: This is the size in bytes of the message submitted to the LES. The size should include any
message header added by the CMC implementation but should exclude addressing information
carried on the message channel that the user is not charged for.

2 message_packets: In the from-mobile case this is the number of Inmarsat-C packets


transmitted and includes additional addressing information that may be added to the start of the
message. If this information is not available to the CMC implementation or in the to-mobile
case, this value should be -1.

3 repeated_message_packet_count: This is the number of repeated message packets sent. If a


particular packet had to be sent more than once, then this value should be incremented each
time the packet is retransmitted. If this information is not available to the CMC implementation,
this value should be -1.

4 retransmission_count: This is the number of message retransmissions where each


retransmission can be one or more packets. More than one packet can be retransmitted
together, repeated_message_packet_count indicating the total number of packets and
retransmission_count indicating the total number of groups of retransmitted packets. If this
information is not available to the CMC implementation, this value should be -1.

5 submission_time: This is the time that the message was submitted by the application. It may
not be the same as start_transmit_time if the MES is busy sending.

6 start_transmit_time: This is the time that the MES started the from mobile message protocol,
i.e. the time that the MES queue the Assignment Request for transmission to the LES or NCS.
If this information is not available to the CMC implementation, all fields in the time structure
should contain zeros.

Volume 2: User Services, Part 3: CMC Extensions, Page: 55


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

7 end_transmit_time: This is the time that the MES completed the from mobile message
protocol, i.e. the time that the MES received the Clear packet from the LES.

8 message_reference_number: This is the Inmarsat-C message reference number for the


message transmitted.

9 les: This is the station ID of the LES used for the call.

10 addresses: The address or addresses to which this report refers. Sending a multiply addressed
message may result in more than one transfer to an LES. Each successful LES communication
may result in a message transfer report and the addresses field should be the intended
recipients of that LES transfer only. The format of the address should be as defined in Section
3.3 with multiply addresses messages separated by commas.

4.2.7 CMC_X_IMS_ncs_information
NAME

NCS Information - Inmarsat-C NCS TDM Channel ID and NCS TDM Channel Number.

C-DECLARATION

typedef struct {
CMC_X_IMS_station_id ncs; /* NCS ID */;
CMC_X_IMS_channel_number channel_number;
} CMC_X_IMS_ncs_information;

DESCRIPTION

Values of this type indicate the channel number for a particular NCS ID. This structure is used for
viewing and modifying the list of known NCS IDs and associated channel numbers held within a
mobile.

4.2.8 CMC_X_IMS_network_id
NAME

Network ID - Inmarsat-C Data Reporting or Enhanced Group Call Closed Network ID (DNID or ENID)

C-DECLARATION

typedef struct {
CMC_uint16 id; /* DNID or ENID*/;
CMC_X_IMS_station_id les; /* LES ID */;
CMC_uint8 member; /* Member Number */;
CMC_string descrip; /* First 25 characters of the
Free field in the download
command */;
CMC_boolean inhibited;
} CMC_X_IMS_network_id;

DESCRIPTION

Values of this type indicate a particular downloaded DNID or ENID. A DNID is always associated with
a particular LES and can only be used with an MES after the DNID has been downloaded to the MES.
An ENID is not associated with an LES and does not have a member number. The les and member
fields should be ignored when using this structure for ENIDs.

Volume 2: User Services, Part 3: CMC Extensions, Page: 56


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

If the ENID or DNID has been inhibited, the inhibited field will be set to CMC_TRUE.

4.2.9 CMC_X_IMS_network_information
NAME

Network Information

C-DECLARATION

typedef struct {
CMC_X_IMS_station_id les_id;
CMC_uint32 les_status;
CMC_uint32 les_service;
CMC_X_IMS_channel_number channel_number;
} CMC_X_IMS_network_information;

DESCRIPTION

This structure shows, for an LES, the status, services and LES TDM channel number.

1 les_id: The LES ID.

2 les_status: Status 8 bit mask as defined in Inmarsat-C SDM, Volume 4, Chapter 2, Section
3.1.4.5 is in the lower 8 bits of les_status. If the status information is not available the value
shall be CMC_X_IMS_VALUE_UNDEFINED.

3 les_services: Services 16 bit mask as defined in Inmarsat-C SDM, Volume 4, Chapter 2,


Section 3.1.4.6 is in the lower 16 bits of les_services. If the status information is not available
the value shall be CMC_X_IMS_VALUE_UNDEFINED.

4 channel_number: The channel number of the first, or only, LES TDM channel. If the information
cannot be determined, the value shall be zero.

4.2.10 CMC_X_IMS_pvt_result
NAME

PVT Result - result of a Performance Verification Test.

C-DECLARATION

typedef struct {
cmc_uint16 attempts;
cmc_uint16 bber;
cmc_uint16 forward_attempts;
cmc_uint16 return_attempts;
cmc_uint16 distress_alert_test;
cmc_uint16 signal_strength;
cmc_uint16 overall;
} CMC_X_IMS_pvt_result;

DESCRIPTION

Integer representations of the contents of the Attempts, BBER, Forward Attempts, Return Attempts,
Distress Alert Test, Signal Strength and Overall Result fields described in Sections 3.18.1.1 through
3.18.1.7 of volume 4 of the Inmarsat-C System Definition Manual.

Volume 2: User Services, Part 3: CMC Extensions, Page: 57


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.2.11 CMC_X_IMS_station_id
NAME

Station ID - Inmarsat-C LES, or NCS, ID number.

C DECLARATION

typedef CMC_uint16 CMC_X_IMS_station_id;

DESCRIPTION

A data value of this type is the station ID (LES ID or NCS ID) as defined in the Inmarsat-C SDM. The
station ID includes the Ocean Region number and so indicates both the ocean region and the
particular station within the ocean region. The number is the decimal representation of the ID and is
of the form rxx where r is a decimal digit from 0 to 3 indicating the ocean region and xx is a two digit
decimal number between 00 and 43.

4.2.12 CMC_X_IMS_timestamped_geographical_coordinates
NAME

Timestamped Geographical Co-ordinates.

C-DECLARATION

typedef struct {
CMC_X_IMS_geographical_coordinates coordinates;
CMC_boolean timestamp_valid;
CMC_time timestamp;
} CMC_X_IMS_timestamped_geographical_coordinates;

DESCRIPTION

A structure for timestamped geographical coordinates to be passed between the DCE and DTE.
Value of coordinates is a geographical position.
If timestamp_valid has value CMC_TRUE, then the value of timestamp is the time at which the
position was last updated.

4.3 Additional Functions


The following additional function is defined:

4.3.1 X_Set_Configuration
NAME

Set Configuration - configure access to the Inmarsat-C network.

Volume 2: User Services, Part 3: CMC Extensions, Page: 58


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

SYNOPSIS

#include <xcmcims.h>

CMC_return_code
cmc_x_set_configuratioN (
CMC_session_id session,
CMC_ui_id ui_id,
CMC_extension *set_configuration_extensions
);

DESCRIPTION

This function allows the calling application to configure access to the Inmarsat-C
network, set various defaults and perform certain Inmarsat-C specific actions.

ARGUMENTS

Session (Session ID)

Opaque session handle which represents a session with the messaging service.

If the session handle is invalid, then the error CMC_E_INVALID_SESSION_ID is returned.

UI Id (UI Id)

An identifier for a User Interface (e.g. the parent-window handle for the calling application) for use in
resolving any questions which might otherwise result in an error.
Ignored if UI is not supported by the CMC implementation.

Set_Configuration Extensions (Extension)

A pointer to an array of CMC_extension structures for this function. The array may contain both input
extensions for providing additional information to the function and output extensions for receiving
information from the function. A value of NULL indicates that the caller is not using any extensions.
See the extensions structure for more information.

RESULTS

Set Configuration Extensions (Extension)

If output extensions were passed to the function in the extensions list, the results from the service will
be available in the extension. See the extensions structure for more information.

Return Code (Return Code)

Whether the function succeeded or not, and if not, why. It may be success or one of the value listed
under ERRORS below.

ERRORS

CMC_E_FAILURE
CMC_E_INSUFFICIENT_MEMORY
CMC_E_INVALID_FLAG
CMC_E_INVALID_PARAMETER
CMC_E_INVALID_SESSION_ID
CMC_E_INVALID_UI_ID
CMC_E_UNSUPPORED_FLAG

Volume 2: User Services, Part 3: CMC Extensions, Page: 59


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

CMC_E_UNSUPPORED_FUNCTION_EXT
CMC_E_USER_NOT_LOGGED_ON

4.4 Extension Sets

4.4.1 General Extensions (CMC_XS_IMS_GEN)


This is a general Inmarsat-C extension set containing extensions common to both the MES and the
LES.

4.4.1.1 CMC_X_IMS_GEN_HEADERS

Description:

This extension allows the application to decide what information, if any, is to be included in the
Inmarsat-C Message Header.

This extension can be used with:

cmc_logon()
to indicate the default headers for this session

cmc_x_set_configuration()
to change the default headers for this session

cmc_query_configuration()
to determine the default headers for this session

cmc_send()
to override the defaults when sending a particular message

Used-by:

cmc_logon()
cmc_x_set_configuration()
cmc_send()
cmc_query_configuration()

Input

extension_flags
No further flags are defined

item_data
Not used.

item_reference
A pointer to an array of elements of type CMC_uint8. The array has
CMC_X_IMS_NR_OF_KWDS elements. Each element corresponds to a keyword. Symbolic
names that can be used to index the array are defined in the Inmarsat-C CMC Extensions
header file. If the element is non-zero then the header line with the associated keyword will be
included in the Inmarsat-C message (unless the default value associated with the keyword is
appropriate). If the element is zero then the header line will not be included.

Output

extension_flags
No further flags are defined

Volume 2: User Services, Part 3: CMC Extensions, Page: 60


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

item_data
Not used.

item_reference
A pointer to an array of elements of type CMC_uint8. The array has
CMC_X_IMS_NR_OF_KWDS elements. Each element corresponds to a keyword. Symbolic
names that can be used to index the array are defined in the Inmarsat-C CMC Extensions
header file. If the element is non-zero then the header line with the associated keyword will be
included in the Inmarsat-C message (unless the default value associated with the keyword is
appropriate). If the element is zero then the header line will not be included.

4.4.1.2 CMC_X_IMS_GEN_IP_REFERENCE

Description

This extension is used to indicate the IP message reference for the message received or transmitted.
This information is carried in the OURREF header line.

Used-by:

cmc_message
cmc_message_summary

Input
extension_flags
No further flags are defined.

item_data
NULL

item_reference
Pointer to CMC_string. If there is no IP message reference the item_reference shall be NULL.

Output

extension_flags
No further flags are defined.

item_data
NULL

item_reference
Pointer to CMC_string. If there is no IP message reference, the item_reference shall be NULL.

4.4.1.3 CMC_X_IMS_GEN_LAND_MOBILE_ALERT_DATA

Description:

This extension reflects additional information that is carried in a Land Mobile Alert message from an
MES to an LES.

Application Developer’s Note:

If the address indicates a Land Mobile Alert address, and if this extension is not included with the
message to be sent, then the contents of the Land Mobile Alert will use the message data held in the
text note and any attachments.

Volume 2: User Services, Part 3: CMC Extensions, Page: 61


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

If the address indicates a Land Mobile Alert address, and if this extension is included with the
message to be sent, then the contents of the Land Mobile Alert will be determined by the contents of
the structure pointed to by this extension.

If the address does not indicate a Land Mobile Alert address, this extension will be ignored.

Any parameter included in the address overwrites the data included in the extension.

Land Mobile Alerts received will have this extension on the message (if requested with
CMC_X_COM_SUPPORT at cmc_logon()) and will also have the land mobile alert contents stored in
the first attachment.

Used-by:

CMC_message
CMC_message_summary

Input

extension_flags
No further flags are defined.

item_data
Not used.

item_reference
Pointer to a CMC_X_IMS_land_mobile_alert. The current position stored in the MES will be
used if the latitude in the land position field is 180 degrees North. Whenever the current
position is set by the MES, the time of position field should be set accordingly and the
time_of_position field in the extension structure ignored.

Output

extension_flags
No further flags are defined.

item_data
Not used.

item_reference
Pointer to a CMC_X_IMS_land_mobile_alert.

4.4.1.4 CMC_X_IMS_GEN_LES_ID

Description:

Data extension for the LES ID used, or to be used, for the delivery of a message.

This extension can be used with:

cmc_logon()
to indicate the default LES for sending a message in this session,

cmc_message
to indicate the LES for a message.

cmc_message_summary
to indicate the LES for each message

Volume 2: User Services, Part 3: CMC Extensions, Page: 62


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

cmc_x_set_configuration()
to change the default LES for sending a message in this session

If, when a message is submitted to an MES for transmission, the LES to be used lies outside of the
current Ocean Region, the MES should automatically login to the new ocean region4. If the login fails,
the MES should remain logged in to the original Ocean Region and a non-delivery message returned
to the application.

This extension, if included with a message to be sent, overrides the current default LES for the
session. If the LES parameter is, however, also included in the address line, this extension will be
ignored and the LES given in the address will be used to send the message.

Used-by:

cmc_logon()
cmc_message
cmc_message_summary
cmc_x_set_configuration()

Input

extension_flags
No further flags are defined

item_data
CMC_X_IMS_station_id

item_reference
NULL

Output

extension_flags
No further flags are defined

item_data
CMC_X_IMS_station_id

A value of CMC_X_IMS_VALUE_UNDEFINED indicates that the LES used for the call is
unknown.

item_reference
NULL

4.4.1.5 CMC_X_IMS_GEN_MESSAGE_HEADERS

Description:

This extension reflects any additional information carried in a header at the start of an Inmarsat-C
message. Each header line is in two parts, a keyword and then a value.

This is a data extension added to the message structure. If required for received messages, the
application must request this extension using CMC_X_COM_SUPPORT_EXT with cmc_logon(). All
keywords and their values will be included on message reception including those recognised by the
CMC implementation. Known keyword abbreviations in message headers received will be expanded
to full keyword names. On message sending, recognised keywords may be abbreviated or expanded

4 The login procedure cannot be activated on GMDSS MESs from additional DTEs. Implementations connected
to such MESs should send an non-delivery report if the LES is not within the current Ocean Region.

Volume 2: User Services, Part 3: CMC Extensions, Page: 63


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

by the CMC implementation. If a conflict exists between this extension and header lines generated
automatically by the CMC implementation (i.e. if this extension includes header keywords known to
and used by the CMC implementation) the values for the header keywords given by this extension
take presence.

Application Developer’s Note:

Care should be taken when using this extension. Some information, such as the message subject, is
carried over Inmarsat-C by adding a header to the message so keywords already defined should be
used with caution.

Used-by:

CMC_message
CMC_message_summary

Input

extension_flags
No further flags are defined

item_data
Number of message header keyword and value pairs.

item_reference
CMC_X_IMS_keyword_value_pair_list

Output

extension_flags
No further flags are defined

item_data
Number of message header keyword and value pairs.

item_reference
CMC_X_IMS_keyword_value_pair_list

4.4.1.6 CMC_X_IMS_GEN_MESSAGE_TRANSFER_REPORT

Description:

This extension is included with a message transfer report generated by the CMC implementation
when reports have been requested.

This extension should only be present with message transfer reports; the content of message
transfer report text notes is defined in Section 3.2.5.

Used-by:

CMC_message
CMC_message_summary

Input

extension_flags
No further flags are defined.

Volume 2: User Services, Part 3: CMC Extensions, Page: 64


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

item_data
Not used.

item_reference
NULL

Output

extension_flags
No further flags are defined.

item_data
Not used.

item_reference
CMC_X_IMS_message_transfer_report

4.4.1.7 CMC_X_IMS_GEN_MSG_RECEIVED

Description

This extension is a flag used to indicate whether a message in a message_summary structure has
been received or not. Messages that have not been received may have been sent or may be stored
in the message store unsent.

This extension allows an application or user agent to determine which messages listed were created
by the user and which have been received.

Used-by:

message_summary

Input

extension_flags
No further flags are defined.

item_data
Not used.

item_reference
Not used.

Output

extension_flags
No further flags are defined.

item_data
CMC_TRUE indicates that the message has been received (i.e. has been sent over Inmarsat-C
and retrieved (or received) from an LES or MES).

CMC_FALSE indicates that the message has been received.

item_reference
Not used.

Volume 2: User Services, Part 3: CMC Extensions, Page: 65


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.4.1.8 CMC_X_IMS_GEN_MSG_STATUS_ENQUIRY

Description

This extension enables an application to determine the status of a message previously sent. The
status may show that the message transfer is in progress, has been delivered, or failed to be
delivered. The format of the message received is identical to the delivery report format but messages
in progress should have the title “In Progress”.

This extension assumes that cmc_list() will give both messages that have been sent as well as those
that have been received so that the CMC message reference number of the sent message can be
passed to cmc_act_on().

(CMC implementations with a user interface may provide an additional and alternative mechanism for
users to initiate message status enquiries).

Used-by:

cmc_act_on()

Input

extension_flags
No further flags are defined.

item_data
Not used.

item_reference
Not used.

Output

extension_flags
No further flags are defined.

item_data
CMC_FALSE indicates status enquiry request failed
CMC_TRUE indicates status enquiry requested.

item_reference
Not used.

4.4.1.9 CMC_X_IMS_GEN_PRESENTATION

Description:

This extension allows the Inmarsat-C presentation code to be determined. Using this extension with
cmc_logon() defines a default presentation code for messages sent within the logon session. This
default can be changed with cmc_x_set_configuration(). The default presentation code for sending a
message can be overridden by using the extension with a message to be sent. An application may
request this extension be provided with received messages using CMC_X_COM_SUPPORT with
cmc_logon(). If the LES or MES is not able to provide the information for a received message, the
extension should still be included but will have a value of CMC_X_IMS_UNKNOWN.

CMC_X_IMS_FIVE_BIT corresponds to the Inmarsat-C presentation code ITA2,


CMC_X_IMS_SEVEN_BIT to IA5, and CMC_X_IMS_EIGHT_BIT to Data or Basic X400. The
translation of the data into the format required for transmission is done either by the API
implementation or by the Inmarsat-C MES or LES. All message data passed to or from the API is in 8

Volume 2: User Services, Part 3: CMC Extensions, Page: 66


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

bit format. Where a conflict occurs between the presentation code extension and the address type,
e.g. presentation code CMC_X_IMS_FIVE_BIT and an X.400 address, or the presentation code and
the body type, e.g. presentation code CMC_X_IMS_SEVEN_BIT and a binary attachment, the API
implementation will (silently) ignore the presentation code extension and use the most appropriate
presentation code.

Used-by:

cmc_logon()
cmc_x_set_configuration()
CMC_message
CMC_message_summary

Input

extension_flags
No further flags are defined

item_data
CMC_X_IMS_FIVE_BIT
CMC_X_IMS_SEVEN_BIT
CMC_X_IMS_EIGHT_BIT

item_reference
NULL

Output

extension_flags
No further flags are defined

item_data
CMC_X_IMS_FIVE_BIT
CMC_X_IMS_SEVEN_BIT
CMC_X_IMS_EIGHT_BIT
CMC_X_IMS_UNKNOWN

item_reference
NULL

4.4.1.10 CMC_X_IMS_GEN_PRIORITY

Description:

The priority to be used for a particular message. This extension is a superset of


CMC_X_COM_PRIORITY and includes the three priorities defined by the common extension set plus
additional Inmarsat-C priorities. If this extension is used together with CMC_X_COM_PRIORITY on
input this priority takes precedence. Both extensions may be requested for output if desired.
Messages having priorities CMC_X_COM_URGENT, CMC_X_IMS_MARITIMESAFETY,
CMC_X_IMS_MARITIMEURGENCY and CMC_X_IMS_MARITIMEDISTRESS are all shown as
having priority CMC_X_COM_URGENT with the CMC_X_COM_PRIORITY extension.

At the time of writing, messages of priority CMC_X_COM_LOW and CMC_X_COM_URGENT are


sent at the same priority over the Inmarsat-C network as messages of priority
CMC_X_COM_NORMAL. Messages of priority CMC_X_IMS_MARITIMESAFETY,
CMC_X_IMS_MARITIMEURGENCY and CMC_X_IMS_MARITIMEDISTRESS are only supported for
the sending and receiving of EGCs (sending by maritime safety service providers only). If included
with messages to be sent, the extension will be ignored and the message sent with
CMC_X_COM_NORMAL priority.

Volume 2: User Services, Part 3: CMC Extensions, Page: 67


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Used-by:

message
message_summary

Input

extension_flags
No further flags are defined

item_data
The item data shall be one of:
CMC_X_COM_NORMAL
CMC_X_COM_URGENT
CMC_X_COM_LOW
CMC_X_IMS_MARITIMESAFETY
CMC_X_IMS_MARITIMEURGENCY
CMC_X_IMS_MARITIMEDISTRESS

item_reference
NULL

Output

extension_flags
No further flags are defined

item_data
The item data shall be one of:
CMC_X_COM_NORMAL
CMC_X_COM_LOW
CMC_X_COM_URGENT
CMC_X_IMS_MARITIMESAFETY
CMC_X_IMS_MARITIMEURGENCY
CMC_X_IMS_MARITIMEDISTRESS

item_reference
NULL

4.4.1.11 CMC_X_IMS_GEN_REQUEST_DELIVERY_REPORT

Description:

This extension indicates whether a delivery report should be generated for the Inmarsat-C messaging
and EGC protocols (it has no effect for poll, data reports or land mobile alerts).

Including the extension in cmc_logon() sets the default for the session, but it can be overwritten at any
time by using cmc_x_set_configuration(), or, set on a per recipient basis. The current default setting
can be queried by using cmc_query_configuration().

Including the extension with a recipient may result in delivery reports for all recipient with the same
destination network.

Including the DR keyword parameter in the address will result in delivery confirmations requested
regardless of the item_data value in this extension. Recipients in "To" and "CC" lines in the
Inmarsat_C message header will include the DR parameter keyword if either delivery confirmations
are requested using the address parameter or using this extension.

Volume 2: User Services, Part 3: CMC Extensions, Page: 68


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Used-by:

cmc_x_set_configuration()
cmc_query_configuration()
cmc_logon()
cmc_recipient

Input

extension_flags
No further flags are defined.

item_data
CMC_TRUE Delivery Notification Requested
CMC_FALSE Delivery Notification Not Requested

item_reference
NULL

Output

extension_flags
No further flags are defined

item_data
CMC_TRUE Delivery Notification Requested
CMC_FALSE Delivery Notification Not Requested.

item_reference
NULL

4.4.1.12 CMC_X_IMS_GEN_REQUEST_MESSAGE_TRANSFER_REPORT

Description:

This extension indicates whether message transfer reports should be generated. Including the
extension in cmc_logon() sets the default for the session, but it can be overwritten at any time by
using cmc_x_set_configuration(), or, on a message by message basis by including the extension with
cmc_send().

Used-by:

cmc_x_set_configuration()
cmc_query_configuration()
cmc_logon()
cmc_send()

Input

extension_flags
No further flags are defined.

item_data
CMC_TRUE if message transfer reports are requested
CMC_FALSE if message transfer reports are not requested

item_reference
NULL

Volume 2: User Services, Part 3: CMC Extensions, Page: 69


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Output

extension_flags
No further flags are defined

item_data
CMC_TRUE if message transfer reports are requested
CMC_FALSE if message transfer reports are not requested.

item_reference
NULL

4.4.1.13 CMC_X_IMS_GEN_REQUEST_RECEIPT_REPORT

Description:

A sending application requests a receipt and non-receipt reports by including this extension with a
recipient structure for a message to be sent using the Inmarsat-C messaging and EGC protocols (it
has no effect for polls, data reports or land mobile alerts). If the Inmarsat-C “To” and “CC” header
lines are enabled, the information that a receipt report was requested will be presented to a receiving
application using this extension (if requested using CMC_X_COM_SUPPORT) and also by the
presence of the RR keyword in the address.

In order for the CMC implementation, user, or application to match receipt reports with the
corresponding message sent, the message should contain a unique IP reference. Applications
should use the CMC_X_IMS_GEN_IP_REFERENCE extension for this purpose.

Used-by:

cmc_recipient

Input

extension_flags
No further flags are defined

item_data
CMC_FALSE Receipt and non-receipt reports not requested
CMC_TRUE Receipt and non-receipt reports requested

item_reference
NULL

Output

extension_flags
Same as input.

item_data
CMC_FALSE Receipt and non-receipt reports not requested
CMC_TRUE Receipt and non-receipt reports requested

item_reference
NULL

Volume 2: User Services, Part 3: CMC Extensions, Page: 70


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.4.1.14 CMC_X_IMS_GEN_REQUEST_REPLY

Description:

A sending application requests a reply by including this extension with a recipient structure for a
message to be sent using the Inmarsat-C messaging and EGC protocols (it has no effect for polls,
data reports or land mobile alerts). If the Inmarsat-C “To” and “CC” header lines are enabled, the
information that a receipt report was requested will be presented to a receiving application using this
extension (if requested using CMC_X_COM_SUPPORT) and also by the presence of the REPLY
keyword in the “To” or “CC” address.

In order for the CMC implementation, user, or application to match receipt reports with the
corresponding message sent, the message should contain a unique IP reference. Applications
should use the CMC_X_IMS_GEN_IP_REFERENCE extension for this purpose.

Used-by:

cmc_recipient

Input

extension_flags
No further flags are defined.

item_data
CMC_FALSE Reply not requested
CMC_TRUE Reply requested

item_reference
NULL

Output

extension_flags
No further flags are defined.

item_data
CMC_FALSE Reply not requested
CMC_TRUE Reply requested

item_reference
NULL

4.4.1.15 CMC_X_IMS_GEN_YOUR_IP_REFERENCE

Description:

This extension is used to indicate the IP message reference for the message received or transmitted.
This information is carried in the YOURREF header line.

Used-by:

cmc_message
cmc_message_summary

Input

extension_flags
No further flags are defined.

Volume 2: User Services, Part 3: CMC Extensions, Page: 71


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

item_data
NULL

item_reference
Pointer to CMC_string. If there is no IP message reference, the item_reference shall be NULL.

Output

extension_flags
No further flags are defined.

item_data
NULL

item_reference
Pointer to CMC_string. If there is no IP message reference, the item_reference shall be NULL.

4.4.2 MES Extensions (CMC_XS_IMS_MES)


This is an Inmarsat-C extension set for use with applications connected to the MES. Data Reporting
and Polling extensions are separate.

4.4.2.1 CMC_X_IMS_MES_ABORT_CURRENT_OPERATION

Description:

Calling cmc_x_set_configuration() with this extension causes the MES to abort the current operation
in progress.

It may not be possible to abort particular operations, or, if the MES has more than one DTE,
operations initiated from other DTEs.

Used-by:

cmc_x_set_configuration()

Input

extension_flags
No further flags are defined.

item_data
Not used.

item_reference
NULL

Output

extension_flags
No further flags are defined.

item_data
One of the following values is returned:
CMC_X_IMS_SUCCESS
CMC_X_IMS_NO_CURRENT_OPERATION
CMC_X_IMS_UNABLE_TO_ABORT_CURRENT_OPERATION

Volume 2: User Services, Part 3: CMC Extensions, Page: 72


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

item_reference
NULL

4.4.2.2 CMC_X_IMS_MES_AVAILABLE_MES_MEMORY

Description:

This extension gives the approximate number of bytes available for messaging within the MES.

Used-by:

cmc_query_configuration()

Input

extension_flags
No further flags are defined.

item_data
Unused.

item_reference
NULL

Output

extension_flags
No further flags are defined.

item_data
The memory available in bytes. If CMC_X_IMS_VALUE_UNDEFINED is returned, this
indicates that the amount of free memory could not be determined.

item_reference
NULL

4.4.2.3 CMC_X_IMS_MES_BB_ERROR_RATE

Description:

This extension indicates the number of Inmarsat-C bulletin board packets received in error in the last
100 frames (approximately 15 minutes). The number will be in the range 0 to 100.

Used-by:

cmc_query_configuration()

Input

extension_flags
No further flags are defined.

item_data
Unused.

item_reference
NULL

Volume 2: User Services, Part 3: CMC Extensions, Page: 73


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Output

extension_flags
No further flags are defined.

item_data
The bulletin board error rate (0 to 100). If the information is not available, the value
CMC_X_IMS_VALUE_UNDEFINED shall be returned.

item_reference
NULL

4.4.2.4 CMC_X_IMS_MES_CLEAR_WAITING_MESSAGES

Description:

Calling cmc_x_set_configuration() with this extension causes the MES to delete all messages that are
waiting to be sent (if it is possible for the MES to do so).

Used-by:

cmc_x_set_configuration()

Input

extension_flags
No further flags are defined.

item_data
Not used.

item_reference
NULL

Output

extension_flags
No further flags are defined.

item_data
The number of messages that were deleted. If CMC_X_IMS_VALUE_UNDEFINED is returned,
this indicates that an unknown number of messages were deleted (including the possibility that
the operation was unsuccessful).

item_reference
NULL

4.4.2.5 CMC_X_IMS_MES_CURRENT_ACTIVITY

Description:

This extension shows the current MES activity.

Used-by:

cmc_query_configuration()

Volume 2: User Services, Part 3: CMC Extensions, Page: 74


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Input

extension_flags
No further flags are defined.

item_data
Unused.

item_reference
NULL

Output

extension_flags
No further flags are defined

item_data
At least the following values will be supported but there may be others specific to the CMC API
implementation:
CMC_X_IMS_IDLE
CMC_X_IMS_SENDING_MESSAGE
CMC_X_IMS_RECEIVING_MESSAGE
CMC_X_IMS_SENDING_DATA_REPORT
CMC_X_IMS_LOGGING_IN
CMC_X_IMS_LOGGING_OUT
CMC_X_IMS_PVT
CMC_X_IMS_FORCE_CLEARING
CMC_X_IMS_LAND_EMERGENCY_ALERT
CMC_X_IMS_MARITIME_DISTRESS_ALERT
CMC_X_IMS_RECEIVING_EGC

If the information is not available, the value CMC_X_IMS_VALUE_UNDEFINED shall be


returned.

item_reference
NULL

4.4.2.6 CMC_X_IMS_MES_CURRENT_CHANNEL

Description:

This extension gives the channel number and the station number that the MES is currently tuned to.
These can change as data is sent or received by the MES.

Used-by:

cmc_query_configuration()

Input

extension_flags
No further flags are defined.

item_data
Unused

item_reference
NULL

Volume 2: User Services, Part 3: CMC Extensions, Page: 75


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Output

extension_flags
No further flags are defined

item_data
CMC_X_IMS_channel_number

If the number cannot be obtained the value returned should be


CMC_X_IMS_VALUE_UNDEFINED.

item_reference
Pointer to CMC_X_IMS_station_id. If the number cannot be obtained the value returned should
be NULL.

4.4.2.7 CMC_X_IMS_MES_CURRENT_FRAME_NUMBER

Description:

Gives the frame number of the current channel.

Application Developer’s Note:

If the current frame number is used for the scheduling of messages or data-reports, only frame
numbers originating from the NCS (or LES TDMs carrying NCS packets) should be used because
LES frame numbers may not be in synchronisation with the NCS. The extension flag
CMC_X_IMS_CHANNEL_TYPE should be used as a check.

Used-by:

cmc_query_configuration()

Input

extension_flags
No further flags are defined.

item_data
Unused.

item_reference
NULL

Output

extension_flags
CMC_X_IMS_NCS_CHANNEL is set if the frame number was obtained from an NCS channel
(or LES TDM if the LES TDM is carrying NCS packets). The flag is clear if the frame number
was obtained from an LES TDM.

item_data
The current frame numbers. Inmarsat-C frame numbers are always in the range 0 to 9999. If
the information is not available the value CMC_X_IMS_VALUE_UNDEFINED shall be returned.

item_reference
NULL

Volume 2: User Services, Part 3: CMC Extensions, Page: 76


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.4.2.8 CMC_X_IMS_MES_CURRENT_NCS

Description:

This extension gives or sets the NCS ID that the MES will tune to when idle. If used to set the current
NCS, it simply causes the MES to retune to the new NCS and does not issue a login.

MESs that are part of GMDSS installations will probably not support this CMC extension.

Application Developer’s Note:

This extension should normally be used only in conjunction with the extension
CMC_X_IMS_MES_LOGIN_FLAG. Some MESs may not support tuning to a new NCS ID without
logging in. CMC API implementations written for such MESs should store the station id set with this
extension and use it with subsequent CMC_X_IMS_MES_LOGIN_FLAG extensions to issue an
appropriate MES login.

Developers should note that using this extension without CMC_X_IMS_MES_LOGIN_FLAG could
cause MESs to retune from their current NCS TDM (either to a different NCS or the same NCS but a
different TDM) and therefore be unable to receive incoming messages.

If the login fails, the CMC implementation should attempt to return the MES to its original ocean region
and login state. This may, however, not be possible and so application developers are advised to
check the current NCS, and the login state, and act accordingly.

Used-by:

cmc_x_set_configuration()
cmc_logon()
cmc_query_configuration()

Input

extension_flags
No further flags are defined.

item_data
For cmc_x_set_configuration() and cmc_logon():
CMC_X_IMS_station_id

For cmc_query_configuration():
ignored

item_reference
NULL

Output

extension_flags
No further flags are defined

item_data
CMC_X_IMS_station_id
If the information is not known, the value CMC_X_IMS_VALUE_UNDEFINED shall be returned.

item_reference
NULL

Volume 2: User Services, Part 3: CMC Extensions, Page: 77


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.4.2.9 CMC_X_IMS_MES_ENID_LIST

Description

This extension allows an application in a mobile to list the ENIDs that have been downloaded to it.

Used by:

cmc_query_configuration()

Input

extension_flags
No further flags are defined.

item_data
Not used.

item_reference
Not used.

Output

extension_flags
No further flags are defined.

item_data
The number of ENIDs that have been downloaded. If the information is not available, the value
CMC_X_IMS_VALUE_UNDEFINED shall be returned.

item_reference
A pointer to an array of structures of type CMC_X_IMS_network_id, indicating the ENIDs that
have been downloaded.

4.4.2.10 CMC_X_IMS_MES_ENID_MGMT

Description:

This extension allows an application in a mobile to determine the current state of an ENID, to inhibit
an ENID, or to re-activate an ENID that has been inhibited.

Used-by:

cmc_query_configuration()
cmc_x_set_configuration()

Input

extension_flags
No further flags are defined.

item_data
CMC_X_IMS_ID_INHIBIT is set if the ENID is to be inhibited.
CMC_X_IMS_ID_ACTIVATE is set if the ENID is to be activated.

If both flags are clear (or if both flags are set) the no operation is performed but the current
state of the ENID is returned.

Volume 2: User Services, Part 3: CMC Extensions, Page: 78


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

item_reference
A pointer to a structure of type CMC_X_IMS_network_id.

Output

extension_flags
No further flags are defined.

item_data
If the information is not available, the value of item_data shall be
CMC_X_IMS_VALUE_UNDEFINED.
If item_data is not CMC_X_IMS_VALUE_UNDEFINED, then it is composed of a number of
flags:
CMC_X_IMS_EXISTS is set if the ENID has been downloaded and has not been
deleted, and is clear otherwise.

CMC_X_IMS_ACTIVE is set if the ENID exists and is active following the operation, and
is clear otherwise.

item_reference
A pointer to a structure of type CMC_X_IMS_network_id.

4.4.2.11 CMC_X_IMS_MES_GEOGRAPHICAL_COORDINATES

Description:

This extension enables the geographical co-ordinates to be set or to be interrogated by the


application.

Used-by:

cmc_x_set_configuration()
cmc_query_configuration()

Input

extension_flags
No further flags are defined

item_data
Not used.

item_reference
For cmc_x_set_configuration():
CMC_X_IMS_timestamped_geographical_coordinates

Output

extension_flags
No further flags are defined.

item_data
CMC_FALSE indicates that the value was not correctly set or retrieved.
CMC_TRUE indicates that the value was correctly set or retrieved.

item_reference
For cmc_query_configuration():
CMC_X_IMS_timestamped_geographical_coordinates

Volume 2: User Services, Part 3: CMC Extensions, Page: 79


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.4.2.12 CMC_X_IMS_MES_LOGIN_FLAG

Description:

This extension reflects the MES login status. If the MES is in the process of logging in (or has login
requests queued) when cmc_x_set_configuration() or cmc_logon() is called with
CMC_X_IMS_LOGGED_IN, the CMC API shall return CMC_X_IMS_LOGIN_COMMAND_ISSUED
but should not queue a further login request. Similarly,
CMC_X_IMS_LOGOUT_COMMAND_ISSUED should be returned if cmc_x_set_configuration() or
cmc_logon() has been called with CMC_X_IMS_LOGGED_OUT and the previously issued logout is
either waiting to complete or is still queued.

MESs that are a part of GMDSS installations will probably not support this extension.

Implementor's Note:

In order to reduce load on the network and MES delays, the CMC implementation should not cause
the MES to issue a login or a logout if the MES is already logged in or logged out respectively.

Used-by:

cmc_query_configuration()
cmc_x_set_configuration()
cmc_logon()

Input

extension_flags
No further flags are defined.

item_data
For cmc_x_set_configuration():
CMC_X_IMS_LOGGED_IN
CMC_X_IMS_LOGGED_OUT

item_reference
NULL

Output

extension_flags
No further flags are defined.

item_data
As above, and
CMC_X_IMS_LOGIN_COMMAND_ISSUED
CMC_X_IMS_LOGOUT_COMMAND_ISSUED
CMC_X_IMS_VALUE_UNDEFINED (if information is not available)

item_reference
NULL

4.4.2.13 CMC_X_IMS_MES_MESSAGE_TRANSFER_STATUS

Description:

This extension shows the status of a message transfer that is currently in progress.

Volume 2: User Services, Part 3: CMC Extensions, Page: 80


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Used-by:

cmc_query_configuration()

Input

extension_flags
No further flags are defined.

item_data
Unused.

item_reference
NULL

Output

extension_flags
No further flags are defined

item_data
The following are defined:
CMC_X_IMS_NO_MESSAGE_TRANSFER
CMC_X_IMS_CALL_IN_PROGRESS
CMC_X_IMS_VALUE_UNDEFINED (if information is not available)

item_reference
NULL

4.4.2.14 CMC_X_IMS_MES_NAV_EQUIPMENT

Description:

This extension enables the MES to be informed whether it should obtain position information from
internal/directly connected navigation equipment, or whether it should get position information from
the application through the CMC API. The calling application can compare the values of item_data
before and after a call to cmc_x_set_configuration() in order to determine whether the MES is now
configured in the correct way. MESs that are part of GMDSS installations are likely to prevent the
configuration of the DCE navigational equipment using the CMC API.

Used-by:

cmc_x_set_configuration()
cmc_query_configuration()

Input

extension_flags
No further flags are defined

item_data
CMC_X_IMS_NO_NAV_EQUIPMENT_CONNECTED
CMC_X_IMS_NAV_EQUIPMENT_CONNECTED

item_reference
NULL

Volume 2: User Services, Part 3: CMC Extensions, Page: 81


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Output

extension_flags
No further flags are defined.

item_data
As item_data above and
CMC_X_IMS_NAV_EQUIPMENT_UNKNOWN

which will be returned if the CMC implementation is unable to determine whether navigational
equipment is attached.

item_reference
NULL

4.4.2.15 CMC_X_IMS_MES_NCS_TDM_CHANNEL_LIST

Description:

This extension allows an application to list the known NCS IDs and their associated channel numbers.

Used-by:

cmc_query_configuration()

Input

extension_flags
No further flags are defined.

item_data
Not used.

item_reference
Not used.

Output

extension_flags
No further flags are defined

item_data
The number of CMC_X_IMS_ncs_information records pointed to by item_reference.

item_reference
A pointer to an array of structures of type CMC_X_IMS_ncs_information showing all currently
known NCS IDs and their channel numbers.

4.4.2.16 CMC_X_IMS_MES_NCS_TDM_CHANNEL_MGMT

Description:

This extension allows a mobile application to add or delete NCS IDs and their associated channel
numbers from the list stored in the mobile.

Used-by:

cmc_x_set_configuration()

Volume 2: User Services, Part 3: CMC Extensions, Page: 82


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Input

extension_flags
No further flags are defined.

item_data
CMC_X_IMS_ADD
This value indicates that the ncs information pointed to by item_reference is to be stored in the
mobile.

CMC_X_IMS_DELETE
This value indicates that the ncs information pointed to by item_referennce is to be deleted from
the mobile. The NCS ID component of the ncs information is used to determine which
information item to remove; the channel number is ignored. Some NCS IDs stored in the
mobile will probably by read only.

item_reference
Pointer to CMC_X_IMS_ncs_information.

Output

extension_flags
No further flags are defined

item_data
CMC_FALSE indicates that the ncs information was not correctly added or deleted.
CMC_TRUE indicates that the ncs information was correctly added or deleted.

item_reference
Pointer to CMC_X_IMS_ncs_information.

4.4.2.17 CMC_X_IMS_MES_NETWORK_INFORMATION

Description:

This extension enables the network information to be interrogated for the ocean region the MES is
logged in to.

Used-by:

cmc_query_configuration()

Input

extension_flags
No further flags are defined

item_data
Not used.

item_reference
Not used.

Output

extension_flags
No further flags are defined.

Volume 2: User Services, Part 3: CMC Extensions, Page: 83


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

item_data
Number of LESs for which network information is returned (and hence the number of elements
in the array pointed to by item_reference).

If the LESs in the region are not known, the value zero shall be returned.

item_reference
Pointer to an array of structures of type CMC_X_IMS_network_information, with one structure
per LES.

4.4.2.18 CMC_X_IMS_MES_PREFERRED_NCS

Description:

This extension reflects the preferred NCS. MESs currently have a preferred ocean region capability
rather than a preferred NCS capability, but this extension has been defined in this way to allow for
future enhancements.

MESs that are a part of GMDSS installations will probably not support this extension.

Used-by:

cmc_query_configuration()
cmc_x_set_configuration()

Input

extension_flags
No further flags are defined.

item_data
For cmc_x_set_configuration():
CMC_X_IMS_station_id

MESs with a preferred ocean region capability should use the ocean region of the given NCS
and ignore the actual ID number. A value of zero indicates no preferred NCS.

item_reference
NULL

Output

extension_flags
No further flags are defined.

item_data
CMC_X_IMS_VALUE_UNDEFINED or
CMC_X_IMS_station_id

If the MES has a preferred ocean region set, the value returned will be of the form r00, where r
is the ocean region number in the range 0 to 3.

CMC_X_IMS_VALUE_UNDEFINED indicates the information was not available. A value of


zero indicates no preferred NCS.

item_reference
NULL

Volume 2: User Services, Part 3: CMC Extensions, Page: 84


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.4.2.19 CMC_X_IMS_MES_PRINTER_MANAGEMENT

Description:

Controls the printer connected to the MES. Printers connected to the DTE are beyond the scope of
these CMC extensions.

Controlling MES printing functions may not be possible if the MES is used for GMDSS purposes. In
this case, cmc_x_set_configuration() should return the current (unchanged) printer settings.
Application developers can compare the input and output item_data values to check whether the call
was successful.

If the CMC API implementation cannot determine whether the MES is setup to print incoming
messages, outgoing messages or EGCs, the item_data flag
CMC_X_IMS_PRINTER_STATUS_INCOMPLETE shall be set on output in addition to any flags that
can be correctly determined.

Used-by:

cmc_query_configuration()
cmc_x_set_configuration()

Input

extension_flags
No further flags are defined

item_data
For cmc_x_set_configuration():

The value is a set of flags indicating which messages (if any) should be output on the
printer connected to the MES. If no flags are set, the MES printer is not used.

The flags defined are:


CMC_X_IMS_INCOMING_MESSAGES
CMC_X_IMS_OUTGOING_MESSAGES
CMC_X_IMS_EGC_MESSAGES

item_reference
NULL

Output

extension_flags
No further flags are defined.

item_data
A set of flags indicating which messages (if any) should be output on the printer connected to
the MES. In addition to the flags above, the following flags may also be returned
CMC_X_IMS_PRINTER_CONNECTED
CMC_X_IMS_PRINTER_OUT_OF_PAPER
CMC_X_IMS_PRINTER_ERROR
CMC_X_IMS_PRINTER_STATUS_INCOMPLETE

A value of CMC_X_IMS_VALUE_UNDEFINED for item_data indicates that the information was


not available.

item_reference
NULL

Volume 2: User Services, Part 3: CMC Extensions, Page: 85


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.4.2.20 CMC_X_IMS_MES_PVT_REPORT

Description:

Calling cmc_query_configuration() with the extension present causes the MES to report the result of
the previous Performance Verification Test (PVT).

Used-by:

cmc_query_configuration()

Input

extension_flags
No further flags are defined.

item_data
Not used.

item_reference
NULL

Output

extension_flags
No further flags are defined.

item_data
If the information is not available, the value CMC_X_IMS_VALUE_UNDEFINED shall be
returned. The normal value given in item_data on output shall be zero.

Item_reference
Pointer to a structure of type CMC_X_IMS_pvt_result that contains the results of the test.

4.4.2.21 CMC_X_IMS_MES_PVT_TEST

Description:

Calling cmc_x_set_configuration() with the extension present causes the MES to start a Performance
Verification Test (PVT).

Used-by:

cmc_x_set_configuration()

Input

extension_flags
No further flags are defined.

item_data
Not used.

item_reference
NULL

Volume 2: User Services, Part 3: CMC Extensions, Page: 86


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Output

extension_flags
No further flags are defined.

item_data
CMC_X_IMS_PVT_REQUEST_FAILED
CMC_X_IMS_PVT_REQUESTED

item_reference
NULL

4.4.2.22 CMC_X_IMS_MES_SCAN

Description:

Including this extension in a call to cmc_x_set_configuration() causes the MES to initiate a scan.
MESs that are a part of GMDSS installations will probably not support this extension.

Used-by:

cmc_x_set_configuration()

Input

extension_flags
No further flags are defined.

item_data
Not used.

item_reference
NULL

Output

extension_flags
No further flags are defined.

item_data
The value CMC_X_IMS_VALUE_UNDEFINED indicates that the scan request failed. The
normal value given in item_data on output shall be zero.

item_reference
NULL

4.4.2.23 CMC_X_IMS_MES_SIGNAL_STRENGTH

Description:

This extension indicates the current signal strength on a scale of 0 to 100. 0 indicates the carrier
cannot be received at all, 100 indicates a very strong signal. The signal strength should be calibrated
such that a signal strength of 50 or more indicates an adequate signal strength.

Application Programmers Note:

MESs may provide the CMC implementation with a variety of status information at the same time. It
may therefore be more efficient to request the signal strength together with other status information (if
these are also required) rather than making a number of separate calls to cmc_query_configuration().

Volume 2: User Services, Part 3: CMC Extensions, Page: 87


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Used-by:

cmc_query_configuration()

Input

extension_flags
No further flags are defined.

item_data
Unused.

item_reference
NULL

Output

extension_flags
No further flags are defined.

item_data
The current signal strength on a scale of 0 to 100. If the information is not available, the value
CMC_X_IMS_VALUE_UNDEFINED shall be returned.

item_reference
NULL

4.4.3 Data Reporting and Polling Extensions (CMC_XS_IMS_DRP)


This is a Inmarsat-C extension set containing extensions for data reporting and polling service
elements.

4.4.3.1 CMC_X_IMS_DRP_DNID_LIST

Description:

This extension allows an application in a mobile to list the DNIDs that have been downloaded to it.

Used-by:

cmc_query_configuration()

Input

extension_flags
Not used.

item_data
Not used.

item_reference
Not used.

Output

extension_flags
Not used.

Volume 2: User Services, Part 3: CMC Extensions, Page: 88


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

item_data
The number of DNIDs that have been downloaded. If the information is not available, the value
CMC_X_IMS_VALUE_UNDEFINED shall be returned.

item_reference
A pointer to an array of structures of type CMC_X_IMS_network_id, indicating the DNIDs that
have been downloaded.

4.4.3.2 CMC_X_IMS_DRP_DNID_MGMT

Description:

This extension allows an application in a mobile to determine the current state of a DNID, to inhibit a
DNID, or to re-activate a DNID that has been inhibited.

Used-by:

cmc_query_configuration()
cmc_x_set_configuration()

Input

extension_flags
No further flags are defined.

item_data
CMC_X_IMS_ID_INHIBIT is set if the DNID is to be inhibited.
CMC_X_IMS_ID_ACTIVATE is set if the DNID is to be activated.

If both flags are clear (or if both flags are set) the no operation is performed but the current
state of the DNID is returned.

item_reference
A pointer to a structure of type CMC_X_IMS_network_id.

Output

extension_flags
No further flags are defined.

item_data
If the information is not available, the value of item_data shall be
CMC_X_IMS_VALUE_UNDEFINED.

If item_data is not CMC_X_IMS_VALUE_UNDEFINED, then it is composed of a number of


flags:
CMC_X_IMS_EXISTS is set if the DNID has been downloaded and has not been
deleted, and is clear otherwise.

CMC_X_IMS_ACTIVE is set if the DNID exists and is active following the operation, and
is clear otherwise.

item_reference
A pointer to a structure of type CMC_X_IMS_network_id.

Volume 2: User Services, Part 3: CMC Extensions, Page: 89


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.5 MES CMC API Implementation Profiles

4.5.1 Simple MES


An MES implementation conforming to the simple MES profile shall:

• conform to the X.400 API Association CMC API specification version 1.0

• support the CMC_X_COM_SUPPORT_EXT extension that is defined in the CMC API


specification

• implement cmc_x_set_configuration() defined in this specification

• implement the additional data types and error codes that are defined in this specification

• support the CMC_XS_IMS_GEN and CMC_XS_IMS_MES extension sets that are defined in
this specification

• support the address structures and message types defined in this specification, other than
those specific to data reporting and polling.

4.5.2 MES with DRP Support


An MES implementation conforming to the MES with DRP Support profile shall conform to the Simple
MES profile and shall also:

• support the CMC_XS_IMS_DRP extension set that is defined in this specification

• support all of the address structures and message types defined in this specification.

4.6 Terrestrial CMC API Implementation Profiles

4.6.1 General
Every terrestrial implementation shall

• conform to the X.400 API Association CMC API specification version 1.0

• support the CMC_X_COM_SUPPORT_EXT extension that is defined in the CMC API


specification

• implement cmc_x_set_configuration() defined in this specification

• implement all the additional data types and error codes that are defined in this specification

• support the CMC_XS_IMS_GEN extension set that is defined in this specification

• support all of the address structures and message types defined in this specification.

4.6.2 X.25 Terrestrial Station


A terrestrial implementation conforming to the X.25 Terrestrial Station profile shall conform to the
general terrestrial CMC API implementation profile requirements and shall support connection to
Inmarsat-C Land Earth Stations via X.25 packet switched networks. The implementation
documentation shall state what versions and options of the X.25 protocol are supported.

Volume 2: User Services, Part 3: CMC Extensions, Page: 90


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.6.3 PSTN Terrestrial Station


A terrestrial implementation conforming to the PSTN Terrestrial Station profile shall conform to the
general terrestrial CMC API implementation profile requirements and shall support connection to
Inmarsat-C Land Earth Stations via modems and the public switched telephone network (PSTN). The
implementation documentation shall state what types of modem are supported.

4.7 Suggested User Configurable Defaults


The following list are suggested configuration parameters. The mechanism for changing these default
values is left to the CMC implementation.

4.7.1 “From” Address


Messages sent without a “From” recipient to addresses that support Inmarsat-C Headers can use a
default address for the “From” recipient. The address should be configurable and, in the MES case,
will probably contain the MES number and perhaps the Ocean Region number. The following are
example default addresses:

INMC:499999999
INMC:499999999;REGION=0

4.7.2 Presentation Code for Text Only Messages


Messages containing only text to addresses other than Basic X.400 may take one or three
presentation codes: Data (eight bit), IA5 (seven bit), or ITA2 (five bit). This user default value can be
overridden with the CMC_X_IMS_GEN_PRESENTATION extension.

4.7.3 LES(s)
The default LES is best done on an NCS basis so that for each NCS that the MES is logged into, a
default LES can be defined. This allows the MES user to move between ocean regions or NCSs
without having to redefine the default LES. When there is no LES defined in the extensions, the
address line or the defaults, the CMC implementation should fail the call with the
CMC_E_RECIPIENT_NOT_FOUND error code.

4.7.4 Message Header Keywords


The header keywords to be included in Inmarsat-C messages and EGCs should be user configurable.
The user defined default keywords will be the list of keywords to be included in the header when the
address supports Inmarsat-C Message Headers. The headers may be overridden with the address
line NOHEADERS keyword or the CMC_X_IMS_GEN_HEADERS extension.

4.7.5 Port Configuration


The machine port and port speeds may require user configurable values.

4.7.6 LES Access Numbers, Accounts and Passwords


Terrestrial implementations of CMC for Inmarsat-C should allow the user to configure the LES access
numbers (PSTN or X.25), account names and passwords. Passwords should be stored such that
they cannot easily be read.

4.8 Suggested User Interface Functions


CMC implementations for Inmarsat-C may have a user interface. In addition to the user interface
functions described in the CMC API document (requested by the calling application), the CMC

Volume 2: User Services, Part 3: CMC Extensions, Page: 91


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

implementation may have a separate program or programs to provide the user with additional
information and control. This section describes some functions that may be useful:

4.8.1 MES Status Information


MES implementations can provide the user with an indication of the current MES status. This could
include the connection status to the MES, any MES error conditions, signal strength, bulletin board
error rate, current NCS, current MES function (e.g. idle, sending message etc.), access to any MES
specific configuration options, etc.

4.8.2 CMC Implementation Configuration


A user interface could be provided to control the CMC configuration such as the default header lines
added to message, default LES(s) etc. For LES implementations, the user interface may provide the
user with mechanisms to add new LES and enter LES account names, passwords and access
numbers.

4.8.3 Message Status Enquiry


Inmarsat-C provides MES users with a service to determine the status of a previously sent message.
This is useful because non-delivery and delivery reports may be lost if the MES is blocked from
“seeing” the satellite. A user interface could be provided to allow the user to select a previously sent
message to determine the status of.

4.8.4 EGC Cancellation


Cancellation of EGCs can be done through using the EGC addressing keywords but since this is not
very intuitive, a user interface for EGC cancellation could be provided to enable the user to simply
pick a previously sent EGC that he/she wishes to cancel.

4.9 C-Declaration Summaries


/*
* xcmcims.h
*
* Purpose:
* Specifies constants and data structures for Inmarsat-C CMC
* extensions.

* Three extension sets have been defined:


* CMC_XS_IMS_GEN General extensions, common to both the MES and
* the LES
* CMC_XS_IMS_MES Used by applications that connect to the MES
* CMC_XS_IMS_DRP Related to data reporting and polling service
* elements
*
*/
/*** Inmarsat-C Extension Set Ids ***/
#define IMS_GEN_EXT_SET_ID (0x400)
#define IMS_MES_EXT_SET_ID (0x440)
#define IMS_DRP_EXT_SET_ID (0x480)
#define CMC_XS_IMS_GEN ((CMC_uint32) IMS_GEN_EXT_SET_ID)
#define CMC_XS_IMS_MES ((CMC_uint32) IMS_MES_EXT_SET_ID)
#define CMC_XS_IMS_DRP ((CMC_uint32) IMS_DRP_EXT_SET_ID)

/*** ADDITIONAL DATA TYPES ***/


/* If the installed <xcmc.h> file defines any of the following two types,
* remove them */
typedef unsigned char CMC_uint8;
typedef char CMC_char;

/* Inmarsat-C LES, or NCS ID number */


typedef CMC_uint16 CMC_X_IMS_station_id;
/* Inmarsat-C Channel Number */

Volume 2: User Services, Part 3: CMC Extensions, Page: 92


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

typedef CMC_uint16 CMC_X_IMS_channel_number;

/*** ADDITIONAL DATA STRUCTURES ***/


/* Message Transfer Report */
typedef struct {
CMC_uint32 size;
CMC_sint16 message_packets;
CMC_sint16 repeated_message_packet_count;
CMC_sint16 retransmission_count;
CMC_time submission_time;
CMC_time start_transmit_time;
CMC_time end_transmit_time;
CMC_uint32 message_reference_number;
CMC_X_IMS_station_id les;
CMC_string addresses;
}
CMC_X_IMS_message_transfer_report;

/* Geographical Coordinates */
typedef struct {
CMC_uint16 longitude_degrees;
CMC_uint16 longitude_minutes ;
CMC_uint16 longitude_hundredths;
CMC_uint16 latitude_degrees;
CMC_uint16 latitude_minutes;
CMC_uint16 latitude_hundredths;
CMC_char north_south;
CMC_char east_west;
}
CMC_X_IMS_geographical_coordinates;

/* Inmarsat-C Data Reporting Closed Network ID */


typedef struct {
CMC_uint16 id; /* DNID */
CMC_uint8 les; /* LES ID */
CMC_uint16 tdm; /* LES TDM */
CMC_uint8 member; /* Member Number */
CMC_string descrip; /* First 25 characters of
the Free field in the
download command */
CMC_boolean inhibited;
}
CMC_X_IMS_network_id;

/* Keyword Value list */


typedef CMC_uint8 CMC_X_IMS_keyword_list[CMC_X_IMS_NR_OF_KWDS];

/* The following two definitions will need updating


if CMC_X_IMS_NR_OF_KWDS is changed */
CMC_X_IMS_keyword_list zero_keys = /* Clear all flags template */
{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
CMC_X_IMS_keyword_list set_keys = /* Set all flags template */
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1};
/* Keyword Value pair list */
typedef struct {
CMC_string keyword_string;
CMC_string value_string;
}
CMC_X_IMS_keyword_value_pair_list;
/* Network information */
typedef struct {
CMC_uint16 les_id;
CMC_uint32 les_status;
CMC_uint32 les_service;
CMC_X_IMS_channel_number channel_number;
}
CMC_X_IMS_network_information;

/* MES number */
typedef CMC_uint32 CMC_X_IMS_mes_number;

/* Land Mobile Alert - details of an LMA sent from an MES to an LES */


typdef struct {
CMC_uint8 nature_of_alert;
CMC_X_IMS_geographical_coordinates land_position;
CMC_boolean manual_position;

Volume 2: User Services, Part 3: CMC Extensions, Page: 93


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

CMC_uint8 time_of_position;
CMC_uint8 speed;
CMC_uint8 direction_of_travel;
CMC_uint8 extra_info;
}
CMC_X_IMS_land_mobile_alert;
typdef struct {
CMC_X_IMS_geographical_coordinates coordinates;
CMC_boolean timestamp_valid;
CMC_time timestamp;
}
CMC_X_IMS_timestamped_geographical_coordinates;

/* PVT result */
typedef struct {
CMC_uint16 attempts;
CMC_uint16 bber;
CMC_uint16 forward_attempts;
CMC_uint16 return_attempts;
CMC_uint16 distress_alert_test;
CMC_uint16 signal_strength;
CMC_uint16 overall;
}
CMC_X_IMS_pvt_result;

/* Configure access to the Inmarsat-C network */


CMC_return_code
cmc_x_set_configuration(
CMC_session_id session,
CMC_ui_id ui_id,
CMC_extension *set_configuration_extensions
);

/*** GENERAL EXTENSIONS (CMC_XS_IMS_GEN) ***/


#define CMC_X_IMS_GEN_HEADERS ( CMC_XS_IMS_GEN + 1 )
#define CMC_X_IMS_GEN_IP_REFERENCE ( CMC_XS_IMS_GEN + 2 )
#define CMC_X_IMS_GEN_LAND_MOBILE_ALERT_DATA ( CMC_XS_IMS_GEN + 3 )
#define CMC_X_IMS_GEN_LES_ID ( CMC_XS_IMS_GEN + 4 )
#define CMC_X_IMS_GEN_MESSAGE_HEADERS ( CMC_XS_IMS_GEN + 5)
#define CMC_X_IMS_GEN_MESSAGE_TRANSFER_REPORT ( CMC_XS_IMS_GEN + 6 )
#define CMC_X_IMS_GEN_MSG_RECEIVED ( CMC_XS_IMS_GEN + 7 )
#define CMC_X_IMS_GEN_MSG_STATUS_ENQUIRY ( CMC_XS_IMS_GEN + 8 )
#define CMC_X_IMS_GEN_PRESENTATION ( CMC_XS_IMS_GEN + 9 )
#define CMC_X_IMS_GEN_PRIORITY ( CMC_XS_IMS_GEN + 10 )
#define CMC_X_IMS_GEN_REQUEST_DELIVERY_REPORT ( CMC_XS_IMS_GEN + 11 )
#define CMC_X_IMS_GEN_REQUEST_MESSAGE_TRANSFER_REPORT (CMC_XS_IMS_GEN + 12)
#define CMC_X_IMS_GEN_REQUEST_REPLY ( CMC_XS_IMS_GEN + 13 )
#define CMC_X_IMS_GEN_REQUEST_RECEIPT_REPORT ( CMC_XS_IMS_GEN + 14 )
#define CMC_X_IMS_GEN_YOUR_IP_REFERENCE ( CMC_XS_IMS_GEN + 15 )

/* These definitions are used to access particular elements of the


CMC_X_IMS_GEN_HEADERS array. Each element is associated with a
particular message header keyword */
#define CMC_X_IMS_NR_OF_KWDS 28
#define CMC_X_IMS_KWD_ATTACH 0 /* ATTACH */
#define CMC_X_IMS_KWD_AUTHORIZING 1 /* AUTHORIZING */
#define CMC_X_IMS_KWD_AUTOFORWARD 2 /* AUTOFORWARD */
#define CMC_X_IMS_KWD_BCC 3 /* BCC */
#define CMC_X_IMS_KWD_BODYTYPE 4 /* BODYTYPE */
#define CMC_X_IMS_KWD_CC 5 /* CC */
#define CMC_X_IMS_KWD_CID 6 /* CID */
#define CMC_X_IMS_KWD_CONTENTTYPE 7 /* CONTENTTYPE */
#define CMC_X_IMS_KWD_CONVERTED 8 /* CONVERTED */
#define CMC_X_IMS_KWD_DELTTIME 9 /* DELTIME */
#define CMC_X_IMS_KWD_EIT 10 /* EIT */
#define CMC_X_IMS_KWD_ENCRYPTION 11 /* ENCRYPTION */
#define CMC_X_IMS_KWD_FORWARD 12 /* FORWARD */
#define CMC_X_IMS_KWD_FROM 13 /* FROM */
#define CMC_X_IMS_KWD_IMPORTANCE 14 /* IMPORTANCE */
#define CMC_X_IMS_KWD_INCOMPLETE 15 /* INCOMPLETE */
#define CMC_X_IMS_KWD_LANGUAGE 16 /* LANGUAGE */
#define CMC_X_IMS_KWD_LESID 17 /* LESID */
#define CMC_X_IMS_KWD_MSGID 18 /* MESID */
#define CMC_X_IMS_KWD_NOCONVERSION 19 /* NOCONVERSION */
#define CMC_X_IMS_KWD_NODL 20 /* NODL */

Volume 2: User Services, Part 3: CMC Extensions, Page: 94


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

#define CMC_X_IMS_KWD_NOLOSS 21 /* NOLOSS */


#define CMC_X_IMS_KWD_OURREF 22 /* OURREF */
#define CMC_X_IMS_KWD_PRIORITY 23 /* PRIORITY */
#define CMC_X_IMS_KWD_SENSITIVITY 24 /* SENSITIVITY */
#define CMC_X_IMS_KWD_SUBJECT 25 /* SUBJECT */
#define CMC_X_IMS_KWD_SUBTIME 26 /* SUBTIME */
#define CMC_X_IMS_KWD_TO 27 /* TO */
#define CMC_X_IMS_KWD_YOURREF 28 /* YOURREF */

/* Inmarsat-C message presentation codes to be used


with CMC_X_IMS_GEN_PRESENTATION */
#define CMC_X_IMS_UNKNOWN 0
#define CMC_X_IMS_FIVE_BIT 1
#define CMC_X_IMS_SEVEN_BIT 2
#define CMC_X_IMS_EIGHT_BIT 3

/* Inmarsat-C specific priorities to be used with


CMC_X_IMS_GEN_PRIORITY */
#define CMC_X_IMS_MARITIMESAFETY 100
#define CMC_X_IMS_MARITIMEURGENCY 200
#define CMC_X_IMS_MARITIMEDISTRESS 300

/*** MES EXTENSIONS (CMC_XS_IMS_MES) ***/


#define CMC_X_IMS_MES_ABORT_CURRENT_OPERATION ( CMC_XS_IMS_GEN + 1 )
#define CMC_X_IMS_MES_AVAILABLE_MES_MEMORY ( CMC_XS_IMS_GEN + 2 )
#define CMC_X_IMS_MES_BB_ERROR_RATE ( CMC_XS_IMS_GEN + 3 )
#define CMC_X_IMS_MES_CLEAR_WAITING_MESSAGES ( CMC_XS_IMS_GEN + 4 )

#define CMC_X_IMS_MES_CURRENT_ACTIVITY ( CMC_XS_IMS_GEN + 5 )


#define CMC_X_IMS_MES_CURRENT_CHANNEL ( CMC_XS_IMS_GEN + 6 )
#define CMC_X_IMS_MES_CURRENT_FRAME_NUMBER ( CMC_XS_IMS_GEN + 7 )
#define CMC_X_IMS_MES_CURRENT_NCS ( CMC_XS_IMS_GEN + 8 )
#define CMC_X_IMS_MES_ENID_LIST ( CMC_XS_IMS_GEN + 9 )
#define CMC_X_IMS_MES_ENID_MGMT ( CMC_XS_IMS_GEN + 10 )
#define CMC_X_IMS_MES_GEOGRAPHICAL_COORDINATES ( CMC_XS_IMS_GEN + 11 )
#define CMC_X_IMS_MES_LOGIN_FLAG ( CMC_XS_IMS_GEN + 12 )
#define CMC_X_IMS_MES_MESSAGE_TRANSFER_STATUS ( CMC_XS_IMS_GEN + 13 )
#define CMC_X_IMS_MES_NAV_EQUIPMENT ( CMC_XS_IMS_GEN + 14 )
#define CMC_X_IMS_MES_NCS_TDM_CHANNEL ( CMC_XS_IMS_GEN + 15 )
#define CMC_X_IMS_MES_NETWORK_INFORMATION ( CMC_XS_IMS_GEN + 16 )
#define CMC_X_IMS_MES_PREFERRED_NCS ( CMC_XS_IMS_GEN + 17 )
#define CMC_X_IMS_MES_PRINTER_MANAGEMENT ( CMC_XS_IMS_GEN + 18 )
#define CMC_X_IMS_MES_PVT_REPORT ( CMC_XS_IMS_GEN + 19 )
#define CMC_X_IMS_MES_PVT_TEST ( CMC_XS_IMS_GEN + 20 )
#define CMC_X_IMS_MES_SCAN ( CMC_XS_IMS_GEN + 21 )
#define CMC_X_IMS_MES_SIGNAL_STRENGTH ( CMC_XS_IMS_GEN + 22 )

/* Definitions to be used with abort current operation extension


CMC_X_IMS_MES_ABORT_CURRENT_OPERATION */
#define CMC_X_IMS_SUCCESS 0
#define CMC_X_IMS_NO_CURRENT_OPERATION 1
#define CMC_X_IMS_UNABLE_TO_ABORT_CURRENT_OPERATION 2

/*CMC_X_IMS_VALUE_UNDEFINED may be returned by a number of extensions */


#define CMC_X_IMS_VALUE_UNDEFINED ((CMC_uint32) 0xFFFFFFFF)

/* Values returned by CMC_X_IMS_MES_CURRENT_ACTIVITY */


#define CMC_X_IMS_IDLE 0
#define CMC_X_IMS_SENDING_MESSAGE 1
#define CMC_X_IMS_RECEIVING_MESSAGE 2
#define CMC_X_IMS_SENDING_DATA_REPORT 3
#define CMC_X_IMS_LOGGING_IN 4
#define CMC_X_IMS_LOGGING_OUT 5
#define CMC_X_IMS_PVT 6
#define CMC_X_IMS_FORCE_CLEARING 7
#define CMC_X_IMS_LAND_EMERGENCY_ALERT 8
#define CMC_X_IMS_MARITIME_DISTRESS_ALERT 9
#define CMC_X_IMS_RECEIVING_EGC 10

/* Flag defined for CMC_X_IMS_MES_CURRENT_FRAME_NUMBER */


#define CMC_X_IMS_NCS_CHANNEL ( (CMC_flags) 1)

/* Flags for management of ENIDs and DNIDs */

#define CMC_X_IMS_ID_INHIBIT ( (CMC_flags) 1 )

Volume 2: User Services, Part 3: CMC Extensions, Page: 95


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

#define CMC_X_IMS_ID_ACTIVATE ( (CMC_flags) 2)


#define CMC_X_IMS_ID_EXISTS ( (CMC_flags) 4)
#define CMC_X_IMS_ID_ACTIVE ( (CMC_flags) 8)

/* MES login status values */


#define CMC_X_IMS_LOGGED_IN 0
#define CMC_X_IMS_LOGGED_OUT 1
#define CMC_X_IMS_LOGIN_COMMAND_ISSUED 2
#define CMC_X_IMS_LOGOUT_COMMAND_ISSUED 3

/* Values returned by CMC_X_IMS_MES_MESSAGE_TRANSFER_STATUS */


#define CMC_X_IMS_NO_MESSAGE_TRANSFER 0
#define CMC_X_IMS_CALL_IN_PROGRESS 1

/* Values for CMC_X_IMS_MES_NAV_EQUIPMENT */


#define CMC_X_IMS_NAV_EQUIPMENT_UNKNOWN 0
#define CMC_X_IMS_NO_NAV_EQUIPMENT_CONNECTED 1
#define CMC_X_IMS_NAV_EQUIPMENT_CONNECTED 2

/* Flags for CMC_X_IMS_MES_TDM_CHANNEL */


#define CMC_X_IMS_ADD 1
#define CMC_X_IMS_DELETE 2

/* Flags for CMC_X_IMS_MES_PRINTER_MANAGEMENT */


#define CMC_X_IMS_INCOMING_MESSAGES 1
#define CMC_X_IMS_OUTGOING_MESSAGES 2
#define CMC_X_IMS_EGC_MESSAGES 4
#define CMC_X_IMS_PRINTER_CONNECTED 8
#define CMC_X_IMS_PRINTER_OUT_OF_PAPER 16
#define CMC_X_IMS_PRINTER_ERROR 32
#define CMC_X_IMS_PRINTER_STATUS_INCOMPLETE 64

/* Values returned by CMC_X_IMS_MES_PVT_TEST */


#define CMC_X_IMS_PVT_REQUEST_FAILED 0
#define CMC_X_IMS_PVT_REQUESTED 1

/*** DATA REPORTING AND POLLING EXTENSIONS (CMC_XS_IMS_DRP) ***/


#define CMC_X_IMS_DRP_DNID_LIST ( CMC_XS_IMS_DRP + 1 )
#define CMC_X_IMS_DRP_DNID_MGMT ( CMC_XS_IMS_DRP + 2 )

/* ** ERROR CODES ** */
/* The following symbols are defined for the error codes that are
defined in this extension of the CMC API. */
#define CMC_E_IMS_ADDR_SYNTAX 010000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_PREFIX 020000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_ACKNOWLEDGEMENT 030000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_ADDRESS 040000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_AUTOMATIC 050000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_CANCEL 060000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_COMMAND 070000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_DIRECTION 080000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_DR 090000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_DUPLICATE 0A0000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_ECHO 0B0000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_EGCINTERVAL 0C0000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_EXTRA 0D0000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_FRAME 0E0000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_ID 0F0000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_INTERVAL 100000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_LES 110000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_MEMBER 120000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_MTR 130000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_NAME 140000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_NATURE 150000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_NOHEADERS 160000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_POSITION 170000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_PROTOCOL 180000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_RANDOM 190000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_REGION 1A0000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_REPEATS 1B0000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_REPLY 1C0000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_RR 1D0000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_SEQNUM 1E0000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_SERVICE 1F0000H+CMC_E_RECIPIENT_NOT_FOUND

Volume 2: User Services, Part 3: CMC Extensions, Page: 96


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

#define CMC_E_IMS_ADDR_SPEED 200000H+CMC_E_RECIPIENT_NOT_FOUND


#define CMC_E_IMS_ADDR_SUBADDRESS 210000H+CMC_E_RECIPIENT_NOT_FOUND
#define CMC_E_IMS_ADDR_TIMEOFPOSITION 220000H+CMC_E_RECIPIENT_NOT_FOUND

5 Inmarsat-C Message Headers

5.1 Introduction
There are some elements of service that CMC assumes that are not directly supported by the
Inmarsat-C network. This chapter describes how additional information to support these, and other,
service elements, is to be carried in a header added to the start of the message.

5.2 Headers and Inmarsat-C


The Inmarsat-C messaging protocol enables messages to be sent to or from a mobile terminal. In
order to carry additional message information (such as message subject) across the Inmarsat-C
network, header lines are added to the start of the message. With the exception of X.400 services,
the additional headers are not interpreted by the LES but are carried as if part of the message. The
headers are in a text syntax and may therefore be read by an end-user if the receiving application or
machine cannot identify and interpret the header.

All Inmarsat-C messages are sent via a Land Earth Station (LES) and it is the LES that provides the
link to the terrestrial networks. Messages sent to a terrestrial address, could, of course, then enter
another messaging network such as a LAN based electronic mail system. One or more of these
stages in the transfer of a message may add their own header to the start of a message. The LESs
typically add a single line header giving some indication of sender, the LES, time sent, and a message
reference number, and terrestrial networks could add information about the routing of a particular
message. A start of header identifier is provided to enable a receiving program to identify where other
headers end and the Inmarsat-C header starts.

X.400 messages are handled differently. For Basic X.400 in the to-mobile direction, the headers are
created at the LES. In the from-mobile direction, the LES strips the header and uses the information
in the creation of the X.400 message. Enhanced X.400 messages have no headers at all; the
protocol elements being carried as A.S.N. 1. Enhanced X.400 is outside the scope of this document.

A CMC implementation for Inmarsat-C should be able to read and write both Basic X.400 headers and
Inmarsat-C API Message Headers. The CMC API implementation may include API header keywords
when sending Basic X.400 messages (the LES will ignore them). For received messages, the CMC
implementation should use the CMC_X_IMS_GEN_MESSAGE_HEADERS extension (if enabled) to
pass any unrecognised header keywords and values to the application.

5.3 Syntax

5.3.1 Formal Structure


The overall structure of the message as sent over Inmarsat-C is:

[Message] ::= [Header][Data]


| [Data]

The header structure is give by:

[Header] ::= [Basic X.400 Header]


| [API Header]

[API Header] ::= [Start of Header][Protocol Element List]


[End of Header]

Volume 2: User Services, Part 3: CMC Extensions, Page: 97


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The definitions of [Basic X.400 header], [Protocol Element List] and [End of Header] are given in the
Basic Inmarsat-C/X.400 Specification but are repeated here for readability:

[Basic X.400 Header] ::= [Protocol Element List][End of Header]


| [End of Header]

[Protocol Element List] ::= [Protocol Element]


| [Protocol Element] [Protocol Element List]

[Protocol Element] ::= [Element Keyword]:


| [Element Keyword]:[Argument List]

[Argument List] ::= [Argument]


| [Argument],[Argument List]

[Argument] ::= [Value]


| [Value];[Parameter List]
| [Parameter List]

[Parameter List] ::= [Parameter]


| [Parameter];[Parameter List]

[Parameter] ::= [Parameter Keyword]


| [Parameter Keyword]=[Parameter Value]

[End of Header] ::= STX:[EOL]

[EOL] ::= <CR><LF>


|<LF>

5.3.2 General Rules


The general rules applied to the overall structure are as follows:

i) the message header comprises a number of protocol elements. Each protocol element
supports a particular service;

ii) each element consists of a keyword which may be followed by one or more arguments;

iii) a keyword always starts at the beginning of a line (but can, optionally, be preceded by white
space);

iv) a keyword is always followed by a colon (":") whether followed by arguments or not;

v) arguments of a protocol element are delimited by a comma (",");

vi) an argument may have a value and zero or more parameters delimited by a semicolon (";");

vii) a parameter may have a value (separated from the parameter keyword by an equals sign ("=")
and optional white space.;

viii) no distinction is made between upper and lower case for keywords or parameter labels,
although uppercase is recommended for visual identification;

ix) newlines can be added before or after keywords or delimiters if the following line starts with a
hyphen (“-”). Values may also be broken over one or more lines, again by starting the
following line with a hyphen (“-”); in this case any whitespace before the end of line and after the
hyphen is ignored;

Volume 2: User Services, Part 3: CMC Extensions, Page: 98


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

x) all keywords, argument names and delimiters shall use the alphabet implied by the
presentation code. The IA5 alphabet with parity ignored shall be used when the presentation
code is Basic X.400 or Data.

xi) to delimit the end of the Basic X.400 Header and the beginning of the user's text or data, the
character sequence "S" "T" "X" ":" is used beginning on a new line and terminated by
either CR or CR/LF. The first character after LF is taken to be the start of the user data. API
headers, and optionally, Basic X.400 Headers shall start with the character sequence "S" "H"
"D" "R" ":" beginning on a new line. For both start and end of header spaces are allowed
before the keyword and after the colon (":") but not between the keyword and the colon.

5.4 Keywords, Parameters, and Abbreviations


For a full definition of the Basic X.400 header syntax, see the Basic X.400/Inmarsat-C Interworking
Specification [3]. The Basic X.400 keywords are, however, repeated here with the underlining
showing the minimum abbreviations:

API Keyword Keyword Value Parameter Keywords


(A)
Basic X.400 (B)
A ATTACH: byte offset (natural number) Zero or one of the following:
FILE= [string]
BILAT=
TXT
| BIN
| [string]
NAT=
EXT=
TXT
| BIN
| [string]
(Values of TXT and BIN are
short forms for
CMC_ATT_OID_TEXT and
CMC_ATT_OID_BINARY
respectively. If no parameter
is included,
CMC_ATT_OID_BINARY is
assumed).
B AUTHORIZI Address values Address parameters
NG:
B AUTOFORWA
RD:
AB BCC: Address values Address parameters

Volume 2: User Services, Part 3: CMC Extensions, Page: 99


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

AB BODYTYPE: One of the following values: Only one of the following


TXT where no value is present:
| IA5 BILAT=
| ITA2 ACD
| G3 | ACH
| G4 | BIN
| TTX | TXT
| MSG NAT= [string]
| MIXED EXT=
| [free string] BIN
If no value is present, one of TXT
the parameter keywords must | [string]
be present with a value. (Values of TXT and BIN are
(TXT is a short form for short forms for
CMC_ATT_OID_TEXT and is CMC_ATT_OID_TEXT and
the default value). CMC_ATT_OID_BINARY
respectively).
AB CC: Address values Address parameters
B CID: [string]
AB CONTENTTY One of the following values: Only if no value is present:
PE: UNIDENTIFIED EXT= [string]
| EXTERNAL
| IPM84
| IPM88
| CMCDR
| CMCRN
| CMCNDR
| CMCNRN
Default is IPM84 or IPM88 for
Basic X.400, and CMC: IPM
for other destinations. CMCDR
and CMCNDR are used for
Basic-X.400 delivery reports
and non-delivery reports. If no
value is present the parameter
keyword must be present.
B CONVERTED One of the following values: Only if no value is present:
: UNDEFINED EXT= [string]
| TLX
| IA5
| G3
| G4
| TTX
| VTX
| VOICE
| SFD
| MIXED
If no value is present the
parameter keyword must be
present.
B DELTIME: UTC time in following format:
YYMMDD HHMM
where the fields are all two
decimal digits in length and
indicate, in order, the year,
month, day, hour and minutes.

Volume 2: User Services, Part 3: CMC Extensions, Page: 100


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

B EIT: One of the following values: Only if no value is present:


UNDEFINED EXT= [string]
| TLX
| IA5
| G3
| G4
| TTX
| VTX
| VOICE
| SFD
| MIXED
If no value is present the
parameter keyword must be
present.
A ENCRYPTIO [string]
N:
AB FORWARD: [string]
AB FROM: Address values Address parameters
A IMPORTANC LOW
E: | NORMAL (default)
| HIGH
AB INCOMPLET [string]
E: e.g. “2nd body-pt of type
‘mixed’ was lost”
A LANGUAGE: [string]
B MSGID: [string]
B NOCONVERS
ION:
B NODL:
B NOLOSS:
AB OURREF: [string]
AB PRIORITY: NORMAL (default)
NONURGENT (CMC low)
URGENT (CMC urgent)
MARITIMESAFETY
MARITIMEURGENCY
MARITIMEDISTRESS
A SENSITIVI DEFAULT (default)
TY: PERSONAL
PRIVATE
CONFIDENTIAL
AB5 SHDR:
AB STX:
AB SUBJECT: [string]
AB SUBTIME: UTC time in following format:
YYMMDD HHMM
where the fields are all two
decimal digits in length and
indicate, in order, the year,
month, day, hour and minutes.
AB TO: Address values Address parameters
AB YOURREF: [string]

Of the above, the keywords supported by X.400 and not by the API can still be accessed by an
application using the extensions CMC_X_IMS_GEN_HEADERS and
CMC_X_IMS_GEN_MESSAGE_HEADERS.

5 Must be present in messages sent by the API implementation to non-X.400 addresses if there are one or more
keyword lines included in the message.

Volume 2: User Services, Part 3: CMC Extensions, Page: 101


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Some values have a default (the default value for a string is a null string). On creating a header, if the
extension value is the same as the default shown in the above table the header line should not be
included. On reading a header, if a header line is absent, the default value (if present) is assumed
and shall be included in any appropriate extensions requested by the user.

Parameter values cannot be abbreviated except where shown in the above table.

5.4.1 Addressing Syntax


The following table gives the complete set of Basic X.400 address parameter keywords:

Keyword Meaning
A= admin-domain-name
C= country-name
CN= common name
DT = type
DV= value
DR delivery report requested
FREE= free field
G= given name
I= initials
NID= user agent numeric id
O= organisation
OU1= organisational unit1
OU2= organisational unit2
OU3= organisational unit3
OU4= organisational unit4
P= private-domain-name
Q= generation qualifier
REPLY reply requested
S= surname
TID= terminal-id
TTY= terminal type
X121= network-address

No Basic X.400 parameter keywords can be abbreviated. The CMC API implementation should be
able to read and write header lines with Basic X.400 addresses. The following steps will convert
X.400 CMC recipient addresses to header line address:

1 Sort addresses into recipient roles (“To”, “CC” and “BCC”).

2 Add DR and REPLY parameters if present in recipient extensions and not already present in
addresses.

3 Strip off the X400: prefix from the addresses.

4 Concatenate all “To” addresses together separating each address with a comma (“,”) and put
the resulting string after TO: as a header line.

Volume 2: User Services, Part 3: CMC Extensions, Page: 102


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

5 Repeat step 4 with “CC” and “BCC” addresses. Only include the appropriate header line if
there is one or more address to follow.

CMC API addresses are encoded in the header in the same form used in the recipient address fields.
It is strongly recommended that unnecessary white spaces in the address are removed. It is
recommended that the CMC implementation has a configuration option of using either the long or
short forms of keywords and values in the header.

The full list of destination prefixes can be found in Section 3.3.1. The full list of parameter keywords
(abbreviations underlined), for these destination prefixes is shown in the table below (see section 3.3
for the valid parameters for each address):

Parameter Keyword Parameter Value

ACKNOWLEDGEMENT

ADDRESS= see sections 3.3.4 and 3.3.5

AUTOMATIC

CANCEL= see section 3.3.5

COMMAND= see section 3.3.4

DIRECTION= see section 3.3.6

DR
DUPLICATE

ECHO

EGCINTERVAL= see section 3.3.5

EXTRA= see section 3.3.6

FRAME= see section 3.3.4

ID= see section 3.3.4

INTERVAL= see section 3.3.4

LES= see sections 3.3.2 to 3.3.6

MEMBER= see section 3.3.4

MTR

NAME= see sections 3.3.2, 3.3.3, and 3.3.5

NATURE see section 3.3.6

NOHEADERS

POSITION see section 3.3.6

PROTOCOL= see section 3.3.4

RANDOM= see section 3.3.2-3.3.4, and 3.3.6

REGION= see section 3.3.2

Volume 2: User Services, Part 3: CMC Extensions, Page: 103


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

REPEATS= see section 3.3.5

REPLY see section 3.3.2 to 3.3.4

RR

SEQNUM= see section 3.3.4

SERVICE= see section 3.3.5

SPEED= see section 3.3.6

SUBADDRESS= see section 3.3.4

TIMEOFPOSITION= see section 3.3.6

The address line parameters NOHEADERS, DR, and RANDOM should not be included in the TO, FROM
and CC addresses in the message header (unless included in the user default originator address).

The CMC API implementation should create TO, FROM, and CC lines with valid addresses.
However, on message reception, it should be prepared to accept completely free format strings such
as

FROM:Fred Bloggs

in this case the CMC implementation shall set the name field of the recipient to be the free format
string and shall set the address field to NULL..

5.4.2 Attachments (ATTACH)


Attachments are concatenated with the message but an additional header line of the form:

ATTACH: [Byte Offset]


|[Byte Offset][Parameter Keywords and Values]

is included for each attachment where

[Byte Offset] is the byte offset from the start of the first body part. Zero indicates there is no data in
the first body part and the first attachment starts immediately after STX:<New line>. The [Byte Offset]
is always the count from the start of the first line following STX: and the attachment continues to the
start of the next attachment or the end of the file.

FILE, BILAT, and EXT are valid parameter keywords with FILE taking a filename string and BILAT
and EXT taking a bilaterally defined string and an OID respectively (values follow the parameter
keyword and an equality sign ("="). By default the FILE is a NULL string and the attachment type is
CMC_ATT_OID_BINARY.

For example, the header line:

ATTACH:263;FILE=LETTER.DOC

Indicates that the file LETTER.DOC is a binary file of message type CMC_ATT_OID_BINARY and
starts at byte 263 after the start of the line following STX:.

5.4.3 Content and Body Types


5.4.3.1 Interpersonal Messages

Volume 2: User Services, Part 3: CMC Extensions, Page: 104


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Interpersonal messages are passed to and from CMC with a value “CMC: IPM” in the message_type
field in the message structure. Interpersonal messages are the default Inmarsat-C message type and
is assumed if the CONTENTTYPE header keyword is not present. CMC implementations sending
CMC: IPM messages should not include the CONTENTTYPE header line in the message.

CMC messages with a type CMC: IPM may have several body parts. The first body part is a text note
of type CMC_ATT_OID_TEXT (the first body part may be NULL); CMC attachments may have any
type. When creating Inmarsat-C message headers for CMC messages, the attachment type should
be given in the ATTACH keyword line (if other than CMC_ATT_OID_BINARY). See section 5.4.2 of
this document for the encoding of attachment types into the ATTACH: keyword line. Converting
received Inmarsat-C message headers into CMC messages is straightforward when the ATTACH:
keyword is present; the attachment types are given in the ATTACH: message header lines. If the
ATTACH: keyword is not present, the creation of CMC messages depends on the presentation code
and, in the X.400 case, the EIT: and BODYTYPE: header lines. The different cases are shown
below:

Presentation Code Action

ITA2 or IA5 Contents of message in text note; no attachments

Data Contents of message in first attachment


Contents of message in first attachment if EIT or
Basic X.400
BODYTYPE is not IA5.

5.4.3.2 Receipt and Non-Receipt Notifications

Receipt and non-receipt reports are carried over the Inmarsat-C protocol using the CMCRN and
CMCNRN values for the CONTENTTYPE header line. Non-receipt reports will normally contain a
REASON line (after the Inmarsat-C Message Header, not within it) giving the cause of non-receipt
(appropriate syntax for these lines is given in section 3.2.7). Receipt and non-receipt reports should
be sent without repeating the message text or attachments but should contain all enabled Inmarsat-C
header lines. It is recommended that a CMC implementation receiving a receipt or non-receipt report
include the original text note and attachment if possible by matching the YOURREF: value in the
receipt or non-receipt with the OURREF: value in the original message.

5.4.3.3 Other Content Types

CMC messages with other values of message_type have the message_type given in the
CONTENTTYPE message header line. Message attachments are encoded as for IPM. For received
messages, the creation of CMC messages is again straightforward if the ATTACH: keyword is present
and depends on the presentation code of the ATTACH: keyword is not. However, in this case, all
Basic X.400 messages are viewed as having a binary content and the message contents is therefore
always in the first attachment:

Presentation Code Action

ITA2 or IA5 Contents of message in text note; no attachments

Data Contents of message in first attachment

Basic X.400 Contents of message in first attachment.

5.4.4 Delivery Times


The time that the message was delivered to the CMC implementation should be presented to the
application using the CMC_X_COM_TIME_RECEIVED extension if this extension has been
requested. The DELTIME header line (which shows the time that the X.400 message was received at

Volume 2: User Services, Part 3: CMC Extensions, Page: 105


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

the LES) is not to be used for the extension value but may be extracted by an application using the
CMC_X_IMS_GEN_MESSAGE_HEADERS extension.

5.4.5 Importance Indication (IMPORTANCE)


The following are acceptable values:

LOW
NORMAL
HIGH

The default importance indication is NORMAL.

5.4.6 Encryption (Body Part) (ENCRYPTION)


This keyword indicates that the message or an attachment has been encrypted in some unspecified
way (See X.400 EOS B.9).

5.4.7 Forward Indication (FORWARD)


This keyword indicates that a forwarded IP-message or a forwarded IP-message and its "delivery
information" forms either the message or an attachment.

5.4.8 Sensitivity Indication (SENSITIVITY)


The following values are acceptable (See X.400 EOS B.80):

DEFAULT
PERSONAL

PRIVATE

CONFIDENTIAL

where CONFIDENTIAL maps to COMPANY-CONFIDENTIAL.

5.4.9 IP-Reference Numbers


IP references are carried using the OURREF and YOURREF keywords with free-format string values.
The references are passed through CMC using the extensions CMC_X_IMS_GEN_IP_REFERENCE
and CMC_X_IMS_GEN_YOUR_IP_REFERENCE respectively. If these extensions are not used, or if
the string is NULL then, on creating a header the OURREF and YOURREF keywords will not be
included. On receiving a header, if the OURREF and YOURREF keywords are not present, the
extension pointers shall be NULL.

Volume 2: User Services, Part 3: CMC Extensions, Page: 106


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

5.5 Delivery, Receipt and Reply Requests


Notifications can be requested by an application on a per recipient basis, although the following rules
apply:

i) Delivery reports are requested on Inmarsat-C on a per message basis. Each discrete Inmarsat-
C from-mobile message is addressed to one or more recipients residing on the same
destination network. In the from-mobile direction for a CMC message to a mixture of Inmarsat-
C destination networks, if any recipients on a particular destination network have a delivery
confirmation requested, delivery confirmation will be requested on the whole message to that
network and therefore for all such recipients.

ii) It may be difficult for an application to recognise its own address (which may be in a variety of
formats) and consequently difficult to determine whether a receipt and/or a reply has been
requested. Applications may check all “To” and “CC” recipients to determine if any recipient
has receipt or reply requested.

5.5.1 Delivery Report Requests


Applications may use the extension CMC_X_IMS_GEN_REQUEST_DELIVERY_REPORT to request
delivery report or add the keyword DR to the address line. If the keyword or the extension is present,
the CMC implementation should include the delivery report request keyword in the appropriate header
address line.

The notification will arrive as a message of type CMC: IP DR or CMC: IP NDR.

For example, the address

TELEX: 5551234; DR

will generate a request for a delivery report for this message.

Note non-delivery reports are automatic in the Inmarsat-C system and do not need to be requested.

5.5.2 Receipt Report Requests


Applications may use the extension CMC_X_IMS_GEN_RECEIPT_NOTIFICATION to request receipt
and non-receipt reports or add RR to the address line. If the keyword or the extension is present, the
CMC implementation should include the receipt report request keyword in the appropriate header
address line.

If a report arrives it will be a message of type CMC: IP RN or CMC: IP NRN. For example, the
address:

TELEX: 5551234; RR

will generate a request for a receipt report for this message and this recipient.

5.5.3 Reply Requests


Applications may use the extension CMC_X_IMS_GEN_REQUEST_REPLY to request a reply or add
REPLY to the address line. If the keyword or the extension is present, the CMC implementation
should include the reply request keyword in the appropriate header address line.

An IPM message may arrive as a result of the recipient's action.

For example the address:

TELEX: 5551234; REPLY

Volume 2: User Services, Part 3: CMC Extensions, Page: 107


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

will generate an indication of a reply request for this recipient.

6 Examples

6.1 Discussion of Examples from the CMC Specification


Please refer to the Common Message Call API document (RD.1), Section 5 (Programming Examples)
in order to understand the comments in the following sections.

6.1.1 Query Configuration, Logon and Logoff Example


1 It is up to the API implementation whether or not a user interface is supported.

2 The API implementation for an MES may check if the MES is logged in to the Inmarsat-C
network on a successful call to cmc_logon(), and if not initiate a login request. If present, this
API implementation feature should be controllable by the user (for example, by an initialisation
file or set-up menu).

3 On a terrestrial implementation of the API for Inmarsat-C, cmc_logon() does not cause a
connection to be set-up with an LES.

4 This document makes no requirements on the API implementation user names and passwords.
The API implementation may ignore the user and password strings completely or may have an
elaborate security system. Usernames can, however, provide a useful way of storing a
particular initialisation profile such as the default LES etc.

5 cmc_logoff() should not cause the MES implementation of the API to initiate an MES logout.
Inmarsat-C network logouts must be explicitly requested using the CMC extensions, through
some API implementation user interface, or using some other software specific to the MES.

6.1.2 Send and Send Documents Functions Example


1 The example uses "friendly" names to address the message to be sent and assumes an
address book has been implemented and that the addresses "Bob Weaver" and "Mary Yu" are
known to the address book. Address-books may or may not be included in an Inmarsat-C
implementation of CMC.

2 The structure of the message sent over the Inmarsat-C network depends on the default settings
for the API headers (see Section 4.4.1.4). Assuming that all header keywords have been
enabled and if the user has set-up a default "from" address of "TELEX:581499999999" and
"Bob Weaver" resolves to "TELEX: 5512345" and "Mary Yu" resolves to "TELEX: 5554321", the
message sent will be:

SHDR:
TO:TELEX:5512345
CC:TELEX:5554321
FROM:TELEX:581499999999
SUBJECT:Stock
ATTACH:11;FILE="STOCK.WKS"
STX:
Time to buy
<contents of file tmp22.tmp>

The ATTACH line contains no attachment type because there is a default value of
CMC_ATT_OID_BINARY.

Volume 2: User Services, Part 3: CMC Extensions, Page: 108


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6.1.3 List, Read, and Delete the First Unread Message Example
1 To be CMC compliant, a flag must be held with each message to indicate whether or not it has
been read.

6.1.4 Lookup a Specific Recipient and Get its Details Example


1 Address books may or may not be included in an Inmarsat-C implementation of CMC.

6.1.5 Use of Extensions Example


1 Inmarsat-C implementations of CMC should respond to cmc_query_configuration() in the
example shown with CMC_X_COM_NOT_SUPPORTED unless all the common extension set
is supported.

6.2 Examples Using Inmarsat-C Extensions

6.2.1 cmc_logon() with Inmarsat-C Extensions


#define BLAAVAND 131
/* local variables used */

CMC_return_code Status;
CMC_session_id Session;
CMC_extension Extensions[2];

/* setup the extensions structure with two Inmarsat-C extensions */

Extensions[0].item_code = CMC_X_IMS_GEN_LES_ID;
Extensions[0].item_data = BLAAVAND;
Extensions[0].item_reference = (CMC_buffer)NULL;
Extensions[0].extension_flags = 0;
Extensions[1].item_code = CMC_X_IMS_MES_LOGIN_FLAG
Extensions[1].item_data = CMC_X_IMS_LOGGED_IN;
Extensions[1].item_reference = (CMC_buffer)NULL;
Extensions[1].extension_flags = CMC_EXT_LAST_ELEMENT;

Status = cmc_logon(
NULL, /* Default service. */
NULL, /* Prompt for username. */
NULL, /* Prompt for password. */
NULL, /* Default Character set. */
(CMC_ui_id)NULL, /* Default UI ID. */
CMC_VERSION, /* Version 1 CMC calls. */
CMC_LOGON_UI_ALLOWED | /* Full logon UI. */
CMC_ERROR_UI_ALLOWED, /* Use UI to display errors. */
&Session, /* Returned session id. */
&Extensions); /* Logon extensions. */
/* error handling */

/* Do various CMC calls */

/* Log off from the implementation */


Status = cmc_logoff(
Session, /* Session ID */
(CMC_ui_id)NULL, /* No UI will be used */
0, /* No flags */
NULL); /* No extensions */
/* error handling */

Volume 2: User Services, Part 3: CMC Extensions, Page: 109


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Notes:

1 Besides creating a cmc session id for the user, this call will set the default LES ID to be used
for this session to the Blaavand LES, and also ensure that the MES is logged in (if the MES is not
already logged in, a login request will be issued). The region that the user is logged into is not,
however, defined in the example.

6.2.2 MES logon to the IOR


#define IORNCS 344/* local variables used */

/* local variables used */

CMC_return_code Status;
CMC_session_id Session;
CMC_extension Extensions[2];
CMC_boolean UI_available;

/* assume a session has already been created with cmc_logon() */

/* setup the extensions structure with two Inmarsat-C extensions */

Extensions[0].item_code = CMC_X_IMS_MES_CURRENT_NCS;
Extensions[0].item_data = IORNCS;
Extensions[0].item_reference = (CMC_buffer)NULL;
Extensions[0].extension_flags = 0;
Extensions[1].item_code = CMC_X_IMS_MES_LOGIN_FLAG
Extensions[1].item_data = CMC_X_IMS_LOGGED_IN;
Extensions[1].item_reference = (CMC_buffer)NULL;
Extensions[1].extension_flags = CMC_EXT_LAST_ELEMENT;

/* retune and login to the IOR if the MES isn't tuned to the IOR and */
/* already logged in. */

Status = cmc_x_set_configuration(
CMC_session_id, /* Session ID. */
(CMC_ui_id)NULL, /* Default User ID */
&Extensions); /* Extensions */
/* Error Handling */

/* wait until the MES is logged in or until the login fails */


while (Status == cmc_success &&
Extension[1].item_data == CMC_X_IMS_LOGIN_COMMAND_ISSUED)
{ /* Wait a while (10 seconds or more) and check again */
/* . . . */

Status = cmc_query_configuration(
CMC_session_id, /* Session ID. */
CMC_CONFIG_UI_AVAIL, /* See if UI is available */
&UI_available, /* Return value (ignored) */
&Extensions; /* Extensions */
};
if (Extensions[1].item_data != CMC_X_IMS_LOGGED_IN ||
Extensions[0].item_data != IORNCS)
/* Error Handling */

Notes:

1 This example assumes that a CMC session has already been created and uses
cmc_x_set_configuration() to define the new NCS TDM and issue a login if necessary.
Retuning, or logging in, will only be done if necessary. If the MES is already tuned logged in to
the IOR NCS (ID 344) then the first call to cmc_x_set_configuration() will return a value of
CMC_X_IMS_LOGGED_IN in Extensions[1].item_code.

2 After the cmc_x_set_configuration(), the program repeatedly calls cmc_query_configution()


until the login command has been processed. Two checks are then made, firstly that the MES
is now logged in (returned in the first extension) and the second that the MES is logged into the

Volume 2: User Services, Part 3: CMC Extensions, Page: 110


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

correct NCS. If the MES failed to login to the NCS, some MESs or implementations may
choose to return the MES to the previous region keeping the login status as logged in so it is
important that an application should also check the NCS ID.

6.2.3 Using CMC to Send a Message with no API Header


/* local variables used */

extern CMC_X_IMS_keyword_list zero_keys;


CMC_session_id Session;
CMC_message Message;
CMC_return_code Status;
CMC_extension Extension;
CMC_X_IMS_keyword_list Keywords = zero_keys;/* No keys set */

/* Assumes a session has already been setup */


/* The message structure is setup here*/

/* ... */

/* Setup the extensions structure */

Extension.item_code = CMC_X_IMS_GEN_HEADERS;
Extension.item_data = 0;
Extension.item_reference = (CMC_buffer)&Keywords; /* No headers */
Extension.extension_flags = CMC_EXT_LAST_ELEMENT;

/* Send the message */

Status = cmc_send(
Session, /* Session ID. - set with logon call*/
&Message, /* Message structure. */
0, /* No flags. */
(CMC_ui_id)NULL, /* No UI will be used. */
&Extension); /* No extensions. */
/* error handling */

Notes:

1 The item_reference field in the extensions is an array of of flags with one flag for each header
keyword to be supported. A value of zero in a field means that the particular flag is not set set,
otherwise the flag is set.

6.2.4 Sending a Data Report


/* It is assumed that an MES and an implementation of CMC is available */
/* This could also be done using cmc_send */

Status = cmc_send_documents(
"to:DNID:ID=12345;LES=102;PROTOCOL=DATAREPORT",
/* Message recipients. */
"", /* Message subject.*/
"", /* Message note.*/
CMC_LOGON_UI_ALLOWED |
CMC_ERROR_UI_ALLOWED, /* Flags (allow various UI's).*/
"tosend.dat", /* File to attach containing data*/
"", /* File name to carry on attach. */
",", /* Multi-value delimiter. */
NULL); /* Default UI ID. */
/* error handling */

Notes:

1 The address parameter “PROTOCOL=DATAREPORT” forces the API implementation to use


the data reporting protocol to send this data. If too much data is supplied in the file tosend.dat,
an error status code (CMC_E_TEXT_TOO_LARGE) will be returned.

Volume 2: User Services, Part 3: CMC Extensions, Page: 111


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2 The message subject, and the filename to carry on the attachment cannot be carried so are not
included in the call.

6.2.5 Receiving a Data Report


/* This example is based on a Weather Station Example.
Receive (at the central station) a temperature report */

#define NO_FLAGS 0
#define NO_UI_ID 0
#define NO_EXTENSION ((CMC_extension *) NULL)
#define NO_MESSAGE_REFERENCE ((CMC_message_reference *) NULL)

void receive_temp_report (CMC_session_id session)


{CMC_return_code status;
CMC_message_summary *pSum, *pIdx;
CMC_message *pMsg;
char *subject;
CMC_uint32 iCount; /* list at most that many messages */
char *reportFilename; /* filename of report data*/
iCount = 4;
status = cmc_list ( session, /* session id */
NULL, /* list all msg types */
CMC_LIST_UNREAD_ONLY, /* only unread msgs */
NO_MESSAGE_REFERENCE, /* starting at the top */

& iCount, /* msg count */


NO_UI_ID, /* no UI */
& pSum, /* return msg summary array */
NO_EXTENSION); /* no extensions */
/* error handling */
/* get the data reports */

for (pIdx = pSum; pIdx < pSum + iCount; pIdx++) {


subject = (char *)pIdx->subject;

if ( strstr(subject,"Data Report") == subject ) { /* a data report */


status = cmc_read ( session,
pIdx->message_reference,
NO_FLAGS,
& pMsg,
NO_UI_ID,
NO_EXTENSION);
if (status != CMC_SUCCESS); /* error handling */
if ( pMsg->attachments == NULL ); /* error handling - at least
one attachment expected */
reportFilename = (CMC_string *)pMsg->attachments->attach_filename;

/* error handling */
/* process report data in file "reportFilename" */
}
status = cmc_free((CMC_buffer) pMsg);
if (status != CMC_SUCCESS); /* error handling */
}
status = cmc_free((CMC_buffer) pSum);
if (status != CMC_SUCCESS); /* error handling */
}

6.2.6 Sending a Poll


/* This example is based on a Weather Station Example. Send (from the central
system) a request to all stations within a geographical area to program regular
temperature reports using the unreserved data reporting protocol (command 0x04). An
additional message must be sent later to initiate the reports (command 0x05 */

#define POLL_COMMAND_PROGRAM_UNRESERVED_DATA_REPORT 0x04

#define NO_FLAGS 0
#define NO_UI_ID 0
#define NO_EXTENSION ((CMC_extension *) NULL)

#define MAX_LATITUDE 90

Volume 2: User Services, Part 3: CMC Extensions, Page: 112


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

#define MAX_LONGITUDE 180


#define MAX_ADDR_LEN 256

typedef CMC_uint16 Degrees;


extern CMC_time zero_time; /* CMC_time struct with all fields zero */

/* A session must have been established. It is assumed that the parameters have
already been checked for invalid values */

CMC_return_code program_temp_report_request (
CMC_session_id session,
CMC_X_IMS_network_id *dnid,
CMC_X_IMS_geographical_coordinates *areaOrigin,
Degrees extent_north, Degrees extent_east, int
frame, long interval)
{
CMC_message request;
CMC_recipient recip;
char addr[MAX_ADDR_LEN];
/* setting up destination address */
sprintf ( addr,
"DNID:ID=%d;ADD=R%d%c%d%c%dX%d;CO=%d;PR=DATAREPORT;FRA=%d;IN= %ld",
dnid->id, areaOrigin->latitude_degrees, areaOrigin->North_south,
areaOrigin->longitude_degrees, areaOrigin->East_west,
extent_north, extent_east,
POLL_COMMAND_PROGRAM_UNRESERVED_DATA_REPORT, frame, interval);

recip.name = NULL;
recip.name_type = CMC_TYPE_UNKNOWN;
recip.address = (CMC_string) & addr;
recip.role = CMC_ROLE_TO;
recip.recip_flags = CMC_RECIP_LAST_ELEMENT;
recip.recip_extensions = NULL;

/* setting up the message structure */


request.message_reference = NULL;
request.message_type = NULL; /* ignored - could be NULL */
request.subject = NULL;
request.time_sent = zero_time; /* zero'ed CMC_time */
request.text_note = NULL;
request.recipients = & recip;
request.attachments = NULL; /* if there were Free field text it would
go in an attachment */
request.message_flags = NO_FLAGS;
request.message_extensions = NULL;

/* Send Message */
return cmc_send (session, & request, NO_FLAGS, NO_UI_ID, NO_EXTENSION);

6.2.7 Receiving a Poll


/* This example is based on a Weather Station Example.
Example 2: Receive (at a weather station) the poll of the previous example -
programming an unreserved data report */

#define NO_FLAGS 0
#define NO_UI_ID 0
#define NO_EXTENSION ((CMC_extension *) NULL)
#define NO_MESSAGE_REFERENCE ((CMC_message_reference *) NULL)
void receive_poll (CMC_session_id session)
{
CMC_return_code status;
CMC_message_summary *pSum, *pIdx;
CMC_message *pMsg;
char *subject;
CMC_uint32 iCount; /* list at most that many messages */
iCount = 4;
status = cmc_list ( session, /* session id */
NULL, /* list all msg types */
CMC_LIST_UNREAD_ONLY, /* only unread msgs */
NO_MESSAGE_REFERENCE, /* starting at the top */
& iCount, /* msg count */
NO_UI_ID, /* no UI */

Volume 2: User Services, Part 3: CMC Extensions, Page: 113


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

& pSum, /* return msg summary array */


NO_EXTENSION); /* no extensions */

/* error handling */

/* get the POLL messages */


for (pIdx = pSum; pIdx < pSum + iCount; pIdx++) {
subject = (char *) pIdx->subject;
if ( strstr(subject, "POLL:") == subject ) { /* a POLL message */
status = cmc_read ( session,
pIdx->message_reference,
NO_FLAGS,
& pMsg,
NO_UI_ID,
NO_EXTENSION);
if (status != CMC_SUCCESS); /* error handling */

/* process poll message. Any text in the free field of the poll will be in the
first attachment of the poll message */
}
status = cmc_free { (CMC_buffer) pMsg);
if (status != CMC_SUCCESS); /* error handling */
}
status = cmc_free ( (CMC_buffer) pSum);
if (status != CMC_SUCCESS); /* error handling */
}

6.2.8. Sending a Land Mobile Alert


#define NO_FLAGS 0
#define NO_UI_ID 0

#define MAX_ADDR_LEN 256

extern CMC_time zero_time; /* CMC_time struct with zero values */

/* A session must have been established. Parameter range checking is


assumed to have already taken place. Because this is a user defined LMA, only the
position is required */

CMC_return_code send_user_defined_LMA (CMC_session_id session,


CMC_X_IMS_station_id les,
CMC_X_IMS_geographical_coordinates *position,
char *userDefinedDataFile)
{
CMC_extension ext;
CMC_message LMAmessage;
CMC_attachment att;
CMC_recipient recip;
char addr[MAX_ADDR_LEN];
CMC_X_IMS_land_mobile_alert LMAdata;

/* setting up destination address */


sprintf ( addr, "LMA:%d", les);
recip.name = NULL;
recip.name_type = CMC_TYPE_UNKNOWN;
recip.address = (CMC_string) & addr;
recip.role = CMC_ROLE_TO;
recip.recip_flags = CMC_RECIP_LAST_ELEMENT;
recip.recip_extensions = NULL;

/* setting up message extension to carry the LMA particulars */


LMAdata.nature_of_alert = 0; /* ignored */
LMAdata.land_position = *position;
LMAdata.time_of_position = 0; /* ignored */
LMAdata.speed = 0; /* ignored */
LMAdata.direction_of_travel = 0; /* ignored */
LMAdata.extra_info = 0; /* ignored */

ext.item_code = CMC_X_IMS_GEN_LAND_MOBILE_ALERT_DATA;
ext.item_data = 0; /* not used */
ext.item_reference = (CMC_buffer) & LMAdata;

Volume 2: User Services, Part 3: CMC Extensions, Page: 114


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ext.extension_flags = CMC_EXT_LAST_ELEMENT;

/* setting up an attachment to carry user defined data. The existence of an


attachment will cause the implementation to ignore the LMAdata fields except for
the land_position */
att.attach_title = NULL; /* ignored */
att.attach_type = NULL; /* default is binary */
/* user data should be in the first 3 bytes of the given file */
att.attach_filename = userDefinedDataFile;
att.attach_flags = CMC_ATT_LAST_ELEMENT;
att.attach_extensions = NULL;
/* setting up the message structure */
LMAmessage.message_reference = NULL; /* ignored */
LMAmessage.message_type = NULL; /* ignored */
LMAmessage.subject = NULL; /* ignored */
LMAmessage.time_sent = zero_time; /* ignored */
LMAmessage.text_note = NULL;
LMAmessage.recipients = & recip;
LMAmessage.attachments = & att;
LMAmessage.message_flags = NO_FLAGS;
LMAmessage.message_extensions = & ext;

/* Send Message */
return cmc_send (session, & LMAmessage, NO_FLAGS, NO_UI_ID, NULL);
}

Volume 2: User Services, Part 3: CMC Extensions, Page: 115


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Appendix 1: Elements of Service

Interpersonal Message
Orig Rec Supported By
Service Elements
1. Access Management N N
message_type in CMC message structure;
12. Content Type Indication M M
CONTENTTYPE in message headers
15. Converted Indication N N
22. Delivery Time Stamp CMC_X_COM_TIME_RECEIVED extension. (see
N M
Indication also DELTIME in message header)
CMC_X_IMS_IP_REFERENCE and
37. IP-Message CMC_X_IMS_YOUR_IP_REFERENCE
M M
Identification extensions. OURREF and YOURREF message
headers keywords
Combination of Inmarsat-C LES and Message
41. Message Identification M M
Reference number.
Message with type CMC:NDN (format defined).
Requested with
47. Non-Delivery
M N CMC_X_IMS_GEN_REQUEST_DELIVERY_REP
Notification
ORT extension or DR address line parameter
keyword
Message with type CMC:NRN (format defined).
Requested with
48. Non-Receipt Notification
N N CMC_X_IMS_GEN_REQUEST_RECEIPT_REPO
Request Indication
RT extension or RR address line parameter
keyword
Implicit from attachment types, attachment
filenames and/or content types. For Basic X.400,
54. Original Encoded the EIT header line may also be read from and
M M
Information Types Indication written to using the
CMC_X_IMS_GEN_MESSAGE_HEADERS
extension
92. Use of Distribution List M N Address book look ups
time_sent in CMC message structure. Carried in
89. Submission Time Stamp
M M Inmarsat-C messages and EGCs using SUBTIME
Indication
keyword
attach_type in CMC attachment structure. Carried
in Inmarsat-C message and EGCs using ATTACH
keyword. For Basic X.400, the BODYTYPE header
90. Typed Body M M
line may also be read from and written to using the
CMC_X_IMS_GEN_MESSAGE_HEADERS
extension

Key:

N Not supported

M Mandatory

E Extensions

Notes:

Not supported The IAPI will not support this service element.

Mandatory The IAPI is required to support this service element, however, in some instances,
the underlying DCE may not support it.

Volume 2: User Services, Part 3: CMC Extensions, Page: 116


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Extensions Elements of service which may be included in a future revision of the IAPI
specification.

These extensions apply to Store-and-Forward messages, but not to Polls, Data Reports, Enhanced
Group Calls or Distress Alerts. They apply both to MESs and to systems connected to LESs by
terrestrial networks.

Submission Delivery Orig Rec Supported By

3. Alternate Recipient Allowed


N N
19. Deferred Delivery
N N
20. Deferred Delivery Cancellation
N N
Messages of type CMC:DN and CMC:NDN.
Requested by
21. Delivery Notification CMC_X_IMS_REQUEST_DELIVERY_REPOR
M N
T extension or DR address line parameter
keyword.
CMC messages may have many recipient
25. Disclosure of Other Recipients structures. Recipient’s carried using TO and
M1 M
CC header lines.
CMC_X_COM_PRIORITY and
32. Grade of Delivery Selection CMC_X_IMS_GEN_PRIORITY. Carried over
M3 M3 Inmarsat-C using PRIORITY header line.
39. Latest Delivery Designation
N N
CMC messages may have many recipient
45. Multi-destination Delivery structures. Multi-destination delivery may result
M N
in several Inmarsat-C messages.
61. Prevention of Non-Delivery
Notification N N
68. Redirection Disallowed by
Originator N N
69. Redirection of Incoming
Messages N N
77. Restricted Delivery
N N

78. Return of Contents


N2 N
93. User/UA Capabilities
Registration N N
27. DL Expansion Prohibited
N N
44. Message Sequence Integrity
N N
56. Originator Requested
Alternative Recipient N N
CMC messages have a “From” recipient
55. Originator Indication structure. Originator contained in message
M M
using FROM header line.

Key:

N Not supported

Volume 2: User Services, Part 3: CMC Extensions, Page: 117


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

M Mandatory

E Extensions

Note:

1
Optional from calling application (with a default) whether full recipient list is available to all
recipients.

2
Structure of non-delivery notification allows for return of contents by the IAPI layer so
implementations can (optionally) support it.

3
Distress priority messages may be fully supported in a future release of the API document.

These extensions apply to Store-and-Forward messages, but not to Polls, Data Reports, Enhanced
Group Calls or Distress Alerts. They apply both to MESs and to systems connected to LESs by
terrestrial networks.

Conversion Orig Rec

13. Conversion Prohibition N N


14. Conversion Prohibition in case
N N
of loss of information
30. Explicit Conversion N N

34. Implicit Conversion N N

Key:

N Not supported

M Mandatory

E Extensions

These extensions apply to Store-and-Forward messages, but not to Polls, Data Reports, Enhanced
Group Calls or Distress Alerts. They apply both to MESs and to systems connected to LESs by
terrestrial networks.

Status and Inform Service


Orig Rec Supported By
Elements
63. Probe
N N
64. Probe Origin Authentication
N N
4. Alternate Recipient
Assignment N N
33. Hold for Delivery
N N
42. Message Origin
Authentication N N
43. Message Security Labelling
N N

Volume 2: User Services, Part 3: CMC Extensions, Page: 118


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

11. Content Integrity


N N
The Inmarsat-C EGC and messaging protocols
using the header line INCOMPLETE. Access
36. Incomplete Copy Indication
M1 M through CMC via
CMC_X_IMS_GEN_MESSAGE_HEADERS only
40. Message Flow
Confidentiality N N
49. Non-repudiation of Delivery
N N
50. Non-repudiation of Origin
N N
51. Non-repudiation of
Submission N N
65. Proof of Delivery
N N
66. Proof of Submission
N N
74. Report Origin
Authentication N N
79. Secure Access
Management N N

Key:

N Not supported

M Mandatory

E Extensions

Note:
1 Incomplete Copy Indication can be provided by the originating UA.

These extensions apply to Store-and-Forward messages, but not to Polls, Data Reports, Enhanced
Group Calls or Distress Alerts. They apply both to MESs and to systems connected to LESs by
terrestrial networks.

Co-operating IPM UA
Orig Rec Supported By
Information Conveying
5. Authorising Users Indication
N N
The Inmarsat-C EGC and messaging protocols
using the header line ENCRYPTION. Access
9. Body Part Encryption Indication through CMC via
M M
CMC_X_IMS_GEN_MESSAGE_HEADERS
only
18. Cross-Reference Indication
N N
26. DL Expansion History
Indication N N
29. Expiry Date Indication
N N

Volume 2: User Services, Part 3: CMC Extensions, Page: 119


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The FORWARD keyword. Access through


31.Forwarded IP-Message CMC via
Indication M M CMC_X_IMS_GEN_MESSAGE_HEADERS
only
The Inmarsat-C EGC and messaging protocols
using the header line IMPORTANCE. Access
35. Importance Indication1 M M
through CMC via
CMC_X_IMS_GEN_MESSAGE_HEADERS
only
The Inmarsat-C EGC and messaging protocols
using the header line LANGUAGE. Access
38. Language Indication1 M M
through CMC via
CMC_X_IMS_GEN_MESSAGE_HEADERS
only
Attachments. Support over Inmarsat-C EGC
46. Multi-Part Body1 M M
and messaging protocols using the header
line(s) ATTACH
52. Obsoleting Indication
N N
CMC supports multiple recipients with To and
62. Primary and Copy Recipients CC roles. Supported over Inmarsat-C EGC and
Indication M M messaging protocols using TO and CC header
lines
OURREF and YOURREF header lines. Access
73. Replying IP-Message to these via CMC_X_IMS_IP_REFERENCE
Indication N N and CMC_X_IMS_YOUR_IP_REFERENCE
extensions respectively
CMC_X_IMS_GEN_REQUEST_REPLY
extensions and REPLY address line parameter.
72. Reply Request Indication Supported over Inmarsat-C EGC and
M M
messaging protocols by addition of REPLY
parameter to TO and CC header lines.
CMC message structure contains subject.
Supported over Inmarsat-C EGC and
88. Subject Indication
M M messaging protocols using the SUBJECT
header line

Key:

N Not supported

M Mandatory

E Extensions

Note:

1 These elements are neither required nor supported for X.400 messages.

These extensions apply to Store-and-Forward messages, but not to Polls, Data Reports, Enhanced
Group Calls or Distress Alerts. They apply both to MESs and to systems connected to LESs by
terrestrial networks.

Volume 2: User Services, Part 3: CMC Extensions, Page: 120


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Co-operating IPM UA Action Orig Rec Supported By

6. Auto-Forward Indication
N N
Can be supported by an implementation but
8. Blind Copy Recipient requires the sending of multiple messages.
Indication N M Information carried over Inmarsat-C using the
BCC header line.
10. Content Confidentiality
N N
24. Designation of Recipient by Friendly names can be held in CMC directory
Directory Name M1 N and accessed using cmc_look_up()
Receipt notifications can be requested using
67. Receipt Notification
CMC_X_IMS_GEN_REQUEST_RECEIPT_RE
Request Indication M M
PORT or the RR address line parameter
76. Requested Delivery Method
N N
Supported over the Inmarsat-C EGC and
messaging protocols using the header line
80. Sensitivity Indication2 M M
SENSITIVITY. Access through CMC via
CMC_X_IMS_GEN_MESSAGE_HEADERS
only

Key:

N Not supported

M Mandatory

E Extensions

Note:

1 Mandatory but it is acceptable to have a simple address book. Procedures or application


interfaces for updating and maintaining the address book are beyond the scope of this
document.

2 Sensitivity Indication is neither required nor supported for X.400 messages.

These extensions apply to Store-and-Forward messages, but not to Polls, Data Reports, Enhanced
Group Calls or Distress Alerts. They apply both to MESs and to systems connected to LESs by
terrestrial networks.

Physical Service Elements Orig Rec

23. Delivery via Bureau Fax Service


N N
2. Additional Physical Rendition
N N
7. Basic Physical Rendition
N N
16. Counter Collection
N N
17. Counter Collection with Advice
N N

Volume 2: User Services, Part 3: CMC Extensions, Page: 121


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

58. Physical Delivery by PDS


N N
59. Physical Forwarding Allowed
N N
60. Physical Forwarding Prohibited
N N
70. Registered Mail
N N
71. Registered Mail to Addressee in Person
N N
75. Request for Forwarding Address
N N
81. Special Delivery
N N
91. Undeliverable Mail with Return of
Physical Message N N
57. Physical Delivery by MHS
N N
28. EMS (Express Mail Service)
N N
53. Ordinary Mail
N N

Key:

N Not supported

M Mandatory

E Extensions

Message Store Orig Rec

82. Stored Message Alert


E E
83. Stored Message Auto-forward
E E

84. Stored Message Deletion


E
E
85. Stored Message Fetching
E E
86. Stored Message Listing
E E
87. Stored Message Summary
E E

Key:

N Not supported

M Mandatory

E Extensions

Volume 2: User Services, Part 3: CMC Extensions, Page: 122


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The application of these extensions to Store-and-Forward messages, Polls, Data Reports, Enhanced
Group Calls, Distress Alerts, MESs and systems connected to LESs by terrestrial networks is for
further study.

Inmarsat-C MES
Orig Rec Supported By
Management
CMC_X_IMS_MES_GEOGRAPHICAL_COOR
107. Geographical Coordinates
M M DINATES extension
CMC_X_IMS_MES_NAV_EQUIPMENT
108. Manual/NAV Equipment
M M extension
109. LES CMC_X_IMS_GEN_LES_ID extension
M M
CMC_X_IMS_MES_ABORT_CURRENT_OPE
110. Abort Current Operation
M M RATION extension
CMC_X_IMS_MES_CLEAR_WAITING_MESS
111. Clear Waiting Message
M N AGES extension
112. PVT Test CMC_X_IMS_MES_PVT_TEST extension
M N
113. Message Delivery Status CMC_X_IMS_GEN_MSG_STATUS_ENQUIRY
Request M N . See also section 4.8.3.
Printer management supported (see service
137. Peripheral Management element 139). Geographical coordinates
M M
supported by service elements 107 and 108
CMC implementations for specific MESs or
140. Vendor Specific
M M LESs can have their own CMC extension sets

Key:

N Not supported

M Mandatory

E Extensions

These elements apply to MESs, but not to systems connected to LESs by terrestrial networks.

Inmarsat-C Access Control Orig Rec Supported By

CMC_X_IMS_MES_NCS_TDM_CHANNEL
101. NCS TDM Channels
M M extension
CMC_X_IMS_MES_PREFERRED_NCS
102. Preferred NCS
M M extension
CMC_X_IMS_MES_CURRENT_NCS and
103. Login
M M CMC_X_IMS_MES_LOGIN_FLAG extensions
104. Logout CMC_X_IMS_MES_LOGIN_FLAG extension
M M
105. Scan CMC_X_IMS_MES_SCAN extension
M M
CMC_X_IMS_MES_CURRENT_NCS
106. Tune to new NCS
M M extension

Key:

N Not supported

Volume 2: User Services, Part 3: CMC Extensions, Page: 123


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

M Mandatory

E Extensions

These elements apply to MESs, but not to systems connected to LESs by terrestrial networks.

Inmarsat-C Status
Orig Rec Supported By
Information
CMC_X_IMS_MES_SIGNAL_STRENGTH
114. Signal Strength
N M extension
115. BB error rate CMC_X_IMS_MES_BB_ERROR_RATE extension
N M
CMC_X_IMS_MES_CURRENT_CHANNEL_NUM
116. Channel number
N M BER extension
117. Message Transfer CMC_X_IMS_MES_MESSAGE_TRANSFER_STA
Status1 N M TUS extension
CMC_X_IMS_MES_NETWORK_INFORMATION
118. Network Information
N M extension
119. PVT Result CMC_X_IMS_MES_PVT_REPORT extension
N M
CMC_X_IMS_MES_CURRENT_ACTIVITY
121. Current Activities1 N M extension
CMC_X_IMS_MES_AVAILABLE_MES_ MEMORY
121. Available Memory
N M extension
122. Protocol Indication and
Carried as CMC message.
Alarms1 N M
CMC_X_IMS_MES_LOGIN_FLAG and
135. Ocean Region
N M CMC_X_IMS_MES_CURRENT_NCS extensions
136. LES / NCS Number CMC_X_IMS_MES_CURRENT_CHANNEL
N M
CMC_X_IMS_MES_CURRENT_FRAME_NUMBE
138. Current Frame Number
N M R extension
CMC_X_IMS_MES_PRINTER_MANAGEMENT
139. Printer Status1 N M extension
Message Transfer Report messages requested
141. Message Accepted at with
LES N M CMC_X_IMS_GEN_REQUEST_MESSAGE_TRAN
SFER_REPORT or MTR address line parameter

Key:
N Not supported

M Mandatory

E Extensions

Note:

1 Enumeration needed of status information, examples: low memory, HPA over-temperature.

These elements apply to MESs, but not to systems connected to LESs by terrestrial networks.

Volume 2: User Services, Part 3: CMC Extensions, Page: 124


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Inmarsat-C Data Reporting


Orig Rec Supported By
and Polling (MES)
123. Manage Downloaded
CMC_X_IMS_DRP_DNID_MGMT
DNIDs M M
Data reports viewed as a message with DNID
124. Send Data Report
M M address.
Polls viewed as a message with DNID address.
125. Receive Poll (including
Additional data carried as address line
contents) N M1 parameters

126. Respond to Program Polls


E1 E1
142. Sub-address
SUBADDRESS address keyword
Management M M
143. Current DCE Programs
N E

Key:

N Not supported

M Mandatory

E Extensions

Note:

1 Includes an indication of whether the DCE is, if needed, responding to the poll.

These elements apply to MESs, but not to systems connected to LESs by terrestrial networks.

Inmarsat-C EGC (MES) Orig Rec Supported By


(Support from API not required. GMDSS
129. NAVAREA Code
N N restrictions).
(Support from API not required. GMDSS
130. NAVTEX Code
N N restrictions).
131. Manage Downloaded
CMC_X_IMS_MES_ENID_MGMT extension
ENIDs M M
EGCs are treated as ordinary CMC messages.
132. Receive EGC EGC specific data is passed on the address
N M1 line.

Key:

N Not supported

M Mandatory

E Extensions

Note:
1 Includes all fields in EGC header.

These elements apply to MESs, but not to systems connected to LESs by terrestrial networks.

Volume 2: User Services, Part 3: CMC Extensions, Page: 125


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Inmarsat-C Emergency and


Orig Rec Supported By
Distress

127. Maritime Distress protocol indication and alarm message in mailbox


N M1
LMA addressing structure and
128. Land Mobile Emergency
CMC_X_IMS_GEN_LAND_MOBILE_ALERT_DAT
Alert M M1 A extension

Key:

N Not supported

M Mandatory

E Extensions

Note:
1 If initiated automatically (e.g. via distress button), DTE should be informed.

These elements apply to MESs, but not to systems connected to LESs by terrestrial networks.

Inmarsat-C Data Reporting,


Polling and EGC (Land Orig Rec Reference
System)
Data reports are treated as ordinary CMC
124a. Receive Data Report messages. Member number is included in
N M
address line.
Polls are treated as ordinary CMC messages.
125a. Send Poll Address line parameters can be used for
M N
command types, programming poll details etc.
EGCs are treated as ordinary CMC messages.
132a. Send EGC Address line parameters can be used for
M N
addressing, service codes etc.

Key:

N Not supported

M Mandatory

E Extensions

These elements apply systems connected to LESs by terrestrial networks, but not to MESs.

Volume 2: User Services, Part 3: CMC Extensions, Page: 126


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Descriptions
Inmarsat-C Access Control

101. NCS TDM Channels

This element of service enables the mobile UA to manage the set of known NCS TDM Channels.

102. Preferred NCS

This element of service enables the mobile UA to manage the Preferred NCS.

103. Login

This element of service enables the mobile UA to login to the Inmarsat-C network.

104. Logout

This element of service enables the mobile UA to logout of the Inmarsat-C network.

105. Scan

The element of service allows the mobile UA to initiate a scan.

106. Tune to new NCS

This element of service enables the mobile UA to be tuned to a particular NCS.

Inmarsat-C MES Management

107. Geographical Coordinates

This element of service enables the mobile UA to read and set the current position (possible uses
include EGC message reception, distress and position reporting).

108. Manual/NAV Equipment

This element of service enables the mobile UA to select whether position information is given by the
mobile UA or should be obtained directly from navigational equipment.

109. LES

This element of service enables the mobile UA to know the LES used for incoming messages and to
manage the LES to be used for outgoing messages.

110. Abort Current Operation

This element of service enables the mobile UA to abort the current operation.

111. Clear Waiting Message

This element of service allows messages waiting to be sent to be deleted from the DCE.

112. PVT Test

This element of service allows the mobile UA to initiate a PVT.

Volume 2: User Services, Part 3: CMC Extensions, Page: 127


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

113. Message Delivery Status Request

This element of service enables the delivery status of a message (previously sent) to be requested.

137. Peripheral Management

This element of service enables the mobile UA to manage the peripherals attached to the MES DCE.

140. Vendor Specific

This element of service enables the mobile UA to manage MES specific items.

Inmarsat-C Status Information

114. Signal Strength

This element of service enables the mobile UA to have visibility of the signal strength observed by the
MES.

115. BB error rate

This element of service allows the mobile UA to have visibility of the current Bulletin Board Error rate.

116. Channel

This element of service enables the mobile UA to have visibility of the channel number the MES is
tuned to.

117. Message Transfer Status

This element of service enables the mobile UA to have visibility of the status of a message transfer in
progress. Enumeration of states TBD.

118. Network Information

This element of service allows the mobile UA to have visibility of the current network information held
in the MES.

119. PVT Result

This element of service enables the mobile UA to have visibility of the results of the last PVT.

120. Current Activities

This element of service allows the mobile UA to have visibility of the current MES activities.
Enumeration of activities TBD.

121. Available Memory

This element of service enables the mobile UA to have visibility of the approximate amount of free
DCE memory for messaging.

122. Protocol Indication and Alarms

This element of service enables the mobile UA to have visibility of particular protocol related
messages and alarms.

Volume 2: User Services, Part 3: CMC Extensions, Page: 128


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

135. Ocean

This element of service enables the mobile UA to determine whether the MES is logged in and, if so,
to which Ocean Region.

136. LES/NCS Number

This element of service enables the mobile UA to determine the station, either NCS or LES, that the
MES is currently tuned to (this will change from the NCS to an LES during the MES send and receive
protocols).

138. Current Frame Number

This element of service enables the mobile UA to determine the current frame number.

139. Printer Status

This element of service enables the mobile UA to be informed of the current printer status (e.g. out of
paper). Enumeration of printer states TBD.

141. Message Accepted at LES

This element of service enables the mobile UA to determine the status of messages submitted to the
LES. Contents of status TBD, but possibly size, ARQ, time to send etc.

Inmarsat-C Data Reporting and Polling

123. Manage View Downloaded DNIDs

This element of service enables the mobile UA to manage the current set of downloaded DNIDs.

124. Send Data Report

This element of service enables the mobile UA to send a data report to a previously downloaded
DNID.

124a. Receive Data Report

This element of service enables a land-based UA to receive a data report that has been sent to a
DNID.

125. Receive Poll (including contents)

This element of service enables the mobile UA to identify poll contents (e.g. DNID, sub-address, free
field)

125a. Send Poll

This element of service enables a land-based UA to send a poll (of any kind).

126. Respond to Program Polls

This element of service enables the mobile UA to respond to Program Polls by sending Data Reports
or messages.

142. Sub-address Management

This element of service enables the mobile UA to manage polling and data reporting sub-addresses.

Volume 2: User Services, Part 3: CMC Extensions, Page: 129


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

143. Current DCE Programs

This element of service enables the mobile UA to determine data reporting programs previously
downloaded (in Polls).

Inmarsat-C EGC

129. NAVAREA Code

This element of service enables the mobile UA to manage primary and secondary NAVAREA codes
for receipt of certain EGC messages.

130. NAVTEX Code

This element of service enables the mobile UA to set the NAVTEX code for receipt of certain EGC
messages.

131. Manage Downloaded ENIDs

This element of service enables the mobile UA to manage previously downloaded ENIDs.

132. Receive EGC

This element of service enables the mobile UA to receive EGCs and all the header contents (service
code, priority, etc.).

132a. Send EGC

This element of service enables a land-based UA to send EGCs and all the header contents (service
code, priority, etc.).

Inmarsat-C Emergency and Distress

127. Maritime Distress

This element of service enables the mobile UA to send a Maritime Distress alert.

128. Land Mobile Emergency Alert

This element of service enables the mobile UA to send a Land Mobile alert.

Volume 2: User Services, Part 3: CMC Extensions, Page: 130


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Appendix 2: An Introduction to Inmarsat-C

1 The Inmarsat Communications System


The operational satellites in the system provide link between the mobile and the Land Earth Stations
(LES). Operated by Inmarsat Signatory organisations, LES's in turn act as the gateway between the
satellite link and the ground-based networks which carry communications to and from non-mobile
users.

The Inmarsat system consists of the following major elements in an ocean region:

a the space segment (including the Network Control Centre)

b the Network Co-ordination Station (NCS) and

c Land Earth Stations (LES)

d. mobiles, referred to as Mobile Earth Stations (MES)

NCS/NCS SIGNALLING LINK


NCS

NCS COMMON CHANNEL


INTERSTATION SIGNALLING LINKS

SIGNALLING
CHANNEL

SIGNALLING CHANNEL DTE

TELEX
NETWORK LES MESSAGE CHANNEL MES
(DCE)
DATA TDM CHANNEL
NETWORKS EGC

TERRESTRIAL NETWORKS

1.1 Space Element

The space segment, which includes the satellites and their associated ground support facilities, is the
responsibility of Inmarsat. It utilises a number of satellites to provide almost complete global coverage
with the exception of the polar regions, which cannot be seen by geostationary satellites.

There are four ocean regions:

- Atlantic Ocean Region West (AOR West)

- Atlantic Ocean Region East (AOR East)

- Indian Ocean Region (IOR)

- Pacific Ocean Region (POR)

Volume 2: User Services, Part 3: CMC Extensions, Page: 131


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Satellite utilisation is co-ordinated by the Inmarsat Network Operation Centre (NOC) in London.

1.2 Network Co-ordination Station

Each ocean region is served by a Network Co-ordination Station (NCS) which manages the allocation
of central resources such as traffic and signalling channels.

The NCS controls the access rights of Mobile Earth Stations. Every MES that is active in an ocean
region is required to log in to the Network: a copy of the list of all registered MESs is held at each
LES. When an LES receives a call for an MES from a terrestrial subscriber, it checks that the MES is
present in its ocean region before forwarding it. The location of each MES is monitored so that if a
call is received for an MES which has moved on to another ocean region, the call can be redirected or
rejected.

The NCS transmits a common channel which is used to announce calls (addressed to mobile
stations) which are waiting at LESs, for broadcasting Enhanced Group Call (EGC) messages, and at
various stages for protocol signalling and other optional services. When an MES is not involved in
message transfer it automatically tunes to the NCS common channel. Associated with each NCS
common channel is one or more signalling channel on which the NCS receives information from
MESs.

All the NCSs are connected to each other and also to the NOC.

1.3 Land Earth Station

Each LES serves as a gateway between the terrestrial networks and the MESs within the coverage
area of the satellite. It is also used for the transfer of calls from one mobile to another. All LESs
provide telex, maritime distress alerting, and EGC message handling facilities with appropriate
interfaces to the terrestrial network; other interfaces can be provided at the discretion of the LES
operator.

1.4 Mobile Earth Station

Each MES consists of a Data Circuit Terminating Equipment (DCE) which acts as an interface to the
satellite network and a Data Terminal Equipment (DTE) such as a personal computer or intelligent
black box. The DTE may provide an interface at which information gathered by, for example, a
monitoring system or a position location device can be transferred to the DCE or it may allow the user
to enter information manually. Similarly, received information is processed by the DTE and can be
displayed or printed. Alternatively the data can be used by, for example, a control system.

In the From Mobile direction, the DTE assembles a complete message and then transfers it to the
DCE. In the receive direction, the DTE receives messages from the DCE.

2 Inmarsat-C Services
The Inmarsat API has been designed to enable application developers to easily integrate messaging
services provided by Inmarsat-C into their applications. The Inmarsat-C system supports a range of
network services:-

- store and forward communication in both directions

- distress alerting From-Mobile

- enhanced group call To_Mobile

- data reporting From-Mobile

- polling To-Mobile.

Volume 2: User Services, Part 3: CMC Extensions, Page: 132


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Some of the services supported by the Inmarsat-C system are mandatory: other services are optional
as indicated in the following table.

SES SES SES (non- MES


SES (non-
Service LES (SOLAS (SOLAS SOLAS (land-
SOLAS with
with without without
distress) distress)
distress)
distress)
based)
S&F
Messaging Mandatory Mandatory Mandatory Mandatory Mandatory Mandatory

Distress
alerting Mandatory Mandatory N/A Mandatory N/A Not allowed

Land Mobile
alerting Optional N/A N/A N/A N/A Optional

Data
reporting Optional Optional Optional Optional Optional Optional

Polling Optional Optional Optional Optional Optional Optional


EGC Mandatory Mandatory Optional Optional Optional Optional

For store and forward messaging, the mandatory end to end service supported by all elements of the
network is Telex.

2.1 Store and Forward Data and Messaging

The store and forward data and messaging service is a reliable method of sending data or text
messages between an MES and a terrestrial subscriber using the satellite link and a public or private
land network. It can also be used for Inmarsat-C mobile to Inmarsat-C mobile communication within
the Inmarsat-C network and for Inmarsat-A/Inmarsat-C interconnection.

Messages originating from a Mobile Earth Station (MES) are transmitted in packets, via a satellite, to
a fixed Land Earth Station (LES). At the LES the packets are re-assembled before being sent on to
their destination. The LES transmits the information in the form nominated by the sender (telex, data
or electronic mail, for example). A similar procedure is used for communications being sent in the
opposite direction, with callers being able to call one or a group of MESs.

To protect the integrity of the message each packet is checked for errors. Where possible, errors are
corrected but otherwise a partial acknowledgement is returned, requiring retransmission of the
packets in error. Only messages which have been fully received error free are forwarded; the
originator is informed if the system is unable to deliver a message. This error correction is applied to
messaging communications in both directions.

2.2 Distress Alerting

The MES operator may transmit a distress alert. The addressed LES will immediately confirm to the
MES that the message has been received. If automatic or manual position updates are given to the
MES, this distress alert will include its position and an indication that it has been updated within the
last 24 hours.

This function is mandatory for maritime MESs. Land based MESs, however, are not permitted to
send maritime distress alerts although they may, optionally, send land mobile alerts. Land mobile
alerting is an optional commercial service that may be offered by LES.

Volume 2: User Services, Part 3: CMC Extensions, Page: 133


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.3 Enhanced Group Calls (EGC)

The Enhanced Group Call (EGC) service is a message broadcast service within the Inmarsat-C
communications system.

EGC messages are sent to LESs using terrestrial facilities such as telex, X.400 electronic mail, and so
on. The messages are processed at the LES and forwarded to the NCS. EGC messages for the
entire ocean region are queued and scheduled at the NCS for transmission on the NCS common
channel.

Receiver addressing can be performed on the basis of:

- unique individual ID

- group ID (known as an ENID)

- geographical area (circular or rectangular) defined by co-ordinates.

To receive geographically addressed messages, the MES must store information about its current
position. This can be obtained from a navigation system or can be entered into the terminal manually.

Two services are provided:

- FleetNETSM

- SafetyNETSM

FleetNETSM is used to send commercial messages to individuals or groups of subscribers (for


example, individual companies communicating with their own MESs).

SafetyNETSM is used for the transmission of safety information such as weather forecasts or warning;
of hazards such as flooding, earthquakes, civil unrest, and so on, which could affect the safety of MES
operators travelling through a particular area.

2.4 Data Reporting

This service allows the MES to send data reports (position data, for example) and short messages. To
obtain position data the MES must be linked to a navigation system of some description (for example,
a terrestrial or ocean based radio navigation system or a conventional dead reckoning system) or co-
ordinates must be entered manually.

Two access methods are available:

- reserved access

- unreserved access

Reserved access is used for pre-assigned data reporting. The LES transfers the required information
to the MES by poll messages which include instructions on the starting time and duration of the
assignment, the type of report that should be transmitted, and the interval between reports. The MES
can, after initialisation, be programmed to make subsequent reports at specified time intervals without
further intervention. Up to four packets can be transmitted via the signalling channel.

For unreserved access, the transmission of the report is initiated by the MES. Only the slot for the
first packet of the sequence is selected randomly; access for subsequent packets uses a reservation
scheme to guarantee access. Up to three packets, containing at most 32 bytes, can be transmitted
via the signalling channel.

Volume 2: User Services, Part 3: CMC Extensions, Page: 134


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

For data reporting there is an implied Automatic Repeat Request (ARQ) and acknowledgement. If
the LES detects an error in a slot, the slot state marker in the appropriate signalling channel
descriptor packet is left clear in order to indicate that no packet was successfully received. If this
occurs the MES retransmits the packet.

2.5 Polling

Polling is used by the base station to initiate transmission of a data report or message, or to send
small amounts of data to one or more mobiles. The poll command tells the MES if, when and how to
respond and can also include a coded text message or IA5 text of up to 256 characters (maximum
packet length is 300 bytes). All polling packets can include instructions for the addressed MESs to
respond with data reports that acknowledge the poll.

There are three types of polling:

- individual poll

- group poll

- area poll.

Individual polling - means that an explicit poll command is sent to a particular MES. The poll is
originated by a terrestrial subscriber, usually a base station associated with the MES that is being
polled. Using the terrestrial network, the base station sends the LES the poll details and the MESs
the poll is to be sent to. If the MES is busy, the poll is queued until the MES is idle. On receipt of a
polling command the MES responds in accordance with the instructions it has been given.

Group polling - with group polling , a single poll command is broadcast on the NCS common channel.
MESs that are idle when the poll is transmitted and also programmed to respond to the particular
group address will receive the poll and transmit a response if requested. Group poll commands may
be repeated in order to obtain responses from MESs that did not respond the first time.

Area polling - is similar to group polling except that only MESs located in a specified geographical
area are addressed. The geographical area is defined by co-ordinates in the poll message.

2.6 Mobile to Mobile Reporting

This service utilises both the data reporting and polling protocols to provide a fast and flexible means
of delivering small amounts of data between mobile terminals. A server process receives data sent
using the data reporting protocol, repackages it, and sends it out using the polling protocol. The
server can be set-up either to interpret the received data reports according to a particular defined
format thereby allowing all the fields in the poll packet to be set as required, or set-up to simply
enclose all the data report data within the poll

Volume 2: User Services, Part 3: CMC Extensions, Page: 135


Chapter 1: CMC Extensions
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 1: Introduction and Overview

Contents

1 Introduction ............................................................................ 2

2 Functional Requirements ......................................................... 3


2.1 Mandatory Elements .........................................................................................3
Figure 1: General Schematic of Inmarsat-C Land Earth Station .............................3
2.2 Communications Requirements ........................................................................4
2.2.1 TDM Channel .................................................................................................4
2.2.2 Signalling Channel .........................................................................................4
2.2.3 Message Channel ..........................................................................................4
2.2.4 Interstation Signalling Links ...........................................................................4
2.2.4.1 LES – NCS Signalling Channel .............................................................................................. 4

2.2.4.2 NCS – LES Signalling Channel .............................................................................................. 4

2.2.5 L-band monitoring ..........................................................................................4


2.3 Access Control Functions .................................................................................5
2.4 Network Functions ............................................................................................5
2.5 Message Handling Functions ............................................................................5
2.6 Testing Facilities ...............................................................................................5
2.7 Distress Handling ..............................................................................................6
2.8 Enhanced Group Calls ......................................................................................6

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 1
Chapter 1: Introduction and Overview
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
A Land Earth Station (LES) serves as a gateway between the terrestrial network and the Inmarsat-C
communication system.

As well as complying with the mandatory requirements of this part of the System Definition Manual
(that is, Volume 3, Part 1) an LES providing services for the Inmarsat-C system shall also conform
with the technical requirements of:

- Volume 1: System Description

- Volume 2: User Services (if supported by the LES)

- Volume 3, Part 2: Mobile Earth Station

- Volume 3, Part 4: Interstation Signalling Links

- Volume 4: Packet Formats and Usage

- Volume 5: Inmarsat-C SDL

Satisfactory compliance with these requirements must be demonstrated to Inmarsat before access to
the Inmarsat-C system will be granted.

The purpose of these technical requirements is to ensure that all LESs providing Inmarsat-C services
will perform adequately and will preserve the integrity of system operations. Requests for changes to
or waiver of requirements set forth herein will be considered, provided they can be justified as
consistent with the purpose of the document. Such requests should be forwarded to Inmarsat together
with all substantiating details necessary to justify the request.

The LES requirements are considered in the following general terms:

- communications interfaces between an existing Inmarsat-A LES at IF level;

- the aspects of the access control and signalling system that are unique to the LES; and

- the interface with the terrestrial network including the message handling system.

The communications interface with an Inmarsat-A LES is defined in these Technical Requirements as
being an IF interface. It is not mandatory that an Inmarsat-C LES be associated with an Inmarsat-A
LES, however the technical requirements pertaining to

(a) C-band,

(b) L-band, and

(c) AFC,

as described in "Technical Requirements for Inmarsat Standard-A Coast Earth Stations" Issue 5,
March 1989, must be met by any Inmarsat-C LES wishing to operate within the Inmarsat system.
Reference to particular sections of this Document will be contained in the text.

The access control and signalling protocols of the Inmarsat-C system are described in Volume 1 and,
where applicable, in SDL diagrams in Volume 5; packet formats are given in Volume 4. Of particular
note are the arrangements for the Demand Assigned operation of LESs. This method of operation will
be introduced by Inmarsat if operational conditions call for satellite power savings to be made.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 2
Chapter 1: Introduction and Overview
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2 Functional Requirements
The functional requirements for an Inmarsat-C LES are outlined here and are discussed in further
detail in Chapter 2.

2.1 Mandatory Elements


The fundamental requirement for each LES offering Inmarsat-C services is that it be capable of
establishing and clearing the appropriate satellite channels for message transfer and the processing
of message transfer as defined in Volume 1. Figure 1 shows a general schematic of an Inmarsat-C
LES.

The mandatory requirements for all LESs are:

- the ability to operate in the Demand Assigned operation,


- to provide a store and forward telex service,
- to provide EGC message processing, and
- to handle distress alerts and distress priority messages

Figure 1: General Schematic of Inmarsat-C Land Earth Station

IF Interface

C band
Message Packets
Channel Processing
ACCESS CONTROL AND SIGNALLING SUB-SYSTEM

Control

C band Signalling Packets + slot status


Channel Processing Control
MESSAGE HANDLING SUB-SYSTEM

Timing
L band LES TDM Generator
Demodulator
- Reference Tuning

L band Interstation Signalling Data


Link Demodulator

C band Interstation Signalling Data


Link Modulator

C band LES TDM Data


Modulator

Tuning and timing

Inmarsat-C
Test Terminal TERRESTRIAL
LINKS

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 3
Chapter 1: Introduction and Overview
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.2 Communications Requirements


An LES in the Inmarsat-C system communicates with the Inmarsat space segment using the channels
described in the following paragraphs.

2.2.1 TDM Channel


Each LES shall transmit at least one TDM carrier on a frequency assigned by the NCS. The TDM
channel shall be used to transmit the following information:

(a) the LES bulletin board;

(b) signalling and control packets to MESs; and

(c) To-Mobile message packets;

2.2.2 Signalling Channel


Each LES shall continuously receive at least one signalling channel per TDM at a frequency which is
assigned by the NCS. This channel shall be used to receive the following information:

(a) all distress alerts;

(b) data reporting messages; and

(c) signalling packets from MESs;

2.2.3 Message Channel


Each LES shall receive at least one MES message channel per TDM at a frequency which is
assigned by the NCS. This channel shall be used to receive:

(a) the From-Mobile message packets from MESs.

2.2.4 Interstation Signalling Links


2.2.4.1 LES – NCS Signalling Channel

This channel shall be used by the LES to transmit the following information to the NCS:

(a) EGC messages;

(b) signalling and control packets;

(c) requests for LES TDM assignments.

2.2.4.2 NCS – LES Signalling Channel

The LES shall continuously receive the NCS-to-LES interstation signalling link carrier which carries:

(a) signalling and control packets

(b) TDM assignment responses.

2.2.5 L-band monitoring

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 4
Chapter 1: Introduction and Overview
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Each LES shall receive its own TDM carrier(s) to ensure that it is being transmitted within
specification, and to provide a reference for time slot generation.

2.3 Access Control Functions


The main access control functions of an Inmarsat-C LES are:

(a) the establishment and clearing of logical channels under normal and abnormal conditions;

(b) the handling of distress alerts and distress priority messages;

(c) the control of MES's random access to signalling channel slots;

(d) the TDMA access to the message channels by MESs;

(e) the keeping and maintaining of a list of all registered MESs;

(f) requesting and releasing the following Inmarsat-C network resources:

(i) TDM channel(s);

(ii) signalling channel(s); and

(iii) message channel(s);

2.4 Network Functions


The required network functions are:

(a) to conduct commissioning and performance tests when requested by the NCS;

(b) to provide call data recording by transmitting a Network Record to the NCS after the completion
of each call.

2.5 Message Handling Functions


The required message handling functions of a LES are:

(a) the acceptance and the storing of messages for subsequent delivery;

(b) the interworking with the Access Control and Signalling Sub-System for message delivery;

(c) the transmission of non-delivery notification to the message originator; and

(d) the maintenance of a list of the status of each message transfer.

2.6 Testing Facilities


The required testing facilities at the LES include:

(a) order wires;

(b) RF test capabilities;

(c) baseband measurement facilities;

(d) test code access;

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 5
Chapter 1: Introduction and Overview
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(e) performance verification and commissioning; and

(f) a test terminal.

2.7 Distress Handling


The LES shall provide distress alert and distress priority message handling facilities in accordance
with requirements of the Radio Regulations, Article 39, paragraph 3149 and Article N 39, paragraph
N3129:

"an earth station in the maritime mobile-satellite service at a specified fixed point receiving a distress
message shall, without delay, take the necessary action to advise the appropriate authorities
responsible for providing for the operation of rescue facilities."

and Article N39, paragraph N 3129:

"........ appropriate coast earth stations in receipt of distress alerts shall ensure that they are routed as
soon as possible to a Rescue Coordination Centre".

2.8 Enhanced Group Calls


Each LES shall be capable of receiving EGC calls from terrestrial based information providers,
encoding these calls into the EGC message format and transmitting them to the NCS via the
interstation signalling link.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 6
Chapter 1: Introduction and Overview
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Chapter 2: Functional Requirements

Contents

1 Introduction ............................................................................ 6

2 Inmarsat-C Services ................................................................ 6


2.1 Mandatory Services ..........................................................................................6
2.2 Optional Services ..............................................................................................6

3 Communications Interfaces ..................................................... 6


3.1 Overall Requirements .......................................................................................6
3.2 Transmit System Requirements ........................................................................7
3.2.1 LES TDM Channel RF Characteristics ...........................................................7
3.2.2 TDM Channel Modulation Characteristics ......................................................8
3.2.3 LES-to-NCS Channel Transmit Requirements ...............................................8
3.3 Receive System Requirements .........................................................................8
3.3.1 RF Characteristics of Signalling and Message Channels...............................8
Figure 1: Receive Phase Noise ............................................................................. 10
3.3.2 Receiver Tuning ........................................................................................... 10
Figure 2: Pre-Detection Filter Characteristics ....................................................... 11
3.3.3 Predetection Filtering ................................................................................... 11
3.3.4 Signalling Channel Modulation Characteristics ............................................ 11
3.3.5 Message Channel Modulation Characteristics ............................................. 12
3.3.6 Signalling Channel Processing Requirements ............................................. 12
3.3.6.1 Functional Description.......................................................................................................... 12

3.3.6.2 Slot Timing Reference Generation....................................................................................... 13

3.3.6.3 Signalling Packet Propagation Delay Measurement (0ptional) ........................................... 14

3.3.6.4 Checksum Verification ......................................................................................................... 14

3.3.6.5 Slot Processing Capability ................................................................................................... 14

3.3.6.6 General Performance Requirements ................................................................................... 14

3.3.6.6.1 Performance ...................................................................................................................... 14

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 1
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

3.3.6.6.2 Conditions ......................................................................................................................... 15

3.3.7 Message Channel Processing Requirements .............................................. 15


3.3.7.1 Functional Description.......................................................................................................... 15

3.3.7.2 Message Channel Control ................................................................................................... 16

3.3.7.3 Message Start Timing Reference ........................................................................................ 16

3.3.7.4 Initial Acquisition and Demodulation .................................................................................... 16

3.3.7.5 Symbol Storage and Unique Word Detection ...................................................................... 16

3.3.7.6 Frame Processing Delay ...................................................................................................... 17

3.3.7.7 General Performance Requirements ................................................................................... 17

3.3.7.7.1 Performance ...................................................................................................................... 17

3.3.7.7.2 Conditions ......................................................................................................................... 17

3.3.8 NCS-to-LES Carrier Receive Requirements ................................................ 17

4 Access Control Requirements ............................................... 18


4.1 Overall requirements ....................................................................................... 18
4.2 TDM Channel Control ..................................................................................... 18
4.3 Message Channel Control............................................................................... 18
4.3.1 Normal Operation – Frequency Allocation ................................................... 18
4.3.2 MES Frame Length ...................................................................................... 18
4.3.3 Slot Number ................................................................................................. 19
4.4 Signalling Channel Control .............................................................................. 19
4.4.1 General ........................................................................................................ 19
4.4.2 Normal Operation - Frequency Allocation .................................................... 19
4.5 Interstation Signalling Links (ISL) .................................................................... 19
4.5.1 LES – NCS Channel Processing .................................................................. 19
4.5.2 NCS – LES Channel Processing .................................................................. 19
4.6 Call Processing ............................................................................................... 20
4.7 Active Mobile List ............................................................................................ 20
4.7.1 Mobile Service Activation ............................................................................. 20
4.8 Stand Alone Operation .................................................................................... 20
4.8.1 One LES in a Region ................................................................................... 20
4.8.2 Restoration Mode Operation ........................................................................ 21

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 2
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

4.8.2.1 LESs Operating in the Restoration Mode ............................................................................ 22

4.8.2.2 Nominated LES .................................................................................................................... 22

Figure 2: Restoration Mode Network Operation .................................................... 23

5 Terrestrial Message Handling Requirements .......................... 25


5.1 General ........................................................................................................... 25
5.1.1 Call Routing ................................................................................................. 25
5.1.1.1 One Stage Selection ............................................................................................................ 25

5.1.1.2 Two Stage Selection ............................................................................................................ 25

5.1.2 Additional Services....................................................................................... 25


5.2 Functional Requirements ................................................................................ 25
5.2.1 From-Mobile Message Transfer ................................................................... 25
5.2.2 To-Mobile Message Transfer ....................................................................... 26
5.2.3 From-Mobile Distress Calls (Distress Alerts and Distress Priority Messages) ..
..................................................................................................................... 27
5.3 Optional Additional Facilities .......................................................................... 27
5.3.1 Multi-address Messages .............................................................................. 27
5.3.2 Follow-on Messages .................................................................................... 27
5.3.4 Mobile-To-Mobile Message Transfer ........................................................... 27
5.4 Message reference information....................................................................... 27
5.4.1 Date and Time ............................................................................................. 27
5.4.2 Message Reference Number ....................................................................... 27
5.4.3 Terrestrial-Originated Follow-on Message Reference Numbers .................. 28
5.5 Message Header Format ................................................................................ 28
5.6 Status Enquiry ................................................................................................. 28
5.7 Message Status Notification............................................................................ 28
5.7.1 From-Mobile Message Transfer ................................................................... 28
5.7.2 To-Mobile Message Transfer ....................................................................... 28
5.7.3 Non-delivery Codes...................................................................................... 28
5.8 Message Processing ....................................................................................... 30
5.8.1 From-Mobile Message Processing ............................................................... 30

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 3
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

5.8.2 To-Mobile Message Processing ................................................................... 30


5.8.3 Enhanced Group Call Processing ................................................................ 30
5.8.3.1 EGC Closed Networks ......................................................................................................... 30

5.8.4 Optional Data Reporting and Polling Services ............................................. 31


5.8.5 Two Digit Prefix Code Processing ................................................................ 31

6 Testing ................................................................................. 32
6.1 Order Wires..................................................................................................... 32
6.2 RF Test Capabilities ........................................................................................ 32
6.3 Baseband Test Capabilities ............................................................................ 32
6.3.1 Satellite Circuits ........................................................................................... 32
6.3.2 Test Code Access ........................................................................................ 32
6.3.3 Performance Verification Testing (PVT) ....................................................... 32
6.3.3.1 General Requirements ......................................................................................................... 32

6.3.3.2 Facilities to be Provided ....................................................................................................... 33

6.3.3.3 Accuracy Requirements ....................................................................................................... 33

6.3.4 Inmarsat-C Test Terminal ............................................................................ 33


6.3.5 Terrestrial Circuits ........................................................................................ 33

7 Distress ................................................................................ 33
7.1 General Requirements .................................................................................... 33
7.2 Facilities to be Offered .................................................................................... 34
7.3 Logging by NCS .............................................................................................. 34
7.4 Logging by the LES ......................................................................................... 34
7.5 Alarms ............................................................................................................. 34

8 Call Data Reports .................................................................. 34

9 EGC Addressing .................................................................... 34


9.1 Introduction ..................................................................................................... 34
9.2 Terrestrial Routing of Messages ..................................................................... 35
9.3 Addressing of EGC Packets............................................................................ 35
9.3.1 Priority Codes (C1) ....................................................................................... 35

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 4
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

9.3.2 Service Codes (C2) ...................................................................................... 36


9.3.3 Addresses (C3) ............................................................................................. 37
9.3.3.1 Service Code 00 ................................................................................................................... 37

9.3.3.2 Service Code 02 ................................................................................................................... 37

9.3.3.3 Service Code 04 ................................................................................................................... 37

9.3.3.4 Service Code 11 ................................................................................................................... 37

9.3.3.5 Service Code 13 ................................................................................................................... 38

9.3.3.6 Service Code 14 ................................................................................................................... 39

9.3.3.7 Service Code 23 ................................................................................................................... 39

9.3.3.8 Service Code 24 ................................................................................................................... 39

9.3.3.9 Service Code 31 ................................................................................................................... 39

9.3.3.10 Service Code 33 ................................................................................................................... 40

9.3.3.11 Service Code 34 ................................................................................................................... 40

9.3.3.12 Service Code 44 ................................................................................................................... 40

9.3.3.13 Service Code 72 ................................................................................................................... 41

9.3.3.14 Service Code 73 ................................................................................................................... 41

9.3.4 Repetition Codes (C4).................................................................................. 41


9.3.4.1 Category (a) Repetition Codes ........................................................................................... 41

9.3.4.2 Category (b) Repetition Codes ........................................................................................... 42

9.3.4.3 Cancel Facility ...................................................................................................................... 43

9.3.5 Presentation Codes (C5) .............................................................................. 44

10 Addressing of Polling Services ............................................ 44


10.1 General ........................................................................................................ 44
10.2 Terrestrial Routing of Polling Commands..................................................... 44
10.2.1 Poll Type .................................................................................................... 44
10.2.2 Data Network ID ......................................................................................... 45
10.2.3 Response Type .......................................................................................... 45
10.2.4 Sub-Address .............................................................................................. 45
10.3 Polling Command Input Addressing to the LES ............................................ 45
Annex 1: Year 2000 Compliance .......................................................................... 46

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 5
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

1 Introduction
This chapter describes the functional requirements for an Inmarsat-C Land Earth Station. The role of
the LES within the system is described in Volume 1.

2 Inmarsat-C Services

2.1 Mandatory Services


It is mandatory for all LESs to support the following Inmarsat-C services:

- Store and forward message transfer

- EGC message processing

- Maritime distress call handling (i.e. distress alerts and distress priority messages)

- Performance verification testing

2.2 Optional Services


In addition, LESs may also support:

- Polling

- Data reporting

- Land Mobile Alerting

Further services may be added in the future.

These services do not have to be provided but, if they are, they must be implemented in accordance
with this chapter and with other relevant parts of the System Definition Manual.

3 Communications Interfaces

3.1 Overall Requirements


The LES shall transmit and receive those communication carriers that are necessary to provide the
message transfer services described in Chapter 1, Section 2.2. The transmit carriers are the TDM
channels and the LES-to-NCS interstation signalling link. The receive carriers are the signalling and
message channels, the NCS-to-LES interstation signalling link and the LESs own TDM carrier which
is monitored.

The LES shall be equipped with a sufficient number of modulators and demodulators, terrestrial
interface circuits and message handling storage capacity to meet the expected traffic.

It is recommended that the provision of LES equipment and memory storage capacity should be such
that there will be no more than 1% of message transfer requests rejected in the busy hour, assuming
adequate satellite capacity is available.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 6
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

3.2 Transmit System Requirements

3.2.1 LES TDM Channel RF Characteristics


Each LES shall be capable of transmitting at least one TDM carrier at a frequency assigned by the
NCS. The following requirements shall apply:

(a) the RF signal characteristics shall be in accordance with Section 2.4 of the "Technical
Requirements for Inmarsat Standard-A Coast Earth Stations" (Issue 5, March 1989) for the
following:

(i) transmitter linearity;

(ii) transmitter noise and spurious signals;

(iii) phase noise; andi

(iv) signal level stability.

(b) The frequency accuracy shall be consistent with the resultant L-band frequency accuracy
requirements of Section 4.2.3 of the "Technical Requirements for Inmarsat Standard-A Coast
Earth Stations" (Issue 5, March 1989).

(c) The TDM carrier's EIRP shall be specified by Inmarsat according to the station location and the
operational satellites mode; that is, satellite generation and transponder gain setting. The EIRP
of each TDM carrier shall be continuously adjustable from at least 55 dBW to 67 dBW with a
resolution better than +0.3 dB.

(d) The LES TDM transmit modulator units shall be capable of tuning to any channel in 5 kHz
increments starting at 6417.5 MHz for the first generation satellites and at 6425 MHz for second
generation satellites. The To-Mobile channel number frequency code shall be as follows:

Channel Number Frequency (MHz)

Decimal Hexadecimal 1st Generation 2nd Generation

8000 1F40 - 6425.000 (Note 1)


8002 1F42 - 6425.005
- - - -
- - - -
10000 2710 6417.500 (Note 2) 6430.000
- - - -
11000 2AF8 6420.000 (Note 3) 6432.500
- - - -
- - - -
13000 32C8 6425.000 (Note 4) 6437.500
- - - -
14000 36B0 - 6440.000 (Note 5)

Notes:

1 Bottom frequency for second generation satellites;


2 Bottom frequency for first generation (MCS) satellites;
3 Bottom frequency for first generation (MARECS) satellites;
4 Top frequency for first generation (MCS and MARECS) satellites;
5 Top frequency for second generation satellites.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 7
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

3.2.2 TDM Channel Modulation Characteristics


The modulation characteristics of each LES TDM carrier shall be:

(a) modulation: unfiltered binary phase shift keying;

(b) symbol rate: 1200 symbols per second;

6
(c) symbol rate stability: long term stability ±0.8 part in 10 ;

(d) frame length: 10368 symbols (8.64s);

(e) frame unique word: two unique words are transmitted uncoded as specified
in Volume 1, Chapter 4, Section 3;

(f) ambiguity resolution: unique word polarity.

(g) scrambling: consistent with requirement of Volume 1, Chapter 4, Section 3;

(h) error control coding: convolutional, as specified in Volume 1, Chapter 4, Section 3;

(j) interleaving: interleaver implementation as specified in Volume 1, Chapter 4,


Section 3;

(k) frame synchronisation*: maintained to within ±1/2 frame (±4.32s) of NCS frame timing
or UTC;

3.2.3 LES-to-NCS Channel Transmit Requirements


The transmit requirements of LES-NCS interstation signalling link carrier shall be as specified in
Part 4, Chapter 1, Sections 2 and 4 in this volume.

3.3 Receive System Requirements

3.3.1 RF Characteristics of Signalling and Message Channels


Each LES shall receive at least one signalling channel and one message channel. The frequencies of
these channels will be assigned by the NCS.

The LES RF receive system (antenna, low noise amplifier, C-band downconverter and pilot receiver)
shall accord with the "Technical Requirements for Inmarsat Standard-A Coast Earth Stations" (Issue
5, March 1989) , Sections 2.12, 2.2, 2.3.2 through 2.3.6 and Section 4.3.

The signalling and message channels received at the LES will have the following characteristics:

(a) Nominal satellite EIRP from -26 dBW for first generation;
MES at 5° elevation (see note 1): -19 dBW for second generation;

(b) Nominal satellite noise EIRP in the range -66 dBW/Hz to -61 dBW/Hz,
density at beam edge: for the first generation;
in the range -58 dBW/Hz to -52 dBW/Hz,
for the second generation;

(c) Maximum nominal EIRP difference 6 dB;

* Only applicable to LESs intending to offer pre-assigned data reporting.


Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 8
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

between two carriers received


on the same channel (see note 2):

(d) Maximum frequency offset (prior ±30 kHz for first generation
to LES AFC correction): ±4 kHz for second generation;

(e) Maximum frequency uncertainty ±2000 Hz and within ±1450 Hz


of MES carrier from nominal: for >99.9% of the time; (see Note 3)

(f) Maximum rate of change of MES 65 Hz/sec


carrier frequency:

(g) Maximum frequency difference 2100 Hz including all worst case


between two carriers received Doppler shifts;
on the same channel:

(h) Minimum time between two carriers 1 ms; (see Note 4)


received on the same channel:

(j) Phase noise: less than the worst case


spectrum shown in Figure 1.

Note 1: The nominal signal and noise EIRP may be higher by 4 dB for an LES located near the
sub-satellite point. Also, variations in the satellite gain may result in signal and noise
EIRP values 6 dB lower than the nominal values.

Note 2: Signalling packets and messages received from different MESs at the LES on the same
channels, may differ considerably in both power and frequency due to the difference in
the locations of the transmitting MESs. In addition, due to the effect of multipath fading
with a C/M of 7 dB in the worst case, the received signal level for an MES may rise by
more than 4 dB and fall by more than 10 dB for up to 1% of the time.

Note 3: The LES demodulator shall have an acquisition bandwidth of not less than ± 1450 Hz.
The maximum frequency uncertainty of Aeronautical Mobile Earth Stations from nominal
is ± 2200 Hz and within ± 1630 Hz for >99.9% of the time (Volume 1, Chapter 3, Tables
4.1 and 4.2 refer).

Note 4: 1 ms is for normal operation; however, for MES signalling channel packets, collision in
the same slot may take place. The probability of N packets colliding is (0.2)N under
Inmarsat- C design criteria.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 9
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Figure 1: Receive Phase Noise


SSB in 1 Hz Bandwidth

-25

-30

-35

-40
Power in 1 Hz ( dBc )

-45

-50

-55

-60

-65

-70

10 100 1000 10000

Offset from Nominal (Hz)

3.3.2 Receiver Tuning


The signalling and message channel demodulators in each LES shall each be capable of tuning to
any channel in 5 kHz increments, starting at 4192.5 MHz for the first generation satellites and
3605 MHz for the second generation satellites. The From-Mobile channel number frequency code
used in the channel assignment shall be as follows:

Channel Number Frequency (MHz)

Decimal Hexadecimal 1st Generation 2nd Generation


6000 1700 - 3600.000 (Note 1)
6002 1772 - 3600.005
- - - -
- - - -
8000 1F40 - 3605.000
- - - -
- - - -
10000 2710 4192.500 (Note 2) 3610.000
- - - -
10790 2A26 4194.475 (Note 3) 3611.975
- - - -
- - - -
13000 32C8 4200.000 3617.500
- - - -
- - - -
13200 3390 4200.500 (Note 4) 3618.000
- - - -
14000 36B0 - 3620.000 (Note 5)

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 10
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Notes:

1 Bottom frequency for second generation satellites.

2 Bottom frequency for first generation (MCS) satellites.

3 Bottom frequency for first generation (MARECS) satellites.

4 Top frequency for first generation (MCS and MARECS) satellites.

5 Top frequency for second generation satellites.

Figure 2: Pre-Detection Filter Characteristics

40 dB
40
RELATIVE ATTENUATION (dB)

3 kHz

35 kHz
30
16 kHz

20
18 dB
-8 kHz 8 kHz

10

3 dB
0
-40 -30 -20 -10 0 10 20 30 40
OFFSET FREQUENCY (kHz)

3.3.3 Predetection Filtering


LES demodulators shall include a predetection filter in accordance with the mask shown in Figure 2.

3.3.4 Signalling Channel Modulation Characteristics


The signalling channels operate in a TDMA fixed frame duration mode. The frame is subdivided into
14 time slots for the first generation Inmarsat satellites and 28 time slots for the second generation
Inmarsat satellites. The access protocol employed is a hybrid of slotted ALOHA and explicit
reservations as detailed in Volume 1, Chapter 4, Section 4.3.

The modulation characteristics of the received signal shall be:

(a) modulation: unfiltered binary phase shift keying;

(b) symbol rate: 1200 symbols per second (for second generation satellites);
600 symbols per second (for first generation satellites);

(c) symbol rate stability: long term stability ±1 part in 105;


10 seconds stability ±1 part in 106

(d) frame duration: 8.64s. See Volume 1, Chapter 4, Figure 4-12

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 11
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

(e) unique word: one 64 bit unique word is transmitted uncoded at the
beginning of each signalling packet as specified in Volume 1,
Chapter 4, Section 3;

(f) ambiguity resolution: unique word polarity;

(g) scrambling: consistent with requirement of Volume 1, Chapter 4, Section 3;

(h) error control coding: convolutional coding as specified in Volume 1, Chapter 4,


Section 3;

3.3.5 Message Channel Modulation Characteristics


The message channels operate in a quasi-continuous mode with variable frame duration depending
on the length of the message to be transferred, as detailed in Volume 1, Chapter 4, Sections 3.1.3
and 3.2.3.

The modulation characteristics of the received signal shall be as follows:

(a) modulation: unfiltered binary phase shift keying;

(b) symbol rate: 1200 symbols per second (for second generation satellites);
600 symbols per second (for first generation satellites);

(c) symbol rate stability: long term stability +1 part in 105;


10 seconds stability +1 part in 106;

(d) preamble: transmitted uncoded, unscrambled and not interleaved at the


beginning of message frames. Carrier recovery frame field, 128
symbols, all "1"s and symbol timing recovery field, 64 symbols
alternating "1" and "0";

(e) frame duration: variable depending on the length of the message;

(f) unique word: two 64 bit unique words are transmitted each frame
uncoded and distributed through the frame to reduce the effects of
multipath fading and to provide for ambiguity resolution;

(g) ambiguity resolution: unique word polarity (see Volume 1, Chapter 4, Section 3);

(h) scrambling: as specified in Volume 1, Chapter 4, Section 3;

(j) error control coding: as specified in Volume 1, Chapter 4, Section 3;

(k) interleaving: as specified Volume 1, Chapter 4, Section 3.

3.3.6 Signalling Channel Processing Requirements


3.3.6.1 Functional Description

The timing and formatting of the signalling channel is fully defined in Volume 1, Chapter 4, Section 3.
The main processing requirements are:

(a) to recover (that is, to demodulate, decode and unscramble) packets from each time slot in
the received channels; and

(b) to indicate exceptional conditions — for example, an incorrectly decoded packet.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 12
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

In addition it is recommended that the ability to indicate the delay within the time slot of a correctly
recovered packet be provided.

Processing will consist of the following stages:

(i) channel tuning (refer to Section 3.3.2);

(ii) slot timing reference generation which needs timing information from the LESs own
received TDM;

(iii) packet frequency/phase acquisition and demodulation;

(iv) convolutional decoding;

(v) de-scrambling;

(vi) checksum verification;

(vii) error/collision detection; and

In addition it is recommended that signalling packet propagation delay measurement be provided.

In order to reduce overhead, the MES signalling packets do not have dedicated preambles. As a
result, LES processing will be required to perform sample storage in order to acquire frequency,
phase and symbol timing on the data portion and unique word of the packet.

The signalling channel demodulator shall always attempt to demodulate and decode a burst, even
when it is possible to detect that a collision has occurred. If more than one burst is received in a slot
and at least one of them is readable and has a valid checksum, then any recovered packet shall be
processed. If a collision is detected and no valid packet is retrieved, then the slot shall be marked "No
burst received/Burst in Error".

It should be noted that the above mentioned processing may take place off-line, and not necessarily in
the order given above.

3.3.6.2 Slot Timing Reference Generation

The LES shall receive its own TDM at L-band as a basis for slot timing reference. Time reference "To"
at the LES is defined as the timing of the leading edge of the first symbol of the first unique word of its
own TDM, as received at L-band. By using this reference, the variation of the LES to satellite
propagation delay, due to operational plans and satellite station-keeping, is removed.

The shortest propagation round trip delay between a satellite and an LES and MES at the sub-satellite
point is taken to be 238.8 ms (equivalent to 2x 35800 km). An MES transmission delay is specified to
allow the MES to de-interleave and decode the bulletin board and the signalling channel descriptors
prior to any signalling or message channel transmission. The LESs own TDM receiver shall have the
same delay characteristics as specified for the receiver in Part 2 of this volume.

The start time "Ts(k)" of each time slot at the LES is therefore given by:

Ts(k) = To + T1 + Tk(M, G)

where Tk(M, G) = 300 + 208M + 370G(k-1) TDM symbol periods

and M is the total number of signalling channels associated with that TDM, G = 2 or 1 for first
generation or future generation satellites respectively, k is the slot number and T1 = 236.67 ms which
is equal to 284 TDM symbol periods at 1200 symbols per second.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 13
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

For signalling channel demodulators the UW search shall be performed starting at time Ts and cover
a period of not less than 40 ms (48 TDM Symbol periods, 50 is recommended for coverage below 5o
elevation).

Slot timing reference generation is the same for the processing of all signalling channels since all
TDM carriers from the same LES shall be frame synchronised.

After establishing the time reference "To" at the LES, it shall be maintained in the event of unique
word misses up to a maximum of 10 consecutive misses. In case this limit is exceeded, an indication
of loss of timing integrity shall be sent to the access control sub-system to allow appropriate action.

From the start of transmission of a TDM carrier, some time will elapse before time reference To can
be established at the LES. The frame transmitted should show all slots being reserved, but acquisition
of "To" time reference should be attained in time to allow the second frame to show the slot status.
The probability of not acquiring the time reference To on the first frame shall be less than 10-6. If the
time reference is not established, the subsequent frame will continue to show fully reserved status of
all slots.

3.3.6.3 Signalling Packet Propagation Delay Measurement (0ptional)

For successfully decoded packets, the signalling channel processing shall indicate the start time of
the received packet in relation to the slot start time "Tk". This shall be to an accuracy of better than ±1
symbol and preferably ±0.25 symbols.

3.3.6.4 Checksum Verification

Volume 4 contains the set of signalling packets over which the check-sum needs to be performed.
Since there are variations in packet length, this process shall use the first byte of the packet (that is,
the "Type Field"), to determine the packet's length.

3.3.6.5 Slot Processing Capability

The LES shall provide the capability of processing a sufficient number of slots to meet its traffic
demand.

Slots which cannot be provided should be marked as "reserved" in the appropriate signalling channel
descriptor packet. Prior to allocation of an additional signalling channel by Inmarsat, at least 13
(300 bit/s) and 27 (600 bit/s) slots should be utilised.

3.3.6.6 General Performance Requirements

3.3.6.6.1 Performance

Single packet in a slot performance:

Packet error probability:

(i) less than 0.1 (300 bit/s for first generation Inmarsat satellites);

(ii) less than 0.05 (600 bit/s for second generation Inmarsat satellites).

Probability of failure to detect burst presence shall be less than 0.0001.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 14
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

3.3.6.6.2 Conditions

The processing of the signalling channel shall meet the performance requirements under the following
conditions:

(a) the channels are within the frequency passband described in Section 3.3.2;

(b) have a nominal C/No of 32.5 dBHz for first generation and 35.5 dBHz for future generation
satellite operation;

(c) the maximum frequency offsets, rate of change of frequency and clock frequency offset are as
described in Section 3.3.1;

(d) the channels have phase noise as shown in Figure 1 plus LES down converter phase noise;
and

(e) are in the presence of Rician multipath fading of C/M = 7 dB, f(3dB) = 0.7 Hz. (See Part 2,
Figure 2-8 for Rician fading model).

Note 1: For LESs intending to offer Inmarsat-C service to Aeronautical Mobile Earth Stations the
following Rician multipath fading channel parameters shall be used to determine
compliance with the packet error rate requirements:

C/M = 9 dB

f(3dB) = 20 - 100 Hz

Note 2: For LES intending to offer optional low power land mobile service in the global beam, the
demodulator shall be capable of supporting input signals with C/No of 32.9 dBHz for
95% of the low power land mobile terminal population operating under a Rician Channel of
C/M=10 dBW. The expected packet error rate at this level shall not be more than 5%.

Note 3: For LES intending to offer optional low power SES service in the global beam, the
demodulator shall be capable of supporting input signals with C/No of 34.1 dBHz for 95%
of the low power maritime mobile terminal population operating under a Rician Channel of
C/M=7 dBW, f(3 dB)=0.7 Hz. The expected packet error rate at this level shall not be more
than 5%.

3.3.7 Message Channel Processing Requirements


3.3.7.1 Functional Description

The timing and formatting of the frames and packets on this channel from the MESs is fully defined in
Volume 1, Chapter 4, Section 3. The processing objectives for the MES message channel are to
recover packets of data correctly from each quasi-continuous message channel transmitted by MESs.

Processing will consist of the following stages:

(a) channel tuning (see Section 3.3.2);

(b) message start timing reference;

(c) initial frequency/phase/bit timing acquisition and demodulation;

(d) symbol storage and unique word recognition;

(e) de-permuting and de-interleaving;

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 15
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

(f) convolutional decoding and de-scrambling;

(g) check sum verification; and

(h) repetition of (d) to (g) until end of message.

3.3.7.2 Message Channel Control

A control interface with the access control sub-system to message channel processing will be
required to provide the following message information:

(a) bit rate selection (300 or 600 bit/s);

(b) channel frequency;

(c) interleaver block size parameter N

where:

N = 0 to 4 and block size is given by (34 + N *32)* 64 symbols;

(d) indication of time slot at which message reception is expected; and

(e) indication of message duration (that is, number of message blocks).

3.3.7.3 Message Start Timing Reference

Time slots, as defined by "Tk" (see Section 3.3.6.2) will be required for message channel processing.
The access control sub-system, which sets up the message parameters and timing, will indicate the
unique "Tk" after which the message reception is due to start. The carrier should appear within 40
milliseconds after the start time "Tk". The 40 milliseconds is the time delay difference between a
carrier transmitted by an MES at the sub-satellite point and that transmitted by an MES at the edge of
coverage.

The Message Channel demodulator should be capable of accommodating an uncertainty of not less
than 40 ms. (48 TDM symbol periods, 50 is recommended for coverage below 5o elevation)

3.3.7.4 Initial Acquisition and Demodulation

A preamble for carrier and clock recovery is provided to allow acquisition prior to the unique words
and message symbols.

If a deep fade occurs during the preamble, acquisition may not occur until the message symbols have
commenced. However, in such a situation, all the information may be fully retrievable and the
acquisition demodulation process should not be abandoned until the scheduled end of message.

3.3.7.5 Symbol Storage and Unique Word Detection

It will be necessary to store symbols for at least one message channel frame in order to synchronise
to the distributed unique word. There is a maximum timing uncertainty due to the mobile's geographic
position allowing the duration of the unique word search to be limited in time.

In the event of any frame not being detected, the search for successive frames should continue up to,
and including the last scheduled frame.

It is recommended that a cycle-slip correction algorithm be employed at frame level using the known
unique word bit polarity. As each unique word symbol is repeated, soft decision addition of successive
symbols may be used to enhance reliability of the unique word for cycle-slip correction purposes.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 16
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

3.3.7.6 Frame Processing Delay

The requirements for de-permuting, de-interleaving, de-coding, de-scrambling and check-sum


calculation are defined in Volume 1, Chapter 4, Section 3. Because of interleaving, full frame of
received symbols will be stored before further processing can be carried out.

3.3.7.7 General Performance Requirements

3.3.7.7.1 Performance

Packet error rates shall be no worse than those defined in Volume 1, Chapter 3, Tables 6 and 7. In
these tables the C/No is the nominal unfaded value.

3.3.7.7.2 Conditions

The processing of the message channel shall meet the performance requirements under the following
conditions:

(a) the channels are within the passband described in Section 3.3.2;

(b) the maximum frequency offsets, rate of change of frequency and clock frequency offset as
described in Section 3.3.1;

(c) the channels have phase noise as shown in Figure 1 plus LES down converter phase noise;
and

(d) re in the presence of Rician multipath fading of C/M = 7 dB, and a filter of f(3dB) = 0.7 Hz (see
Figure 2-8 in Part 2 for Rician fading model).

Note 1: For LESs intending to offer Inmarsat-C service to Aeronautical Mobile Earth Stations the
following Rician multipath fading channel parameters shall be used to determine
compliance with the packet error rate requirements:

C/M = 9 dB

f(3dB) = 20 - 100 Hz

Note 2: For LES intending to offer optional low power land mobile service in the global beam, the
demodulator shall be capable of supporting input signals with C/No of 32.9 dBHz for
95% of the low power land mobile terminal population operating under a Rician Channel of
C/M=10 dBW. The expected packet error rate at this level shall not be more than 5%.

Note 3: For LES intending to offer optional low power SES service in the global beam, the
demodulator shall be capable of supporting input signals with C/No of 34.1 dBHz for 95%
of the low power maritime mobile terminal population operating under a Rician Channel of
C/M=7 dBW, f(3 dB)=0.7 Hz. The expected packet error rate at this level shall not be more
than 5%.

3.3.8 NCS-to-LES Carrier Receive Requirements


The receive requirements of interstation signalling link shall be as specified in Part 4, Chapter 1,
Sections 2 and 3.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 17
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

4 Access Control Requirements

4.1 Overall requirements


The LES shall control:

(a) the transmission of signalling and message packets on the TDM channel(s);

(b) the access of MESs to the signalling channel(s); and

(c) the access of MESs to message channels.

Each LES shall have the capability to operate in the demand assigned mode according to the
protocols described in Volume 1.

4.2 TDM Channel Control


The LES shall control the multiplexing of the TDM signalling and TDM message packets to minimise
the time an MES will be tuned away from the NCS common channel. Distress priority TDM signalling
packets and TDM message packets of distress priority shall have precedence over all others. The
distress priority levels are:

(a) Acknowledgement of distress alerts;

(b) Assignment of From-Mobile logical channels for distress priority messages;

(c) Assignment of To-Mobile logical channels for distress priority messages; and

(d) To-Mobile distress message packets.

The LES shall encode packets using the shortest packet type which will contain the information.

4.3 Message Channel Control

4.3.1 Normal Operation – Frequency Allocation


Each LES shall control access to message channels in accordance with the priority indicated in the
MES assignment request.

An LES will be allocated one or more frequencies by the NCS.

4.3.2 MES Frame Length


The LES shall assign the frame length (i.e. MES interleaver size) for each mobile-originated message
so that the following two conditions are optimised:

(a) the channel utilisation is maximised; and

(b) the probability of message packets received in error are minimised. (Shorter frames reduce the
effectiveness of the interleaving process).

The control of frame length may be implemented using either of the following methods:

Method (a) Fixed Frame

The length of all From-Mobile message frames N may be preset to a value of 0, allowing one packet
of 127 bytes to be transmitted per frame.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 18
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Method (b) Adaptive Control of Frame Length

Control of frame length may be based on an adaptive algorithm that takes into consideration
conditions (a) and (b).

Note: For LESs intending to offer Inmarsat-C service to Aeronautical Mobile Earth Stations, it is
recommended that all calls from AMESs should use the shortest frame length (N=0).

4.3.3 Slot Number


The LES shall control the allocation of an MES message channel between MESs so as to minimise
the time between transmissions, and simultaneously ensuring the avoidance of collisions.

4.4 Signalling Channel Control

4.4.1 General
The LES shall control the access of MESs to the signalling channels. The LES will transmit
information related to each signalling channel associated with a TDM in a signalling channel
descriptor packet.

A signalling channel descriptor packet contains the following information:

(a) satellite frequency code;

(b) slot state markers.

The randomising interval contained in each frame's bulletin board shall be adjustable to traffic
conditions.

Slot state marker setting for reserved and unreserved access, and randomising interval control shall
be in accordance with Volume 1, Chapter 4, Section 4.

4.4.2 Normal Operation - Frequency Allocation


An LES will be allocated one or more frequencies by the NCS.

4.5 Interstation Signalling Links (ISL)

4.5.1 LES – NCS Channel Processing


The LES – NCS interstation signalling link is used to transfer signalling and control packets to the
NCS.

In addition, formatted EGC messages are transmitted to the NCS for relaying over the NCS common
channel. The transmission of packets on the LES – NCS channel shall be on the following priority
basis in descending order:

(i) Maritime distress co-ordination communications via SafetyNETSM ;

(ii) distress alert packets;

(iii) signalling and control packets; and

(iv) network records.

4.5.2 NCS – LES Channel Processing

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 19
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

The NCS – LES interstation signalling link is used to transfer signalling and control packets to the
LES.

The transmission of packets shall be in the following priority basis in descending order:

(i) relayed distress alerts; and

(ii) signalling and control packets.

4.6 Call Processing


Calls to and from MESs shall be processed in accordance with the protocols described in Volume 1
and the associated SDL diagrams in Volume 5. Specific timeouts for events are defined in Volume 5.

4.7 Active Mobile List


Each LES may maintain a list of all MESs that are currently registered in the system. The NCS
manages the status of active MESs so that terrestrial-originated service requests through different
LESs may be controlled. The NCS updates the LESs active mobile list automatically by means of
Registration packets transferred on the ISL.

If an LESs active mobile list becomes corrupted, or a new LES joins the network, the latest active
mobile list may be automatically obtained from the NCS by means of the "Update Request" packet, as
described in Volume 1.

4.7.1 Mobile Service Activation


The registration packet sent from the NCS contains a flag indicating whether the MES has contracted
service provision with an Inmarsat Service Provider, or whether the MES is to be billed via an
authorised Accounting Authority.

If a new registration packet is received with the I flag set to 1, indicating that an ISP contract is in force
for that MES, then the LES will bar the MES from transferring from-mobile messages only (other than
distress priority for maritime mobiles).

Subsequent receptions of a registration packet for a mobile shall not cause from-mobile message
transfers to be barred unless this flag changes (0 to 1) indicating that an ISP contract is now in force.

If the LES is providing ISP facilities, then it shall have facilities for unbarring, or activating, MESs for
from-mobile message transfers. If the LES has an arrangement with the Inmarsat Service Provider for
an MES, then the LES is permitted to activate the MES for from-mobile message transfers.

4.8 Stand Alone Operation


Stand alone operation refers to the situation where there is no NCS in the region to provide the
network co-ordination role. Two cases are considered below:

1) there is only one LES operating in a region; and

2) a restoration mode is invoked.

The term 'Stand Alone' is used because an LES will be operating independently without an NCS.

When "re-route" is used within this section, it does encompass all kinds of re-routing, and the re-
routing does not have to be done automatically within the LES.

4.8.1 One LES in a Region

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 20
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

The following requirements are applicable to an LES which is to work alone in a region without the
NCS, and are additional to the mandatory LES requirements given in other sections of this Chapter.

a) The LES shall transmit a TDM channel on the allocated NCS Common Channel frequency for
the region it is operating in. The Bulletin Board will be set to indicate that this TDM is an NCS
Common Channel with origin ID = NCS ID. Therefore the LES ID will change to the NCS ID. In
addition to carrying the required NCS signalling, the LES may also use this channel to carry
LES signalling and message traffic; that is, use the TDM as a joint NCS Common Channel/LES
TDM.

b) Optionally, the LES may transmit one (or more) LES TDM, with origin ID = LES ID. This will
increase traffic carrying capability, and simplify the operation of the data reporting service
(please see item d entry xiii).

c) The LES is not required to comply with Part 4, Interstation Signalling Links, nor to support any
of the packets given in Volume 4, Chapter 6.

d) The LES shall perform the following Inmarsat-C network functions:

i) acceptance of distress calls from any maritime MES in the region;

ii) transmission of EGC messages;

iii) transmission of Confirmations for own traffic;

iv) transmission of own Polling Commands -optional;

v) transmission of Announcements for own traffic;

vi) handling of Logins including the transmission of Login Acknowledgements;

vii) handling of Logouts including the transmission of Logout Acknowledgements;

viii) updating of full mobile list with information provided by Inmarsat;

ix) acceptance and handling of Commissioning/PVT requests (optional).

x) ability to transmit Network Update packet with information about own LES on the NCS
Common channel at regular intervals. The interval must be configurable by the LES
operator.

xi) the ability to set the Network Version in the Network Update packet.

xii) transmission of either long log-in ack packet, or network update packet if a mobile logs in
with a network version different from the current one.

xiii) acceptance of Data Reports (optional); [Please note that if there is no additional TDM,
the LES ID change will require DNIDs to be downloaded again, and the programs in
the mobiles to be re-started].

4.8.2 Restoration Mode Operation


If the NCS in a region fails, Inmarsat will introduce a network restoration plan. Under this plan, an LES
may operate independently in a similar manner to the single LES in a region described in
Section 4.8.1.

As part of the plan, one LES is nominated by Inmarsat to transmit a TDM channel on the NCS
Common Channel frequency for the region. This LES is referred to as the Nominated LES, and it will
perform some of the NCS functions. The TDM transmitted on the Common Channel frequency will be

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 21
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

marked as a NCS Common Channel and it will have origin ID = NCS ID. A Network Update packet
will be transmitted on this TDM at regular intervals.

Distress priority EGC traffic from LESs operating in the restoration mode may be routed by alternative
means to the Nominated LES. The NCC will advise all RCCs that the network is being restored and
appropriate terrestrial routing arrangements for their Distress traffic.

4.8.2.1 LESs Operating in the Restoration Mode

The additional requirements to the mandatory LES requirements given in other sections of this
chapter for LESs wishing to operate in the restoration mode are:

a) the addition of the following Inmarsat-C network functions:

i) The ability to accept From-Mobile traffic without an ISL connection to an NCS.

ii) The ability to re-route EGC SafetyNET traffic and To-Mobile distress traffic to the
Nominated LES.

b) an LES operating in Restoration mode are recommended to perform the following Inmarsat-C
network functions:

i) inhibit reception of To-Mobile, polls and EGC traffic

ii) re-route To-mobile and EGC FleetNET traffic to the nominated LES for that ocean
region.

iii) bar requests for Mobile-to-Mobile (Inm-C to Inm-C) traffic in the region. It is
recommended that this is done even if it will have impact on Inm-C to Inm-A traffic.

iv) continue to accept Data Reports from mobiles that were programmed before the network
was put into Restoration mode.

4.8.2.2 Nominated LES

In addition to the requirements for "LESs Operating as One LES in a Region" described above, the
Nominated LES shall perform the following:

i) transmission of Network Update packets with information about all LESs in the region, at
regular intervals. The interval must be configurable by the LES operator.

ii) the ability to configure and change from the LES operators console the LES descriptors for
all LESs in the region.

iii) reject test request received from mobiles.

iv) only accept data reports with LES ID = Nominated LES (data reporting is optional).

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 22
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Figure 2: Restoration Mode Network Operation

NCS LES 1 LES 2 MES


(Nominated LES)

Type= Type= Type=


NCS LES LES

EGC (Sa Calls, to


fetyNET -mobile, Calls, to
) -m
from-mo
bile. from-mo obile,
EGC Fle bile.
etNET

NCS
Failure.
Type = NCS Type = LES Type = LES
(radiated by LES1). (radiated by LES1), All ISLs to
TDM optional at LES. NCS are cut.
[Network
Up date]
To-mobil
e When idle, MES
Calls (LE
S1)
obile
remains tuned to NCS
EGC (Sa From-m 2) CC now being
fetyNET (LES
) Calls transmitted by
EGC Fle
etNET (L
nominated LES
ES1) obile
From-m
ES1)
Calls (L
obile
From-m
s (L ES1)
Call

NCS restored

Type= Type= Type= When idle, MES


NCS LES LES remains tuned to NCS
CC now being
[Network
transmitted by NCS
Update] (normal network
operation restored)

Figure 2-3. Restoration Mode Network Operation

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 23
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

STAND ALONE OPERATION

RESTORATION MODE
FUNCTION: LES IN
RESTORATION
ONE LES IN REGION NOMINATED LES MODE.
NCS Common TDM with
Yes. Yes. No.
local id = NCS ID.
Additional TDM (Channel
type = LES), with local id = Optional. Optional. Optional.
LES ID.
Message packets on NCS Yes, if no additional Yes, if no additional
No.
Common Channel TDM. TDM.
To-mobile messaging
(normal / distress priority).
Yes. Yes. No.1)

From-mobile messaging.
Yes. Yes. Yes.
(normal / distress priority).
Mobile-to-mobile messaging
Yes. Yes. No.
(inter region)
Distress Alert reception Yes. Yes. Yes.
EGC transmission
(SafetyNET and FleetNET).
Yes. Yes. No.1)

Data Reporting2) Yes.3) Yes.3) Yes.4)


Polling2) Yes. Yes.5) No.
Pre-assigned Data
Yes. Yes. Yes.4)
Reporting.2)
Land Mobile Alerting2) Yes. Yes. Yes.

1) The LES operator are expected to offer these services. An LES have to enter an agreement
with the operator of the Nominated LES in order to offer the services.

2) The services are optional services for an LES. Table covers situation where the services are
offered by the LES.

3) If no additional TDM, the Data Reports have to be re-started.

4) The LES may continue to receive the Data Report for programs started before the network is
put into Restoration mode.

5) The Polling service will only be available for the Nominated LES.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 24
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

5 Terrestrial Message Handling Requirements

5.1 General
The Inmarsat-C system requires the intervention of a message handling sub-system at the LES for
the transmission of all store and forward message transfer services. Store and Forward Message
delivery to and from terrestrial subscribers must be provided for the public telex network. Procedures
for the interworking with the telex service are described in draft CCITT Recommendation F.127, and
Recommendations U.80, U.81, U.82 and F.72.

It should be noted that the terrestrial telex network in general uses the ITA2 5 unit bit code while the
mandatory Inmarsat-C telex service uses the IA5 7 bit plus parity code. In this case the LES will have
to perform a character code conversion.

In addition, support must be provided for From-Mobile maritime safety services using two-digit prefix
codes (LES operators are referred to Inmarsat SOP, *-OP-014); Section 5.8.5 refers.

5.1.1 Call Routing


5.1.1.1 One Stage Selection

The registration of MESs in the Inmarsat-C system permits the use of one stage selection of MESs for
calls in the To-Mobile direction.

5.1.1.2 Two Stage Selection

As an alternative to single stage selection, the LES may accept calls from the terrestrial network using
a two stage selection procedure. This requires the LES to respond to terrestrial network originated
calls by requesting the address and other information. Two stage selection is also required for the
implementation of services such as multi-addressee calls, follow-on calls and delivery scheduled
calls.

5.1.2 Additional Services


In addition to the interface with the telex network, services may be provided via other terrestrial
networks such as:

(i) public switched telephone network (PSTN) for voice band data;

(ii) circuit switched data network (CSDN); and

(iii) packet switched data network (PSDN).

5.2 Functional Requirements


The message handling sub-system shall be capable of processing From-Mobile and To-Mobile calls
in accordance with the following sub-sections.

5.2.1 From-Mobile Message Transfer


The message handling sub-system shall have the capability of providing the following functions:

(i) interwork with the access, control and signalling equipment of the LES;

(ii) validate the authorisation status of MESs and destination requested using a list of network
identification codes for each service offered; for example, telex destination codes as defined in
CCITT Recommendation F.69 and Data DNICs as defined in CCITT Recommendation X.121.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 25
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

(iii) provide the message originator with a message reference number;

(iv) accept and temporarily store messages for subsequent transmission;

(v) disassemble message packets;

(vi) analyse the header included in the message if necessary;

(vii) perform number translation between the Inmarsat Mobile Number and the MESs return 24 bit
code that is allocated by Inmarsat;

(viii) issue a message identity to recipients for delivered messages;

(ix) perform character code conversion if required;

(x) validate where possible, the address of the message's destination before transmission;

(xi) provide the message originator with a non-delivery notification if the message is not
successfully delivered;

(xii) transmit a confirmation or message status report if requested by the message originator; and

(xiii) provide special access code addressing (see Volume 4, Chapter 4) for codes with a minimum
of two digits.

5.2.2 To-Mobile Message Transfer


The message handling equipment shall have the capability of the following functions:

(a) accept and temporarily store messages for subsequent transmission;

(b) provide the message originator with the following message reference information:

(i) Message reference number;

(ii) Message handling system identifier; and

(iii) Date and time of accepting message for delivery;

(c) analyse the header included in the incoming message if required;

(d) validate the authorisation and registration status of MESs;

(e) perform number translation between the Inmarsat Mobile Number used by terrestrial
subscribers and the forward 24 bit MES code;

(f) issue a message identity to recipients for delivered messages;

(g) perform character code conversion, if required;

(h) assemble message packets for transmission over the satellite channel;

(j) interwork with the access, control and signalling sub-system;

(k) validate the MESs number before transmission;

(l) provide the message originator with a non-delivery notification if the message is not
successfully delivered; and

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 26
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

(m) transmit a message status report if requested by the message originator.

5.2.3 From-Mobile Distress Calls (Distress Alerts and Distress Priority Messages)
The distress call handling sub-systems shall provide the following functions:

(i) The LES shall only generate a positive delivery notification when successful delivery has been
made to an RCC;

(ii) A non-delivery notification shall be generated if the transmission to an RCC has not
commenced
within 10 minutes or if the call fails subsequently; and

(iii) Distress calls shall only be routed to an RCC, and to no other party.

Note: The validation described in Section 5.2.1 (ii) shall not be carried out for distress calls.

5.3 Optional Additional Facilities


The message handling sub-system may provide the following additional facilities for message
transfer:

5.3.1 Multi-address Messages


The means to send terrestrial based messages to two or more addressees.

5.3.2 Follow-on Messages


This facility may be provided only for terrestrial network originated messages. It permits the message
originator to enter more than one message into the LESs message handling system consecutively
without breaking the terrestrial circuit. Each message will be preceded by a different header.

5.3.4 Mobile-To-Mobile Message Transfer


For MES originated messages addressed to other mobiles in the same ocean region, it is
recommended that message delivery without the use of terrestrial networks is used.

5.4 Message reference information


The message reference information may consist of the following:

(i) LES or message handling system identifier — for example, "Eik LES" for To-Mobile calls;

(ii) date and time;

(iii) message reference number.

See CCITT Recommendation F.127, 1988.

5.4.1 Date and Time


On receipt of a call the date and time of the request message input will be sent to the message
originator before message input.

5.4.2 Message Reference Number

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 27
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

A message reference number will be sent to the message originator immediately following the date
and time information. The reference number will comprise up to six numerical characters and will not
be re-used until the message is delivered or considered undeliverable, whichever is the earliest. Refer
to CCITT U.80, Section 4.3.3.

5.4.3 Terrestrial-Originated Follow-on Message Reference Numbers


For terrestrial-originated follow-on messages, reference numbers will be provided by the message
handling sub-system. After the messages have been transferred, the sub-system will inform the
message originator of the number of messages it has received and the reference numbers of the
messages. The LES need not conform to the last paragraph in U.80, Section 4.3.3.

5.5 Message Header Format


For the Telex service each message received from an MES will contain a header which may consist
of a number of address lines. The message originator should provide each address, in the address
line, which may consist of up to 3 fields as follows:

(a) address to be called;

(b) expected destination identifier or part of it; for example, the answerback; and

(c) delivery indication; for example, desired delay or maximum time limit for message delivery.

Only field (a) is mandatory. Each field within an address line and each address line should be
delimited. The delimiters for the telex service are specified in CCITT Recommendation U.80.

The address lines should be delimited from the message text by an end of address (EOA) signal.

For From-Mobile calls the EOA signal shall be the STX code "start of text" as defined in CCITT
Recommendation T.50.

5.6 Status Enquiry


A message originator who initiates a status enquiry request must provide the message handling
system with the following information:

(a) the message reference information, see Section 5.4; and

(b) an indication of whether the enquiry concerns all addressees associated with a message or
whether the enquiry concerns only address(es) which have not yet received the messages.

The message handling sub-system will validate the message originators terminal identifier with that
taken at the time of message input before responding to the message status enquiry.

5.7 Message Status Notification

5.7.1 From-Mobile Message Transfer


Notification of delivery may be provided if requested. The delivery or non-delivery notification will be
transmitted over the NCS common channel. See Volume 1, Chapter 4, Section 8.2.

5.7.2 To-Mobile Message Transfer


Notification of non-delivery and the message reference information shall always be provided for the
originator.

5.7.3 Non-delivery Codes


Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 28
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

The Non-delivery Code field in a Message Status Descriptor holds a 1-3 character failure code
formatted as IA5 with odd parity. The meaning of the codes are LES specific, but it is mandatory that
they include the following codes:

ABS Absent subscriber

BK Message aborted

BMC No end of message or end of transmission received

DER Out of Order

DTE Remote DTE clearing

EOS Element of service not subscribed (X.400)

FMT Format error

IAB Invalid answerback

INC Inconsistent Request (X.400)

INF Call the Network Information service

INV Invalid Call

ITD Awaiting delivery

LDE Maximum message length exceeded

LPE Local Procedure Error

NA Access Barred

NC Network Congestion

NCH Subscriber's number has been changed

NP Not Obtainable

NRC Reverse charging acceptance not subscribed

OCC Number Busy

IS Recipient improperly specified (X.400)

RDI Redirected call

RPE Remote Procedure Error

RSB Retransmission still being attempted

TMD Maximum number of addresses exceeded

UNK Unknown status (e.g. when the Logical channel number is zero)

For one or two character codes, the field is padded to the right with the IA5 space character.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 29
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

5.8 Message Processing


Full details of the protocols used for message delivery are found in Volume 1, Chapter 4.

5.8.1 From-Mobile Message Processing


Upon receiving a request for assignment from the MES, the LES will check the MES authorisation
status, type of service, message length and network ID so as to ensure that the message can be
accepted and delivered. Depending on the terrestrial network through which the message will be
delivered by the LES, The message handling system will pass the message for transmission over the
terrestrial network.

5.8.2 To-Mobile Message Processing


The LES will analyse the message header and extract the MES number and delivery class
information. The LES will translate the Inmarsat Mobile Number to the forward link 24 bit MES
number.

The status of the MES will be checked to determine whether it is commissioned and logged into the
ocean region. If the MES is not commissioned or it is logged-out of the Ocean region, the LES will
notify the message originator that it is not possible to complete the call.

Abnormal Conditions: it is recommended that if a logged-in MES does not respond to an


announcement, the LES shall make further attempts to send the stored message to the MES within a
certain time period. Only three more attempts to send the stored message are allowed, i.e. the
number of announcement is limited to 4 X MaxL (see Volume 5, Chapter 1). It is recommended that
the time delay between the three attempts are increased every time the LES fails to deliver the
message.

5.8.3 Enhanced Group Call Processing


EGC messages are received at the LES and are converted to the appropriate packet structure. The
LES shall translate the Inmarsat Mobile Number to the unique 24 bit EGC forward ID if required (see
Part 2, Chapter 8). These messages will be forwarded to the NCS using the LES-NCS link. EGC
message addressing is described in Section 9. The associated packet formats are described in
Volume 4, Chapter 3.

In EGC transmission to the NCS single or double header packets may be used; double header
packets giving greater security. All packets containing more than 64 bytes of information shall use the
double header format. In addition all SafetyNETSM traffic containing more than 16 bytes of information
shall use double headers.

5.8.3.1 EGC Closed Networks

In order to ensure an adequate level of security across the network for the provision of EGC closed
networks under FleetNETSM the following defines the restrictions on general access and the necessary
crosschecks:

i) only registered users shall have access to EGC closed network functions;

ii) an Information Provider shall only have access to those EGC closed network IDs (ENIDs),
allocated to him by the service provider;

iii) the LES shall not permit general access to service code 33, Download Group Identity, which
provides the mechanism to download and delete EGC closed network IDs (ENIDs). The LES
shall maintain a separate list of Information Providers, who have been given explicit access to
service code 33, and in addition, the LES shall only perform such a command if:

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 30
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

a) the requesting Information Provider is a registered user, and

b) this registered user has the right to have the given ENID downloaded or deleted.

5.8.4 Optional Data Reporting and Polling Services


For LESs offering the optional data reporting and polling services, restrictions shall be applied to the
access to closed network functions in order to ensure an adequate level of security across the
network:

i) only registered users shall have access to data reporting and polling closed network functions;

ii) a user shall only have access to those data reporting and polling closed network IDs (DNIDs),
allocated to him by the service provider;

iii) general access to the commands to download and delete closed network IDs (DNIDs), shall not
be given. The LES shall maintain a separate list of users, who have been given explicit access
to these commands, and in addition, shall only perform such a command if:

a) the requesting user is a registered user, and

b) this registered user has the right to have the given DNID downloaded or deleted.

Where an LES is simultaneously serving more than one ocean region, it is permissible for polls for
any ocean region served to be forwarded to the NCS indicating an alternative ocean region (for which
that LES also provides service). In such cases the LES ID indicated in the individual poll will have a
different 2-bit ocean region identifier than the sending LES.

If an acknowledgement data report is requested this should indicate the LES ID and Ocean Region
identifier of the originating LES as indicated in the poll.

Note; if an LES sends a poll to an alternative ocean region and requests acknowledgement, only
Global DNID capable mobiles will respond.

5.8.5 Two Digit Prefix Code Processing


For distress and safety purposes, the following 2-digit codes are defined. It is a national matter
whether all of these services are provided by a particular LES.

or maritime safety services -

32 Medical Advice Used for requesting medical advice.

38 Medical Assistance Used for requesting medical assistance.

39 Maritime Assistance Used for requesting maritime search and rescue


assistance.

41 Meteorological reports Necessary for ease of addressing weather reports


from ships to meteorological centres.

42 Navigational Hazards and warnings Used for making urgent navigational/


meteorological danger reports.

43 Ship position reports Used for routing of messages to ship safety


reporting systems.

for general utility -

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 31
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

31 Maritime enquiries Desirable for requesting information including


service offerings.

33 Technical assistance Desirable for addressing technical enquiries to


appropriate personnel.

37 Time and charges requested at Desirable for mobile operator sending


end of call traffic for a third party

Special access codes for other purposes are also available.

6 Testing

6.1 Order Wires


The LES shall be equipped with adequate LES – NCS communications for co-ordination purposes
such as a Voice Order Wire and a Telegraph Order Wire as described in Section 8 of "The Technical
Requirements for Inmarsat Standard-A Coast Earth Stations", Issue 5, March 1989.

6.2 RF Test Capabilities


The LES shall be equipped with suitable radio frequency (RF) and intermediate frequency (IF) test
access points to allow measurement of at least the following signal parameters for each C-Band
carrier transmitted by the LES:

(a) absolute carrier power;

(b) centre frequency of a carrier as received at L-Band.

6.3 Baseband Test Capabilities

6.3.1 Satellite Circuits


The LES shall be equipped with access points for sending, receiving and monitoring signals from
TDM, signalling and message channels at C-Band and in addition, the Interstation Signalling Link
channel units at both L-Band and C-Band. In addition it is recommended that facilities be provided for
the measurement of C/No and bit error rate before forward error correction

6.3.2 Test Code Access


It is recommended that provision be made for MESs to obtain access to the following service
assistance positions:Technical assistance position

Service Designated Code Facility

Telex 33 Technical Assistance Position

In the future, it may be desirable to introduce additional assistance codes. No specifications are
included here, but future introduction should not be precluded.

6.3.3 Performance Verification Testing (PVT)


6.3.3.1 General Requirements

Performance verification testingLESs shall provide facilities for the measurement of signal strength
over a single packet frame (N=0) of a message channel transmission, recording the Bulletin Board

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 32
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

error rate measured by the MES and transmitted to the LES as part of the PVT procedure (see
Volume 1, Chapter 4, Section 10).

LESs shall have the flexibility for setting a test message to be used during performance verification
and commissioning testing.

Note that it is operationally desirable that the test messages should be kept short. A suitable HEX
coded 64 byte test message based on CCITT Rec. V.52 is as follows:

FF83 DF17 3209 4ED1 E7CD 8A91 C6D5 C4C4


4021 184E 5586 F4DC 8A15 A7EC 92DF 9353
3018 CA34 BF42 C759 678F BA0D 6DD8 2D7D
540A 5797 7039 D27A EA24 3385 ED9A 1DEO

6.3.3.2 Facilities to be Provided

The measurement of average power is to be carried out on an operational message channel


referenced to the AFC pilot. The protocols used are described in Volume 1, Chapter 4, Section 10.

6.3.3.3 Accuracy Requirements

The measurement accuracy of the Received signal strength shall be [±1 dB] referred to the L-to-C
AFC pilot.

The upper limit will be determined operationally.

6.3.4 Inmarsat-C Test Terminal


It is recommended that a LES be equipped with a Inmarsat-C test terminal that is able to originate and
receive calls under the control of the automatic equipment. If this facility is provided, using the existing
L-band antenna system, attenuation should be provided so as to be able to reproduce near
operational conditions.

6.3.5 Terrestrial Circuits


It is recommended that the LES shall be equipped with test access points for sending, receiving and
monitoring signals on all terrestrial circuits. It may also be desirable to equip circuits for automatic
testing and measuring.

7 Distress

7.1 General Requirements


The LES shall meet the distress message handling requirements of Radio Regulations, Article 39,
paragraph 3149:

"an earth station in the maritime mobile-satellite service at a specified fixed point receiving a distress
message shall, without delay, take the necessary action to advise the appropriate authorities
responsible for providing for the operation of rescue facilities."

and Article N39, paragraph N 3129:

"........ appropriate coast earth stations in receipt of distress alerts shall ensure that they are routed as
soon as possible to a Rescue Coordination Centre".

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 33
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

7.2 Facilities to be Offered


The LES shall be provided with one of the following means of responding to "Distress Alert" and
Distress Priority messages from MESs:

(a) a terminal or printer in the LES dedicated to answering distress calls and under continuous
supervision; or

(b) the automatic connection to a leased circuit to the nearest Rescue co-ordination Centre (RCC);
or

(c) the automatic connection to a public switched circuit for routing to the RCC on a high priority
basis.

The means of providing priority channels to and from MESs for subsequent message transfer is
described in Volume 1.

7.3 Logging by NCS


Distress alerts will also be logged by the NCS, see Section 8.2, so as to ensure that the Inmarsat
NOC can be made aware of such calls at the time of planned outages and so on.

7.4 Logging by the LES


The LES shall print out or display the contents of each distress alert on receipt and all successfully
received packets of distress priority messages from MESs shall be retained (stored or printed) for
future reference.

In the case of distress priority messages which fail to complete for whatever reason, the contents of
all packets shall be retained and an alarm raised.

7.5 Alarms
Visual and audible alarms shall be provided to alert station personnel if a distress call does not result
in the extension of the call to the associated RCC.

8 Call Data Reports


Land Earth Stations are required to generate two kinds of call record for calls processed at the
station. The first is the Network Record that is transmitted on the Interstation Signalling Link to the
NCS. The generation and transmission of Network Records is determined in Volume 1.

The second are call records to be provided to Inmarsat on a regular basis for all calls processed by
the LES during a specified interval. This information shall be provided in accordance with the Inmarsat
Management Documents, Financial Policies and Procedures Section, reference E “Traffic Accounting
Matters”. The information shall be supplied in the Inmarsat Coded File Format (CFF). A specification
for this format is available from the Manager, Revenue and Signatory Accounts, Inmarsat Finance
Division.

9 EGC Addressing

9.1 Introduction
This section describes the method by which EGC messages are transmitted to land earth stations by
Information Providers for subsequent transmission over the satellite system. The format in which they
are transmitted is also described.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 34
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

9.2 Terrestrial Routing of Messages


An Information Provider wishing to have an EGC message transmitted via the Inmarsat-C system will
use an appropriate terrestrial service such as the Telex or Packet Network to gain access to the
required land earth station. CCITT Rec. F.127 describes the operational procedures.

9.3 Addressing of EGC Packets


Having gained access to the land earth station, the Information Provider must give EGC Packet
address information so that the right groups of MESs, in the right areas, receive the EGC messages.
The EGC packet address information is sent by the Information Provider by means of a special
message header at the beginning of messages that are required to be transmitted. These message
headers l consist of 5 special codes called C codes. The 5 codes may be prefixed by additional
characters, e.g. to indicate that the message is an EGC transmission or the ocean region to which it
should be addressed.

C codes transmitted to the land earth station are: C1 C2 C3 C4 C5:

Where

C1 is the priority code - 1 digit

C2 is the service code - 2 digits

C3 is the address - up to 12 digits

C4 is the repetition rate - 2 digits

C5 is the presentation code - 2 digits

A digit in this context means an alpha-numeric character received from the terrestrial network.

The same information is transferred to the EGC packets and coded as given in Volume 4, Chapter 3,
Section 3.10.

Meanings of the C codes are is explained in the next following sections, but for illustrative purposes
an example is given below:

An incoming EGC telex:

1:31:01:11:00 (the C code message header)


SECURITE
GALE WARNING GALE FORCE 8 EXPECTED IN SOLE AND LUNDY SOON

This example code is for a safety priority (C1 = 1) EGC call containing a MET/NAVAREA warning or
MET forecast (C2 = 31) to Area 1 (C3 = 01) which will be repeated 6 mins (C4 = 11) after the initial
transmission. The text is transmitted in International Alphabet 5 (C5 = 00).

Each of the C codes shall be delimited by the character combination number 3(:) CCITT Alphabet
ITA2.

9.3.1 Priority Codes (C1)

Format as received at land earth station — 1 digit.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 35
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

The C1 code is used to indicate to the land earth station the level of priority needed for the message's
transmission. The priority number is given in ascending order as follows:

0 Routine

1 Safety

2 Urgency

3 Distress

9.3.2 Service Codes (C2)


Format as received at land earth station — 2 digits.

A C2 code is adopted that will explicitly indicate to the EGC receiver the length of the address it will
need to decode during message processing. The presently allocated Service codes are described
below together with the length of the EGC packet address in bytes and the number of digits in the C3
code. 64 Service codes are available.

Service Type is defined as follows:

- SafetyNETSM Only available to SafetyNETSM Information Providers, registered by the IMO


for GMDSS purpose.

- FleetNETSM Available for use by commercial Information Providers.

- System Restricted, and their use is covered by INMARSAT System Operation


Procedures.

Service
Service Name C3 Code Service Type
Code
00 General Call none System
02 Group Call 5 digits FleetNETSM
04 Urgency message, NAV warning to rectangular area 12 digits SafetyNETSM
11 INMARSAT System Message 2 digits System
13 Coastal Warning 4 digits SafetyNETSM
14 Shore-to-Ship Distress Alert to circular area 10 digits SafetyNETSM
23 EGC System Message 9 digits System
24 Urgency message, MET/NAV Warning to Circular Area 10 digits SafetyNETSM
31 MET/NAVAREA Warning or MET Forecast 2 digits SafetyNETSM
33 DownLoad Group Identity (ENID) 9 digits System
34 SAR Co-ordination to rectangular area 12 digits SafetyNETSM
44 SAR Co-ordination to circular area 10 digits SafetyNETSM
72 Chart Correction Service 5 digits FleetNETSM
73 Chart Correction Service for fixed areas 7 digits SafetyNETSM

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 36
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

9.3.3 Addresses (C3)

The methods that Information Providers will use to transmit the EGC packet addresses are given
below for each Service Type described in Section 9.3.2.

9.3.3.1 Service Code 00

Name of Service — General Call:

C3 Code — Empty

Description — used to address messages to all MESs in the region.

9.3.3.2 Service Code 02

Name of Service — Group Call:

C3 Code — 5 digits

Description — used to address closed user groups in the EGC system. The closed user groups will be
allocated 5 digit ENID numbers corresponding to the C3 code.

9.3.3.3 Service Code 04

Name of Service — Urgency Message, Navigational Warnings to Rectangular Areas:

C3 Code — 12 digits

Description — rectangular addresses will consist of 12 digits as received at the LES. These are as
follows:

D1 D2 N or S (3 characters) — Latitude of Southwest corner of rectangle centre in degrees and


whether North (N) or South (S). For latitudes less than 10o, use 0 for D1. For example: 08 for 8o.

D3 D4 D5 E or W (4 characters) — Longitude of Southwest corner of the rectangle in degrees and


whether East (E) or West (W) of the prime meridian.

If the longitude is less than 100° then set D3 (and D4) to zero as necessary. For example: 085 for
85o.

D6 D7 (2 characters) — Extent in degrees of rectangle in latitude (northings).

D8 D9 D10 (3 characters) — Extent in degrees of rectangle in longitude (eastings).

For example, 12S124E10010

A rectangle whose Southwest corner is 12° S and 124° E. The extent of the rectangle is 10° north and
10° east.

9.3.3.4 Service Code 11

Name of Service — Inmarsat System Message:

C3 Code — 2 digits

Description - This service is used to address EGC receivers under the following categories:

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 37
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

00 all mobiles

01 AOR East

02 AOR West

03 POR

04 IOR

05 Inmarsat A MESs only

06 Inmarsat C MESs only

07 Inmarsat B MESs only

08 Inmarsat M MESs only

09 Inmarsat B and M MESs only

0A Inmarsat Aero-C AMESs only

0B-FF Spare

9.3.3.5 Service Code 13

Name of Service — Coastal Warning:

C3 Code — 4 digits

Description — The Navarea X1 and X2 codes and the Coastal area B1 and B2 codes are transmitted
to the LES as 4 characters. The order of transmission is X1, X2, B1 and B2.

The following is a list of the B1 and B2 codes:

B1 is a character identifying the Coastal information coverage area (see Volume 2, Chapter 4).

B2 is a unique character for each type of message as follows:

A: Navigational warnings

B: Meteorological warnings

C: Ice reports

D: Search and rescue information

E: Meteorological forecasts

F: Pilot service messages

G: DECCA messages

H: LORAN messages

I: OMEGA messages

J: SATNAV messages

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 38
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

K: Other electronic navaid messages

L: Additional Navigational warnings

Z: QRU (no message on hand)

X1X2 is a two character IA5 representation of the Navarea code from 00 to 99. The Navareas are
shown in Figure 1 of Volume 2, Chapter 4.

9.3.3.6 Service Code 14

Name of Service — Shore-to-Ship Distress Alert to circular area:

C3 Code - 10 digits

Description — Circular address will consist of 10 numbers as follows;

D1 D2 N or S (3 characters) — Latitude of centre in degrees and whether North (N) or South (S). For
latitudes less than 10°, use 0 for D1. For example: 08 for 8°

D3 D4 D5 E or W (4 characters) — Longitude of centre in degrees and whether East (E) or West (W)
of the prime meridian. For longitudes less than 100° set D3 (and D4) to zero as necessary. For
example: 085 for 85°

M1 M2 M3 (3 characters) — Radius of circle in nautical miles. Up to 999 NMs.

For example, 56N034W010

Centre of circle is 56° N 034° W

Radius of circle is 10 nautical miles.

9.3.3.7 Service Code 23

Name of Service — EGC System Message:

C3 Code — 9 digits

Description — used to send messages to an individual EGC receiver.

9.3.3.8 Service Code 24

Name of Service — Urgency message, Meteorological and Navigational Warnings to Circular areas:

C3 Code — 10 digits

Description — see 9.3.3.6 for description of circular addressing.

9.3.3.9 Service Code 31

Name of Service — Meteorological or Navarea Warnings or Meteorological Forecast:

C3 Code — 2 digits

Description — up to 99 Navareas can be addressed.

See Volume 2, Chapter 4.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 39
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

9.3.3.10 Service Code 33

Name of Service — Download Group Identity (ENID):

C3 Code — 9 digits

Description — used to download and delete EGC Network IDs (ENIDs) at a specific EGC receiver.
Each EGC receiver is allocated a unique 9 digit Inmarsat mobile number. The ENIDs will be managed
by Inmarsat. The downloading instructions are given in the text part of the EGC message in the
following format:

/K/Download command1/ENID1/Download command2/ENID2 /


Originator Identification String

Where:

K the number of commands Range = 1 to 5


in the message

Download a single character defining N or n. New entry to EGC receiver's list of ENIDs
Command the command
D or d. Delete an ENID in the EGC receiver's list

Originator a string of maximum 25 Format as follows:


Identification characters identifying the [LES ID],[Information Provider]
String LES downloading or deleting e.g: 102, ABC Oil Company
the ENID and the information
provider "owning" the ENID

Note that the syntax implies that all commands in a particular EGC message have the same
originator.

Example of an EGC Download Group, as it might be entered through the telex network:

0:33:123456789:22:00
/1/N/12345/
102, ABC Oil Company
NNNN

This is a routine priority message to download a new ENID 12345 to EGC receiver number
123456789, using IA5 alphabet and repeat the message after two hours. The LES undertaking the
download is 102 and the information provider which requested the download was the ABC Oil
Company. One command only is included in the message.

9.3.3.11 Service Code 34

Name of Service — Search and Rescue Co-ordination to rectangular area:

C3 Code — 12 digits

Description — see Section 9.3.3.3 for description of rectangular address.

9.3.3.12 Service Code 44

Name of Service - Search and Rescue Co-ordination to circular area:

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 40
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

C3 Code — 10 digits

Description — See Section 9.3.3.6 for description of circular address.

9.3.3.13 Service Code 72

Name of Service — Chart Correction Service:

C3 Code — 5 digits

Description — Used to address electronic chart corrections to ENIDs.

9.3.3.14 Service Code 73

Name of Service - SafetyNETSM Chart Correction Service for fixed areas:

C3 Code - 7 digits

Description - up to 9,999,999 fixed areas can be addressed. Details of this service are still under
consideration by IHO and IMO.

9.3.4 Repetition Codes (C4)

Format as received at land earth station - 2 digits. The C4 repetition codes are divided into 2
categories:

Category a) for messages that are required to be repeated a finite number of times; and

Category b) for messages that are required to be repeated at specified intervals until cancelled by
the information provider.
SM
In general the first category will apply to FleetNET Information Providers and the second
SM
incorporates the needs of Maritime Safety Information Providers for the SafetyNET services.

9.3.4.1 Category (a) Repetition Codes

01 transmit once on receipt

11 transmit on receipt followed by repeat 6 minutes later

61 transmit 1 hour after initial broadcast (twice)

62 transmit 2 hours after initial broadcast (twice)

63 transmit 3 hours after initial broadcast (twice)

64 transmit 4 hours after initial broadcast (twice)

66 transmit 12 hours after initial broadcast (twice)

67 transmit 24 hours after initial broadcast (twice)

70 transmit 12 hours after initial broadcast then 12 hours after the second broadcast. (three
times)

71 transmit 24 hours after initial broadcast then 24 hours after the second broadcast. (three
times)

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 41
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

9.3.4.2 Category (b) Repetition Codes

The following repetition codes are mandatory for SafetyNETSM information providers.

A category (b) repetition code allows a message to be repeated until cancelled by the message
provider. The repetition period can be set at between 1 and 120 hours. In addition, each transmission
can be echoed after a fixed period of 6 minutes.

The repetition codes are of the form < Multiplier > < Delay > where < Multiplier > specifies the
number of delay periods between each broadcast and < Delay > is a fixed number of hours.
The Multiplier digit may be any digit from 1 to 5 as follows:

Multiplier

1 1 specified delay period between broadcasts

2 2 specified delay periods between broadcasts

3 3 specified delay periods between broadcasts

4 4 specified delay periods between broadcasts

5 5 specified delay periods between broadcasts

The Delay digit coding is:

Delay

2 1 hour delay; no echo

3 1 hour delay; with echo

4 6 hours delay; no echo

5 6 hours delay; with echo

6 12 hours delay; no echo

7 12 hours delay; with echo

8 24 hours delay; no echo

9 24 hours delay; with echo

The various combinations are shown in the table below:

Multiplier

Delay 1 2 3 4 5 Echo

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 42
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

2 1 2 3 4 5 no
3 1 2 3 4 5 yes
4 6 12 18 24 30 no
5 6 12 18 24 30 yes
6 12 24 36 48 60 no
7 12 24 36 48 60 yes
8 24 48 72 96 120 no
9 24 48 72 96 120 yes

Examples

1 Code 19 means " repeat broadcast every 24 hours with an echo 6 minutes after each
broadcast"

2 Code 38 means " repeat broadcast every 72 hours with no echo"

9.3.4.3 Cancel Facility

A cancellation facility for messages transmitted to an LES with Category (b) repetition codes shall be
provided at the LES to terminate the repetition.

It is recommended that the following format shall be supported :

"Cancel <Message Reference Number> at <Date/Time>"

where <Message Reference number> is the number given to the message provider by the LES on
receipt of the initial message and <Date/Time> is of the form:

DDHHMM Z space MMM space YY

For example 2 1 1 4 3 0 Z FEB 88

If the Cancel instruction accompanies a broadcast message it will appear between the NNNN and
++++ characters as follows :

- ZCZC

- C1 C2 C3 C4 C5

- "Text "

- NNNN

- CANCEL ( Message Reference Number ) at ( Date/Time Group )

- ++++

Notes:

1 Only the "text" is for transmission.

2 When included with a message for broadcasting, the LES message cancellation instructions
will appear between the N N N N and the + + + + characters. There will only be one instruction to
each line, but the facility to provide for more than one line of instructions is desirable.

3 If the cancellation instruction terminates after the Message Reference Number, i.e. the
(Time/Date) is not included, then the instruction should be executed immediately.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 43
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

4 It should also be possible for a Cancel instruction to be sent to the LESs Store and Forward
unit.

9.3.5 Presentation Codes (C5)

The current allocation of presentation codes is as follows:

00 IA number 5 (IRV version) odd parity

01 Reserved

02 Reserved

03 Reserved

04 Reserved

05 Reserved

06 ITA 2

07 Data

10 Addressing of Polling Services

10.1 General
This section describes a method by which terrestrial users can gain access to the Polling services via
a Land Earth Station.

10.2 Terrestrial Routing of Polling Commands


A terrestrial based user wishing to use the Polling Services of the Inmarsat-C system should use an
appropriate terrestrial service such as the Telex or Packet Switched network to gain access to an
LES. To gain access to the Polling services, a number of instructions need to be sent to the LES so
as to inform the equipment of the type of poll required. The access method is a national matter,
however for guidance the following is an example of a terrestrially originated polling command set. It
should consist of the following information:

(i) Poll Type

(ii) Data Network ID (DNID)

(iii) Response Type

(iv) Sub- Address

(v) Terminal or Area address

In addition text or data may follow the command set.

10.2.1 Poll Type


Three types of Poll are available:

(i) Group Poll,

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 44
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

(ii) Individual Poll, and

(iii) Area Poll

A full description of Group, Individual and Area Polls is to be found in Volume 4, Chapter 9, which also
describes the downloading of Data Network IDs.

10.2.2 Data Network ID


The Data Network ID (DNID) is used in the Polling Services to define a group of mobile terminals and
the method of accessing the terrestrial user. In general the terrestrial access is a national matter, but
in the simplest case the DNID is used to identify a polling output file at the LES. The use made of the
DNID by the type of Poll is explained below:

(a) For the Group Polling service, the DNID defines a group of mobile terminals and an Output file
at the LES.

(b) For the Individual Polling service, the DNID defines only an output file at the LES.

(c) For the Area Polling service, the DNID defines a group of mobile terminals and an output file at
the LES which will contain the polling responses from only those mobile terminals that are
within the polled area. It is recommended that the EGC Circular addressing method described in
Section 9.3.3.6 be adopted.

10.2.3 Response Type


For any Polling command set transmitted by a LES there is a choice of responses available from the
mobile terminal. These responses are:

(a) Data Report, for short responses.

(b) Message Channel Report for longer responses.

(c) Choice of Data Report or Message Channel Report ( Mobile Terminal decides).

10.2.4 Sub-Address
The Sub-Address is used to identify specific ports on the mobile terminal.
See Volume 4, Chapter 3, Section 4.23.

10.3 Polling Command Input Addressing to the LES


As described above, the method by which the terrestrial based user transmits the polling command to
the LES is a national matter.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 45
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Annex 1: Year 2000 Compliance

The Inmarsat-C LES shall be compliant with the year 2000 date change so that it can:

- handle date information before, during and after 1 January 2000, including but not limited to
accepting date input and performing calculations on dates or portions of dates

- function accurately and without interruption before, during and after 1 January 2000 without
changes in operation associated with the advent of the new century

- respond to two-digit year date input in a way that resolves the ambiguity as to the century in a
disclosed, defined and pre-determined manner

- store and provide output of date information in ways that are unambiguous as to century

- manage the leap year occurring in the year 2000 following the quad-centennial rule.

In addition, GPS receivers used in conjunction with the Inmarsat-C LES shall be able to manage the
rollover occurring in that system at midnight on 21 August 1999.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 46
Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 3: The Inmarsat C Numbering Plan

Contents

1 Introduction ............................................................................ 2

2 Maritime Numbering Plan ........................................................ 2

3 Land Mobile Numbering Plan ................................................... 2

4 Future Expansion .................................................................... 2

5 Test Terminals ........................................................................ 2

6 Closed Network IDs ................................................................. 2

7 LES and NCS Identities ........................................................... 2

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 1
Chapter 3: The Inmarsat C Numbering Plan
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
The Inmarsat-C Numbering Plan is the system by which unique identities are allocated to the stations
(LES, MES, and NCS) using Inmarsat-C. It follows CCITT Recommendation F.125. The Inmarsat-C
numbering plan consists of the following digits:

T X1 X2 X3 X4 X5 X6 X7 X8 (9 digits)

where T is a system identifier, which for Inmarsat-C = 4 and X1 X2 X3 X4 X5 X6 X7 X8 depend on the


type of MES.

The number includes 3 digits which identify the country in which the MES is registered.

2 Maritime Numbering Plan


For ordinary calls to SES the format shall initially be:

4 M1 I2 D3 X4 X5 X6 X7 X8

MID identifies the country where the SES is registered.

3 Land Mobile Numbering Plan


For Land Mobile MESs the Inmarsat-C Mobile Number takes the form 4 + [8 or 9] + M2 C3 C4 X1 X2 X3
X4 MCC identifies where the land mobile MES is registered.

4 Future Expansion
[TBD]

5 Test Terminals
The IDs for the NCS, LES and other special test terminals will be advised by Inmarsat. These will
typically be in the form 4000 X5 X6 X7 X8 for maritime and 4999 X5 X6 X7 X8 for land mobile mobiles.

6 Closed Network IDs


A range of five-digit (decimal) numbers that will be allocated in blocks to Routing Organisations.

7 LES and NCS Identities


An 8 bit byte is allocated for NCS and LES IDs in the various packets used in the signalling system.
This byte will be coded:

[Ocean Region] [NCS/LES ID]

2 bits 6 bits

The 2 bit ocean region identifier is coded as follows:

00B Atlantic Ocean Region (West)

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 2
Chapter 3: The Inmarsat C Numbering Plan
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

01B Atlantic Ocean Region (East)

10B Pacific Ocean Region

11B Indian Ocean Region

The unique LES IDs will take the following decimal form:

316: LES 16 in Indian Ocean

102: LES 2 in Atlantic Ocean (East)

NCS IDs will be assigned in the range x44 to x63 and LES IDs x00 to x43 (where x is the 2 bit ocean
region identifier and 0≤x≤3). The allocation of the Inmarsat-C LES and NCS IDs can be found in the
document ID 003C (Information Document) which is a part of Inmarsat Network Operation Handbook
(NOH). This can be obtained upon request from the Inmarsat Network Operation Centre (NOC).

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 3
Chapter 3: The Inmarsat C Numbering Plan
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 4: Inmarsat C / Basic X.400 Interworking

Contents

1 Introduction and Overview ...................................................... 6


1.1 Abbreviations ....................................................................................................6
1.2 Introduction .......................................................................................................7
1.3 Interworking Principles ......................................................................................7
1.3.1 Gateways .......................................................................................................7
Figure 1: Transferring Messages only .....................................................................8
Figure 2: Acting as an End User .............................................................................8
1.3.2 Gateway Design Guidelines ...........................................................................8
Figure 3: Overlap of Protocol Elements ..................................................................8
1.3.3 Mapping Principles .........................................................................................9
Figure 4: X.400 to Inmarsat-C .................................................................................9
Figure 5: Inmarsat-C to X.400, the Mapping Functions are Reversible ...................9

2 Elements of service classification ........................................... 9


2.1 Basic Message Transfer Service .................................................................... 10
Figure 6: Scenario Description .............................................................................. 10
Figure 7: The Inmarsat-C Message Transfer Service ........................................... 11
Table 1: Inmarsat-C MTS' Classification ............................................................... 12
2.2 Basic Interpersonal Messaging Service .......................................................... 13
Figure 8: Scenario Description .............................................................................. 13
Figure 9: The Inmarsat-C InterPersonal Messaging Service................................. 14
Table 2: Inmarsat-C IPMS Classification .............................................................. 15

3 Message Transfer System ...................................................... 16


3.1 Message Transfer System in the Context of Inmarsat-C Interworking with MHS .
........................................................................................................................ 16
Figure 10: Functional Model.................................................................................. 17
3.2 Objects and Ports Description......................................................................... 17

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 1
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 11: General Access to the MTS ................................................................. 18


Figure 12: Refined Access Model ......................................................................... 19
3.3 Abstract Operations ........................................................................................ 19
Figure 13: Dependences between Elements of Service and Associated Information
Element ................................................................................................ 20
Figure 14: Example Classification ......................................................................... 21
3.3.1 MessageSubmission Abstract Operation ..................................................... 21
Figure 15: Depiction of Origination and Reception ................................................ 22
Table 3: MessageSubmission Abstract Classification .......................................... 22
3.3.2 MessageDelivery Abstract Operation ........................................................... 23
Figure 16: Depiction of Origination and Reception ................................................ 23
Table 4: Message and Report Delivery Abstract Classification ............................ 24
3.3.3 Inmarsat-C Message Transfer Service Abstract Syntax Definition ............... 25
Table 5: ANY DEFINED BY types for ExtensionAttributes .................................... 25
Table 6: ANY DEFINED BY Types and Criticality for ExtensionFields .................. 25
Figure 17: INMC-MTS ........................................................................................... 25
Figure 18: INMC-MTS-Extensions ........................................................................ 32
Figure 19: INMC-MTS-UB ..................................................................................... 33
3.4 Message Identification .................................................................................... 35
3.4.1 From-Mobile Message Identification ............................................................ 35
Figure 20: Message Identification ......................................................................... 36
3.4.2 To-Mobile Message Identification ................................................................ 36
3.4.3 Mobile-To-Mobile Message Identification ..................................................... 37
3.5 Procedure Description..................................................................................... 37
Figure 22: Scope of this Section ........................................................................... 37
3.5.1 Processing of the MessageSubmission Operation ....................................... 38
Table 7: MessageSubmission Abstract Handling Summary ................................. 38
3.5.2 Processing of the MessageDelivery Operation ............................................ 39
Table 8: Message Delivery Abstract Handling Summary ...................................... 39
3.5.3 Processing of the Report Delivery Operation ............................................... 40

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 2
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Table 9: Report Delivery Abstract Handling Summary .......................................... 40


3.5.4 MTS-Bind and MTS-UnBind......................................................................... 41
3.6 Realization of Abstract Operations .................................................................. 41
Table 10: Summary of IAPDUs ............................................................................. 41
Figure 23: The Steps to Define the Inmarsat-C Message Transfer System Protocols
42
Figure 24: Employment of the Inmarsat-C Channels and Signals by the Gateway43
Figure 25: From-Mobile Call Procedure ................................................................ 44
Figure 26: To-Mobile Call Procedure .................................................................... 46
3.7 Encoding of IAPDUs ....................................................................................... 46
3.7.1 General Encoding Rules .............................................................................. 47
3.7.2 Employment of Inmarsat-C Channels and Signals ....................................... 49
3.7.3 A Textual Encoding of IAPDUS .................................................................... 50
3.7.4 A Textual Encoding of Delivery and Non-Delivery Reports .......................... 50
Table 11: Message Submission Envelope Fields.................................................. 53
Table 11: Message Submission Envelope Fields, continued…............................. 54
Table 12: Per Recipient Message Submission Fields ........................................... 55
Table 13: Message Delivery Envelope Fields ....................................................... 56
Table 13: Message Delivery Envelope Fields, continued… .................................. 57
Table 13: Message Delivery Envelope Fields, continued… .................................. 58
Table 14: ORNames ............................................................................................. 59
Table 15: Delivery-Report Fields........................................................................... 60

4 Interpersonal Messaging System in the Context of Inmarsat-C


Interworking with MHS ............................................................... 61
Figure 27: InterPersonal Messaging Scenario ...................................................... 61
Figure 28: InterPersonal Messaging Scenario To or From a Mobile User ............ 62
4.1 Abstract Information Objects ........................................................................... 62
Figure 29: Dependencies Between Elements of Service and Associated Information
Elements 62
Table 16: Inmarsat-C IPM Heading Fields ............................................................ 64
Table 17: Inmarsat-C IPM Body Part Types ......................................................... 65

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 3
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 30: Information Objects .............................................................................. 65


Figure 31: Extensions ........................................................................................... 69
Figure 32: Upper Bounds ...................................................................................... 69
4.2 Abstract Service Definition .............................................................................. 70
4.2.1 Secondary Object Types .............................................................................. 70
Figure 33: The InterPersonal Messaging System Extended with the InmCA ........ 71
4.2.2 Inmarsat-C Agent ......................................................................................... 71
Figure 34: Refinement of the InmCA..................................................................... 71
4.2.3 Inmarsat-C User ........................................................................................... 72
4.3 Abstract Ports and Operations ........................................................................ 72
4.3.1 Abstract Ports .............................................................................................. 72
4.3.2 Abstract Operations ..................................................................................... 72
Figure 35: Origination & Reception for the OriginateIPM Abstract Operation ....... 73
Table 18: Classification of Abstract Operations Supplied by the Origination Port . 73
Figure 36: Origination and Reception for ReceiveIPM and ReceiveReport Abstract
Operations ........................................................................................... 74
Table 19: Classification of Abstract Operations Supplied by the Reception Port .. 74
4.4 Message Identification in the IPMS ................................................................. 75
4.4.1 From-Mobile Message IPM Identification ..................................................... 75
Figure 37: Message Identification of a Mobile Originated IPM .............................. 76
Figure 38: Delivery Notification of a Mobile Originated IPM .................................. 77
4.4.2 To-Mobile Message IPM Identification ......................................................... 78
Figure 39: Message Identification of a Terrestrial Originated IPM ........................ 78
Figure 40: Delivery Notification of a Terrestrial Originated IPM ............................ 79
4.4.3 Mobile To Mobile Message IPM Identification .............................................. 79
4.5 Inmarsat-C Agent Operation in Provision of the IPM Abstract Service ........... 79
4.5.1 Procedures of the InmC-MES - Realization Of Abstract Operations ............ 79
4.5.2 Procedures of the InmC-GTW - Mapping Of Abstract Information Objects .. 80
Table 20: Mapping of Inmarsat-C IPM Heading Fields ......................................... 80
Table 21: Mapping of Inmarsat-C IPM Body-Part Types....................................... 80

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 4
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.6 A Textual Representation of Abstract Information Objects ............................. 81


4.6.1 General Encoding Rules .............................................................................. 81
4.6.2 A Textual Encoding of Abstract Information Objects - Introduction to the
Tables .......................................................................................................... 83
4.6.3 X.400 InmC-MES Address Specification ...................................................... 83
Table 22: IPM Heading Fields ............................................................................... 85
Table 23: Body-Part Fields ................................................................................... 86
Table 24: ORDescriptor and RecipientSpecifier Fields ......................................... 87

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 5
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction and Overview


This chapter gives an introduction and overview of Basic X.400 interworking with Inmarsat-C system.

1.1 Abbreviations

Name/
Description
Abbreviation
ADMD ADministrative Management Domain
API Application Program Interface
AU Access Unit
Data Carrier Equipment, in this context the mobile transceiver to which the
DCE
mobile DTE is connected
DL Distribution List
DTE Data Terminal Equipment
EDI Electronic Data Interchange
EGC Enhanced Group Call
EOS Element Of Service
FS Functional Standard
GES Ground Earth Station, alternative for LES
GTW Gateway
IAPDUs Inmarsat Application Protocol Data Units
IPM InterPersonal Messaging
IPMS InterPersonal Messaging Service
IWU InterWorking Unit
MHS Message Handling System
MPDU Message Protocol Data Unit
MS Message Store
MSAP Message Store Access Protocol
MSS Mobile Satellite Service
MSSFU Mobile Satellite Store-and-Forward Unit
MSSUA Mobile Satellite Service User Agent
MTA Message Transfer Agent
MTS Message Transfer Service
NCS Network Co-ordination Station
NDN Non-Delivery Notification
NSAP Network Service Access Point
OSI Open Systems Interconnection
P1 Message transfer system transfer protocol
P2 Interpersonal messaging protocol
P3 Message transfer system access protocol
P7 Message store access protocol

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 6
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Name/
Description
Abbreviation
PDU Protocol Data Unit
PRMD PRivate Management Domain
SES Ship Earth Station
UA User Agent
UAPDU User Agent Protocol Data Unit
XAPIA X.400 Application Program Interface Association
X.25 Network access protocol
X. 400 Message handling system

1.2 Introduction
The document provides the technical specification for a Gateway to interconnect Inmarsat-C and
X.400, specifically the InterPersonal Messaging System of X.400. This specification defines a "Basic"
service in that X.400 elements of service are transferred across the satellite in plain text.

Section 2 specifies the Elements of Service which are supported by this Gateway for the Basic
service. Sections 3 and 4 provide the details for the handling of these elements of service by the
Gateway for the Message Transfer System and the InterPersonal Messaging System respectively.

A MES can check from the LSE's Bulletin Board on whether a particular LES supports the Basic
service as described in this document. If the "Basic X.400 supported" indicator located at Byte 2 of the
TDM descriptor field of the Bulletin Board is set, the LES is providing this basic service. Conversely, a
LES can check whether an X.400 message can be delivered, in this basic service syntax format, to a
particular MES. If the "Basic X.400 supported" indicator located at the 'Options' field of the MES's
'Class' descriptor is set, the MES is a consumer of this basic service.

1.3 Interworking Principles


This section outlines the interworking principles between Inmarsat-C and the X.400 InterPersonal
Messaging System by means of a Gateway.

1.3.1 Gateways
In general, the Gateway permits the interchange of messages between X.400 and Inmarsat-C,
matching dissimilar characteristics of the two services. Normally, such a Gateway must be
transparent to the services common to the interconnected systems, and emulate the special services
not supported by one of the systems.

The most difficult problem encountered in the Gateway design has been the absence of a number of
X.400 service elements in Inmarsat-C, such as blind copies, deferred delivery, etc. This problem has
been solved by allowing the Gateway to provide these service elements. The mapping between non-
common characteristics of the systems interconnected through the Gateway has been made
according to the available CCITT recommendations.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 7
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: Transferring Messages only

Gateway
SendMessage

Result

ReceivedMessage

Figure 2: Acting as an End User

Gateway (AccessUnit)
SendMessage
SendMessage

Result

Normally, a gateway is only concerned with transferring services between end users, the originator
and the recipient, see Figure 1. Support of service elements on reception is not a gateway issue,
although in some cases the gateway performs as an end user and thus as the ultimate recipient, see
Figure 2, this is generally the way probes will be handled by the gateway.

1.3.2 Gateway Design Guidelines


This section describes the design guide-lines used in the specification of the Gateway. The design is
based on matching dissimilar characteristics of the services involved in intercommunication by means
of a Gateway:

1. the Message Transfer Service (MTS), which is provided by the P1 protocol specified in X.411;

2. the InterPersonal Messaging Service (IPMS), which is provided by the P2 protocol specified in
X.420. The IPMS is built upon the MTS and offers its services to end users; and

3. the Inmarsat-C Group-Directed and Individual-Directed Messaging Service, which is provided


by Inmarsat-C Channels and Signals specified in the Inmarsat-C System Definition Manual.

Figure 3 gives a graphical representation of the overlap of protocol elements providing the three
services.

Figure 3: Overlap of Protocol Elements

IPMS
P2

Inm-C
Ch&Si

MTS
P1/P3

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 8
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The Message Transfer Service is built upon lower-layer services, such as Reliable Transfer Server
(RTS), Presentation services, etc. As none of the lower-layer service elements are directly available to
the IPMS user, these services do not need to be considered in the Basic gateway specification.

Inmarsat-C does not explicitly define service elements, as distinct from message fields (i.e. protocol
elements). However, all of the Inmarsat-C message fields, with the exception of some control
information fields, can be regarded as corresponding to implicit Inmarsat-C service elements.

This document considers only the IPMS, and not any other usage of the Message Transfer Service.
Any other usage of the Message Transfer Service, for instance EDI Messaging, is for further study.

1.3.3 Mapping Principles


For some services, corresponding protocol elements are provided by both Inmarsat-C and
IPMS/MTS, so the full service can be provided to end users by mapping the corresponding protocol
elements. In several other cases, a mapping is used to place the information contained in P2 protocol
elements and the associated P1 envelope into the contents of the Inmarsat-C message. This can be
regarded as partial support, as it allows the information to be conveyed to the end user even though
there is no corresponding Inmarsat-C protocol element. Hence, even if there is a complete mismatch
of protocol elements the related service can still be partially provided, see Figures 4 and 5.

Figure 4: X.400 to Inmarsat-C

X.400 mapping functions Inmarsat-C

p2 protocol elements message text

p1 protocol elements channels & signals

Figure 5: Inmarsat-C to X.400, the Mapping Functions are Reversible

X.400 mapping functions Inmarsat-C

p2 protocol elements message text

p1 protocol elements channels & signals

2 Elements of service classification


This section is primarily concerned with both the classification of Elements of Service (EOS)
belonging to the Basic Inmarsat-C MTS'. and to the Basic Inmarsat-C IPMS'. The Elements of Service

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 9
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

for both the Basic Inmarsat-C Message Transfer Service (MTS') and the Basic Inmarsat-C
InterPersonal Messaging Service (IPMS') are described here.

2.1 Basic Message Transfer Service


Elements of Service are associated with the various services provided in the MHS. The Elements of
Service are inferred from protocol elements which are described in Section 3. The Elements of
Service (EOS) supported by the Basic Inmarsat-C MTS' are still a subset of the Elements of Service
supported by the minimum kernel of A/3311 (3311.1). A classification scheme in line with X.400 profile
A/3311 is used.

The classification of EOS belonging to the terrestrial MTS is covered by functional profile A/3311.
Figure 6 describes the scenario used in this classification.

Figure 6: Scenario Description

MTS-user GTW MTA MTS-user

Scope of this
Scope of A/3311
Chapter

The scenario describes two MTS users (MTS-users) engaged in intercommunication via a Message
Transfer Agent (MTA) and a Gateway (GTW). In this scenario the Basic Inmarsat-C Message
Transfer Service is provided by the co-operative performance of the GTW and MTA.

The MTS in the context of Inmarsat-C interworking with X.400 has different appearances. At the
terrestrial side, service appears as defined in the base standards and profiles. At the satellite side,
service appears in a lightweight fashion. The difference manifests itself in the support of different
subsets of EOS, and a different usage of the underlying services. The difference in appearance as a
result of different subsets of supported EOS is outside the scope of this document for the following
reason:

X.400 Management Domains may offer different functions, capabilities, or features. Therefore the
support of different subsets of EOS is not specific to Inmarsat-C interconnection with X.400.

Section 3 deals with the difference in appearance as a result of different usage of the underlying
services. Figure 7 illustrates the difference in appearance of the MTS in the context of Inmarsat-C
interworking with X.400. The gateway is the functional unit concerned with mapping the terrestrial MT
service onto the Inmarsat-C MT Service, and vice versa. MT Service mapping itself is described in
Section 3.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 10
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 7: The Inmarsat-C Message Transfer Service

MTS- MTS- MTS'- MTS'-


user user user user

EOS EOS'

Service Inmarsat-C
MT Service mapping MT Service

Covered by A/3311 Covered by


Interworking Specification

Each EOS associated with the Basic Inmarsat-C MTS' will be classified for Origination and Reception.
The class 'Origination' consists of all EOS which may be originated from a Basic Inmarsat-C MTS
user (MTS' user). The class 'Reception' consists of all EOS which may be conveyed to a Basic
Inmarsat-C MTS user (MTS' user). The classification for a specific class, e.g. Origination, is
independent of the classification for another class, e.g. Reception. Thus an EOS can be Mandatory
for Origination and still Optional for Reception.

The Basic Inmarsat-C MTS' is fully provided by the procedures implemented in the terrestrial MTS,
there are no further actions of the gateway required in conjunction with those procedures. Hence
there is no need for a separate class 'Implemented' for the Basic Inmarsat-C MTS classification.

A clear distinction is retained between EOS and protocol elements necessary to fulfil them. Due to the
different usage of the underlying services the gateway has to reformat the information associated with
each element of service supported, either mandatory or optional. Section 3 classifies the protocol
elements which needs to be reformatted.

The following categories apply to EOS belonging to the Inmarsat-C Message Transfer Service:

Category Description
Support for this element or feature depends on a specified
C Conditional
condition.
Support of the element or feature is outside the scope of this
I Out of Scope
document
- For origination (Orig): The Element of Service is logically
impossible or otherwise not applicable in the context of
Inmarsat-C X.400 interworking.
- Not Applicable
- For reception (Rec): The Element of Service is logically
impossible or otherwise not applicable in the context of
Inmarsat-C X.400 interworking.
- For origination (Orig): The gateway will not make this EOS
available to the MES.
N Not Supported
- For reception (Rec): The gateway will not make the
information associated with this EOS available to the MES.
- For origination (Orig): The gateway shall make this EOS
available to the MES.
M Mandatory
- For reception (Rec): The gateway shall make the information
associated with this EOS available to the MES.
- For origination (Orig): The gateway may make this EOS
available to the MES.
O Optional
- For reception (Rec): The gateway may make the information
associated with this EOS available to the MES.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 11
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

In Table 1, the first three columns apply to the minimum kernel of A/3311. The following columns
apply to the Basic Inmarsat-C MTS'.

Table 1: Inmarsat-C MTS' Classification

Service Element MTS (3311.1) MTS'


Number Name Orig Imp Rec Orig Rec
B.1 Access Management M M M - -
B.3 Alternate recipient allowed M C C N N
B.12 Content type indication M M M O M
B.13 Conversion prohibition M M M M M
Conversion prohibition in case of loss of
B.14 M M M M M
information
B.15 Converted indication - M M - M
B.19 Deferred delivery M M - N -
B.20 Deferred delivery cancellation M M - N -
B.21 Delivery notification M M - M1 -
B.22 Delivery time stamp indication - M M - O
B.25 Disclosure of other recipients M M M N N
B.26 DL expansion history indication - O M - N
B.27 DL expansion prohibited M M - M2 -
B.30 Explicit conversion M O - M -
B.32 Grade of delivery selection M M M M M3
B.41 Message identification M M M M5 O6
B.45 Multi-destination delivery M M - M -
B.47 Non-delivery notification M M - M -
B.54 Original encoded information type indication M M M M M
B.61 Prevention of non-delivery notification M M - N -
B.63 Probe M M - N -
B.68 Redirection disallowed by originator M M - N -
B.89 Submission time stamp indication M M M N M
B.92 Use of distribution list M O M -4 -4
B.93 User/UA capabilities registration - M M N N

1: Note that a delivery report is requested on a per-recipient basis and not on a per-message
basis.

2: Submission of a message to a DL is similar to the submission of a message to a user. A DL is


represented by an ORName. From an ORName you cannot tell whether you send to a user, or
to all members of a DL. DL expansion prohibition is the only means to prevent a message from
being send to DL members. Default DL expansion is allowed. The occurrence of DL expansion
is not reported to the mobile originator.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 12
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3: The priority of an Inmarsat-C message transfer is not relative to this element of service.
However the Inmarsat-C priority mechanism may be used by an LES operator to meet the
message transfer time targets applicable for ADMD's as mentioned in CCITT Recommendation
F.410.

4: After submission a message is transferred to the DL expansion point by the MTS. Upon
detection by the MTS that a recipient ORName represents a DL. DL expansion will occur if the
originator of the message has permission to submit to the particular DL. DL submit permission
is one of the properties of a DL. A DL owner is responsible for the management of the DL and
its properties. DL expansion and DL management is done by the terrestrial MTS. Its not
applicable for the Basic Inmarsat-C MTS'.

5. For origination, the gateway provides the message identification on behalf of the MES user.

6. If a gateway implementation does not make this element of service available to the MES, then
an alternative method of call tracing should be considered.

2.2 Basic Interpersonal Messaging Service


Elements of Service (EOS) are associated with the various services provided in the MHS. The
realization of these EOS is described in Section 4. The Basic Inmarsat-C IPMS' includes the Basic
Inmarsat-C MTS'. Thus, this section includes classifications of EOS as specified in Section 2.1. The
EOS supported by the Basic Inmarsat-C IPMS' are still a subset of the EOS supported by functional
standard A/3321. A classification scheme in line with X.400 profile A/3321 is used.

The classification of EOS belonging to the terrestrial IPMS is covered by functional profile A/3321.
The following scenario description is used to classify IPMS' Elements of Service.

Figure 8: Scenario Description

IPM GTW MTA IPM


end-system end-system

Scope of this Scope of A/3321


Chapter

The scenario describes two InterPersonal Messaging end-systems (IPM end-systems) engaged in
InterPersonal Messaging via a Message Transfer Agent (MTA) and a Gateway (GTW).

The IPMS in the context of Inmarsat-C interworking with X.400 has different appearances. At the
terrestrial side, the IPMS appears as defined in the base standards and profiles. At the satellite side,
the IPMS appears in a lightweight fashion. The difference manifests itself in the support of different
subsets of EOS, and a different usage of the underlying services. At the terrestrial side of the
gateway, the support of IPM Elements of Service (IPMS) conforms to profile A/3321. At the Inmarsat-
C side of the gateway, the support of IPM Elements of Service (IPMS') conforms to the classification
described. Section 4 pays attention to the difference in appearance as a result of different usage of
the underlying services. Figure 8 illustrates the difference in appearance of the InterPersonal
Messaging Service in the context of Inmarsat-C interworking with X.400. The gateway is the functional
unit concerned with mapping the terrestrial IPM Service onto the Inmarsat-C IPM Service, vice versa.
IPM Service mapping is described in Section 4.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 13
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 9: The Inmarsat-C InterPersonal Messaging Service

IPMS- IPMS- IPMS'- IPMS'-


user user user user

EOS EOS'

Service Inmarsat-C
IPM Service mapping IPM Service

Covered by A/3321 Covered by


Interworking Specification

Each EOS associated with the Basic Inmarsat-C IPMS' will be classified for Origination and
Reception. The class 'Origination' consists of all EOS which may be originated from a Basic Inmarsat-
C InterPersonal Messaging end-system (IPM' end-system). The class 'Reception' consists of all EOS
which may be conveyed to an Inmarsat-C InterPersonal Messaging end-system (IPM' end-system).
The classification for a specific class, e.g. Origination, is independent of the classification for another
class, e.g. Reception. Thus an Element of service can be Mandatory for Origination and still Optional
for Reception.

A clear distinction is retained between EOS and protocol elements necessary to fulfil an Element of
Service. Due to the different usage of the underlying services the gateway has to reformat the
information associated with each element of service supported, either mandatory or optional. Section
4 classifies the protocol elements which needs to be reformatted.

In general, the IPM Service is fully provided by the procedures implemented in the IPM end-systems,
there are no further actions of the gateway required in conjunction with those procedures. However to
reduce the amount of traffic crossing expensive satellite channels the gateway may act on behalf of
the mobile IPM end-system by implementing some of the procedures that provide the Basic Inmarsat-
C IPMS'. For instance, forwarding an InterPersonal Message, originated by a terrestrial IPM end-
system, may be done by the gateway on behalf of the mobile IPM end-system. When a message
originates from a mobile IPM end-system, there is another way to reduce the overhead across the
satellite link. Then both the mobile IPM end-system itself and the gateway have to provide part of the
information associated with an Element of Service. For instance receipt notifications may be
constructed this way. The terrestrial IPM end-system is unaware of the fact that the gateway is
assisting or acting on behalf of the mobile IPM end-system in providing the IPM service. This aspect
of service mapping is probably the most trickiest part of Inmarsat-C interworking with X.400. Therefore
special attention is given in Section 4, at the description of the procedures that have to be
implemented in the mobile IPM end-system and the gateway to provide the Basic Inmarsat-C IPM
Service. Note that this is not of any interest to the Basic Inmarsat-C IPM Service classification, as the
Basic Inmarsat-C IPM Service is not changed by the fact that part of the procedures providing the
Basic Inmarsat-C IPM Service are implemented in the gateway. Moreover, as implementation in the
gateway is not required to fulfil any Element of Service there is no need for a separate class
Implemented for this service classification.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 14
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Category Description
Support for this element or feature depends on a specified
C Conditional
condition.
Support of the element or feature is outside the scope of this
I Out of Scope
document
- For origination (Orig): The Element of Service is logically
impossible or otherwise not applicable in the context of
Inmarsat-C X.400 interworking.
- Not Applicable
- For reception (Rec): The Element of Service is logically
impossible or otherwise not applicable in the context of
Inmarsat-C X.400 interworking.
- For origination (Orig): The gateway will not make this EOS
available to the MES.
N Not Supported
- For reception (Rec): The gateway will not make the
information associated with this EOS available to the MES.
- For origination (Orig): The gateway shall make this EOS
available to the MES.
M Mandatory
- For reception (Rec): The gateway shall make the information
associated with this EOS available to the MES.
- For origination (Orig): The gateway may make this EOS
available to the MES.
O Optional
- For reception (Rec): The gateway may make the information
associated with this EOS available to the MES.

In Table 2, the first two columns apply to profile A/3321. The following columns apply to the Inmarsat-
C IPMS'. The classification of Elements of Service is specified for an IPM end-system on origination
and reception.

Table 2: Inmarsat-C IPMS Classification

IPMS
Service Element IPMS'
(3321)
Number Name Orig Rec Orig Rec
B.5 Authorising users indication O M N M
B.6 Auto-forwarded indication O M N M
B.8 Blind copy recipient indication O M N M
B.9 Body part encryption indication O M N N
B.18 Cross-referencing indication O M N N
B.29 Expiry date indication O M N N
B.31 Forwarded IP-message indication O M N1 M2
B.35 Importance indication O M N N
B.36 Incomplete copy indication O O N M3
B.37 IP-message identification M M M M
B.38 Language indication O M N N
B.46 Multi-part body O M N N4
B.48 Non-receipt notification request indication O M N N
B.52 Obsoleting indication O M N N
B.55 Originator indication M M M M
B.62 Primary and copy recipients indication M M M M

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 15
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

B.67 Receipt notification request indication O O N O


B.72 Reply request indication O M O M5
B.73 Replying IP-message indication M M M M
B.80 Sensitivity indication O M N N
B.88 Subject indication M M M M
B.90 Typed body M M M M

Notes:

1: IPM forwarding will be performed by the gateway on behalf of the mobile IPM-end-system.

2: A forwarded IPM is presented to the mobile IPM-user after unpacking by the gateway. The
base message is presented as a normal IPM containing a header a single body-part. See also note
3.

3: If body-parts are lost due to gateway processing additional information may be inserted by the
gateway indicating the type of body-parts that have been lost provided the transferable body
part is of IA5 encoded type and within other LES system limitation such as message size restriction.

4: From an IPM containing a multi-part body the best effort must be made to deliver as much body
parts as possible, within the constraints of the message format used in the basic service (see
Volume 4). In general the message will be flattened or only the first body part will be delivered.
The Incomplete copy indication is set to indicate the loss of body parts. See also note 3.

5: The reply-time heading field is not supported.

3 Message Transfer System

3.1 Message Transfer System in the Context of Inmarsat-C Interworking with MHS
In this section the Inmarsat-C Message Transfer System is described. The Inmarsat-C Message
Transfer System is based on the selected subset of Message Transfer Service Elements as described
in section 2.1. Sections 3.2 and 3.3 together describe the Inmarsat-C MTS abstract service. Message
identification in the context of Inmarsat-C interworking with X.400 is described in section 3.4. Section
3.5 describes the actions performed by the gateway to map the Inmarsat-C MTS abstract service onto
the terrestrial MTS abstract service of Recommendation X.411. How an Inmarsat-C gateway realizes
the Inmarsat-C abstract service by using the Inmarsat-C Store-and-Forward protocol is described in
Section 3.6. Section 3.7 provides a reference between Inmarsat-C message transfer protocol
elements and its encoding in a human-readable representation.

Recommendation T.330 is one of the CCITT Recommendations dealing with telematic interworking.
Inmarsat-C access to and participating in the Message Transfer System is one of the telematic
interworking applications. This particular telematic interworking application based on the concepts and
description techniques of T.330.

This section provides a functional model of Inmarsat-C access to the Message Transfer System. The
purpose of this functional model is to provide a general description of the functional entities, which are
then explicitly defined using the definitions and conventions of Recommendation X.407. These
conventions provide a descriptive tool for the specification of information processing tasks in abstract
terms. This ensures that the task's functional requirements are stated independently of its realization.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 16
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 10: Functional Model

Inmarsat-C Agent

User MES Gtw MTS MS UA User

AU UA

Access User
Network

This functional model comprises the following functional entities:

• Inmarsat-C Agent (InmCA)

• Inmarsat-C Gateway (InmCGtw)

• Mobile earth station (MES)

• Message transfer system (MTS)

• Message store (MS)

• User agent (UA)

• Access unit (AU)

3.2 Objects and Ports Description


An InmCA helps the mobile Inmarsat-C user (inmc-user) to originate, receive, or both originate and
receive messages containing different types of information objects.

An inmc-user is associated with the InmCA by means of origination and reception ports.

The origination and reception port services and operations are described in detail in Section 3.7. The
origination, and reception port services and operations provided to a mobile user are a subset of the
port services and operations described in Recommendation X.420.

inmc-user OBJECT
PORTS { origination [C],
reception [C]}
::= id-ot-inmc-user

The InmCA provides access to the MTS via ports of two different types: an import port and an export
port.

An import port enables the InmCA to submit messages to the MTS for transfer and delivery to one or
more recipient MTS-users. An export port enables the InmCA to accept messages from the MTS, and
to accept reports on the delivery or non-delivery of messages. Thus an import port is the means by
which the MTS imports messages from the InmCA, whereas an export port is the means by which the
MTS exports messages to the InmCA. The inmc-user is said to be the consumer ([C]) of both port
services provided by the supplier ([S]), InmCA. In turn InmCA is the consumer of the import and
export services provided by the supplier, MTS. For the purpose of this document import and export

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 17
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

port operations will be considered to be similar to terrestrial submission and delivery port operations
as defined in CCITT Recommendation X.411.

inmca OBJECT
PORTS { origination [S],
reception [S],
import [C],
export [C],}
::= id-ot-inmca

The general access to the MTS is illustrated in Figure 12.

Figure 11: General Access to the MTS

(Inmarsat-C Agent) InmCA

origination
InmC- reception import MTS
User export

The InmCA is refined further into secondary objects namely: the mobile terminal (MES) and the
gateway (GTW). The secondary objects interact with one another by means of ports.

inmca-refinement REFINE inmca AS


inmc-gtw
submission [S] PAIRED WITH inmc-mes
delivery [S] PAIRED WITH inmc-mes
import [C] VISIBLE
export [C] VISIBLE
inmc-mes RECURRING
origination [S] VISIBLE
reception [S] VISIBLE
::= id-ref-inmca

The submission and delivery ports enables the interaction of the inmc-mes and the inmc-gtw via the
satellite link.

The secondary-object types inmc-mes and inmc-gtw are defined below.

inmc-mes OBJECT
PORTS { origination [S],
reception [S],
submission [C],
delivery [C]}
::= id-ot-inmc-mes

inmc-gtw OBJECT
PORTS { submission [S],
delivery [S],
import [C],

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 18
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

export [C]}
::= id-ot-inmc-gtw

The refined access model to the MTS is illustrated in Figure 12.

Figure 12: Refined Access Model

(Inmarsat-C Agent) InmCA

(MES) (Gtw)
origination
InmC-
User reception InmC- submission InmC- import MTS
Mes delivery Gtw export

The MessageSubmission abstract operation enables the MES (inmc-mes) to submit a message to the
gateway (inmc-gtw).

submission PORT
CONSUMER INVOKES {MessageSubmission }
::= id-pt-submission

The MessageDelivery abstract operation enables the gateway (inmc-gtw) to deliver a message to the
MES (inmc-mes).

The ReportDelivery abstract operation enables the gateway (inmc-gtw) to deliver a report to the MES
(inmc-mes).

delivery PORT
SUPPLIER INVOKES {MessageDelivery,
ReportDelivery }
::= id-pt-delivery

The MessageSubmission, MessageDelivery and ReportDelivery abstract operations are fully


described in Section 3.3.

3.3 Abstract Operations


In this Section 3 the Inmarsat-C Message Transfer Service is defined. The following abstract
operations are supported by the Inmarsat-C MTS:

1. submission port abstract operations:

a. MessageSubmission

2. delivery port abstract operations:

a. MessageDelivery

b. ReportDelivery

Each abstract operation conveys a number of information elements between the gateway (InmC-Gtw)
and the mobile terminal (InmC-Mes). Information elements are associated with Elements of Service.
In this

section information elements are classified based on the classification of Elements of Service in
Section 2.1. Several dependencies exist as illustrated in Figure 13.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 19
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 13: Dependences between Elements of Service and Associated Information


Element

Origination Reception

elements
of
service
(1) (3)
associated
information
elements
(2)

An arrow "A-(1)->B" depicts that B depends on A in relation (1). Figure 13 shows that the following
dependences and independences exist:

o For elements of service as well as information elements the classification at Origination is


independent from the classification at Reception.

o For elements of service the classification at Reception is independent from the classification at
Origination.

o For information elements the classification at reception is dependent from the classification at
origination, please see note 2.

o For information elements the classification at origination and reception is dependent from the
classification for elements of service at origination and reception respectively, please see note
1 and 3.

Note 1 When an element of service is available at origination either (O)ptional or (M)andatory the
originating side must be able to generate the associated information elements. The classification for
these information elements becomes (C)onditional and (M)andatory respectively. The condition is that
when the (O)ptional element of service is made available the classification for the associated
information elements becomes (M)andatory. In short, (O)-1->(C) where (C) becomes (M) when (O) is
implemented, and (M)-1->(M).

Note 2 When an information element may be generated at origination the reception side must always
be prepared to handle the information element, i.e. the reception side must be able to decode the
information element. In short, (M/O/C)-2->(M). Strictly speaking an information element which is
(O)ptional or (C)onditional for origination should be (C)onditional at reception, (O/C)-2->(C), where (C)
becomes (M) when the information element concerned is generated. However due to the fact that this
classification involves two separate systems and many systems may intercommunicate with many
other systems its very likely or at least uncontrollable that one originator may generate the information
element. All recipients should then be prepared to handle the information element.

Note 3 When an element of service is available at reception either (O)ptional or (M)andatory the
reception side must make the information elements available. The classification for these information
elements becomes (C)onditional and (M)andatory respectively. The condition is that when the
(O)ptional element of service is made available the classification for the associated information
elements becomes (M)andatory. In short, (O)-3->(C) where (C) becomes (M) when (O) is
implemented, and (M)-1->(M). Note that when an information element is available at the reception
side the recipient is not forced to make the element of service available, the classification of the
element of service is independent of the classification of the associated information element.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 20
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 14: Example Classification

Origination Reception

elements
Optional Optional of
service

associated
Conditional Mandatory information
elements

Tables 3 and 4 specify the behaviour of an MES (InmC-Mes) and an GTW (InmC-Gtw) associated
with information elements in processing. The following abbreviations are used in this classification:

Conditional (C): Support of this information element depends on a specified condition.

Out of scope (I): Support of this information element is outside the scope of this document.

Not applicable (-): The information element is logically impossible or otherwise not applicable
in the context of Inmarsat-C message transfer system.

Not supported (N): The gateway or mes is not able to handle the information element. The
information element is ignored by the gateway or mes if presented.

Mandatory (M): The gateway or mes shall handle the information element, i.e. the gateway
and mes are able to encode and decode the information element, the
gateway shall transfer the information element.

Optional (O): The gateway or mes may handle the information element, i.e. the gateway
and mes may be able to encode and decode the information element, the
gateway may transfer the information element. If an information element is
received by the gateway or mes and the necessary procedures to handle
the information element are not implemented the receipt of the information
element results in a protocol error only if the information cannot be
ignored or downgraded.

The classifications in Tables 3 and 4 depict the ability of the InmC-Gtw or InmC-Mes to handle the
information elements on origination and reception. The ASN.1 definitions contained in this section
inherently define the presence of an information element in the protocol. If an ASN.1 definition
contains an OPTIONAL information element, then the information element may be present. If not
OPTIONAL the information element shall be present in the Inmarsat-C protocol. If an information shall
be present the recipient object (InmC-Gtw or InmC-Mes) must be capable of handling the information
element.

3.3.1 MessageSubmission Abstract Operation


Table 3 defines the actions of the Gateway (InmC-Gtw) and MES (InmC-Mes) in relation to the
MessageSubmission abstract operation. The ARGUMENT depicts the abstract information the InmC-
Mes can construct and present (to the InmC-Gtw) on origination and the InmC-Gtw can expect to
receive (from the InmC-MES) and handle the given information. The RESULT definition depicts the
information provided by the performer (MTA) when apprising the invoker (the InmC-Gtw) on the
successful completion of the abstract operation. RESULT is not defined between the InmC-Gtw and

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 21
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

the InmC-Mes. The ERROR definition depicts the information provided by the InmC-Gtw when
apprising the InmC-MES on the failure of the abstract operation.

Figure 15: Depiction of Origination and Reception

Message Inmarsat-C
Submission (import) MessageSubmission

In In
Argument m Argument m
R O C R O C-
M Result - M
T O R G O R E
A Errors t Errors S
O R w O R

Scope of Scope of
A/3311 Table 3.1

Table 3: MessageSubmission Abstract Classification

MTS' MTS'-user
Operation/Element
(InmC-Gtw) (InmC-Mes)
MessageSubmission M O
ARGUMENT
envelope M M
content M M
ERRORS
ElementOfServiceNotSubscribed M M
OriginatorInvalid M M
RecipientImproperlySpecified M M
InconsistentRequest M M

MessageSubmissionEnvelope
PerMessageSubmissionFields M M
per-recipient-fields M M

PerMessageSubmissionFields
originator-name M O1
original-encoded-information-types M O
content-type M O2

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 22
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

content-identifier M O
priority M O
per-message-indicators M O
extensions M O

per-recipient-fields
recipient-name M O
originator-report-request M O
explicit-conversion M O

1. If the InmC-Mes is not able to generate this information element it will be absent in the
Inmarsat- C protocol. In this case an appropriate value will be filled in by the InmC-Gtw based on
information provided by the application of the MTS' (see section 3.7, here being the IPMS' OR-
name).

2. If the InmC-Mes is not able to generate this information element it will be absent in the protocol.
In this case the InmC-Gtw will default to IPM'84 or IPM'88 depending on the analysis of the
specified IPM information elements.

3.3.2 MessageDelivery Abstract Operation


Table 4 defines the actions of the Gateway (InmC-Gtw) and MES (InmC-Mes) in relation to the
MessageDelivery and ReportDelivery abstract operation. The ARGUMENT depicts the abstract
information the InmC-Gtw can present (to the InmC-MES) and the InmC-MES can expect to receive
(from the InmC-Gtw) and handle on reception.

Figure 16: Depiction of Origination and Reception

Message/Report Inmarsat-C
Delivery (export) Message/Report
Delivery
In In
m m
Argument Argument
O R C O R C-
M - M
Result G
T R O E
A t S
Errors w
R O

Scope of Scope of
A/3311 Table 3.2

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 23
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Table 4: Message and Report Delivery Abstract Classification

MTS' MTS'-user
Operation/Element
(InmC-Gtw) (InmC-Mes)
MessageDelivery M
ARGUMENT
MessageDeliveryEnvelope M M
content M M

MessageDeliveryEnvelope
message-delivery-identifier M M
message-delivery-time M M
other-fields M M

other-fields
content-type M M
originator-name M M
original-encoded-information-types M M
priority M M
delivery-flags M M
converted-encoded-information-types M M
message-submission-time M M
content-identifier M M
extensions M M

ReportDelivery M M
ARGUMENT
ReportDeliveryEnvelope M M

ReportDeliveryEnvelope
subject-submission-identifier M M
per-recipient-fields M M

per-recipient-fields
actual-recipient-name M M
report-type M M

report-type
delivery M M
non-delivery M M

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 24
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

non-delivery
non-delivery-reason-code M M
non-delivery-diagnostic-code M M

3.3.3 Inmarsat-C Message Transfer Service Abstract Syntax Definition


Figures 17 to 19 provide a formal specification of the Inmarsat-C Message Transfer Service using the
conventions of the ASN.1 defined in Recommendation X.208 and the abstract service definition
conventions defined in Recommendation X.407.

In Figure 17 (INMC-MTS) the type 'ExtensionAttribute' is specified using an ANY DEFINED BY


construct. ANY may be substituted by one of the different types from Figure 18 (INMC-MTS-
EXTENSIONS). In an instance of communication of an 'ExtensionAttribute' the 'value' component may
be filled with a different type. One of the component types of 'ExtensionAttribute' is an INTEGER
named 'type', which specifies in an instance of communication the type which fills the ANY. Table 5
contains a list which specifies the ASN.1 type (from Figure 18) to be carried by the ANY ('value') for
each permitted value of the INTEGER ('type').

Table 5: ANY DEFINED BY types for ExtensionAttributes

'type' ANY
common-name CommonName
terminal-type TerminalType

For example: if the value of the INTEGER 'type' equals 'common-name' then the value of the 'value'
component is of type 'CommonName'.
In Figure 17 (INMC-MTS) the type 'ExtensionField' is specified using an ANY DEFINED BY construct.
ANY may be substituted by one of the different types from Figure 18 (INMC-MTS-EXTENSIONS). In
an instance of communication of an 'ExtensionAttribute' the 'value' component may be filled with a
different type. One of the component types of 'ExtensionField' is an INTEGER named 'type', which
specifies in an instance of communication the type which fills the ANY. In addition the 'criticality'
component must be set to specific value for some 'ExtensionFields'. Table 6 contains a list which
specifies the ASN.1 type (from Figure 18) to be carried by the ANY ('value') and specifies the value of
the 'criticality' component for each permitted value of the INTEGER ('type').

Table 6: ANY DEFINED BY Types and Criticality for ExtensionFields

'type' ANY 'criticality'


dl-expansion-prohibited DLExpansionProhibited for-delivery
conversion-with-loss-prohibited ConversionWithLoss-Prohibited for-delivery

For example: if the value of the INTEGER 'type' equals 'conversion-with-loss-prohibited' then the
value of the 'value' component is of type 'ConversionWithLossProhibited' and the value of 'criticality' is
set to 'for-delivery'.

Figure 17: INMC-MTS

INMC-MTS -- { iso:org:dod:internet:private:enterprise:inmarsat:inmc-mts }
-- Implementation Note:
-- Certain abstract syntax definitions in this INMC-MTS specification are different
-- to their corresponding definitions in the CCITT MTS specification. These differences
-- have been underlined and they should be checked by the implementation.
-- In particular some definitions are OPTIONAL in the INMC-MTS

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 25
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

-- specification but are mandatory at the X.400 MTA.


--

MTS definitions are highlighted

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

IMPORTS

-- upper bounds

ub-integer-options, ub-content-length, ub-bit-options, ub-recipients, ub-content-id-length,


ub-x121-address-length, ub-reason-codes, ub-diagnostic-codes, ub-extension-types,
ub-built-in-content-type, ub-local-id-length, ub-country-name-numeric-length,
ub-country-name-alpha-length, ub-domain-name-length, ub-terminal-id-length,
ub-organization-name-length, ub-numeric-user-id-length, ub-surname-length,
ub-given-name-length, ub-initials-length, ub-generation-qualifier-length,
ub-organizational-units, ub-organizational-unit-name-length, ub-domain-defined-attributes,
ub-domain-defined-attribute-type-length, ub-domain-defined-attribute-value-length,
ub-built-in-encoded-information-types, ub-encoded-information-types

FROM INMC-MTS-UB;

-- Submission port abstract operations

MessageSubmission ::= ABSTRACT-OPERATION


ARGUMENT SEQUENCE {
envelope MessageSubmissionEnvelope,
content Content }
RESULT SET {
message-submission-identifier MessageSubmissionIdentifier }
ERRORS {
ElementOfServiceNotSubscribed,
OriginatorInvalid,
RecipientImproperlySpecified,
InconsistentRequest }
::= 3

-- Submission port parameters

MessageSubmissionIdentifier ::= MTSIdentifier

MessageSubmissionTime ::= Time

-- Delivery port abstract operations

MessageDelivery ::= ABSTRACT-OPERATION


ARGUMENT SEQUENCE {
COMPONENTS OF MessageDeliveryEnvelope,
content Content }
::= 5

ReportDelivery :: = ABSTRACT-OPERATION
ARGUMENT SET {
COMPONENTS OF ReportDeliveryEnvelope }
::= 6

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 26
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

-- Delivery port parameters

-- Message submssion envelope

MessageSubmissionEnvelope ::= SET {


COMPONENTS OF PerMessageSubmissionFields,
per-recipient-fields [1] SEQUENCE SIZE (1..ub-recipients) OF
PerRecipientMessageSubmissionFields DEFAULT { } }
-- if content-type is interpersonal-messaging-19xx
-- a per-recipient-field may not be present, in this case
-- recipient information should be derived from the ipm heading

PerMessageSubmissionFields ::= SET {


originator-name OriginatorName OPTIONAL,
original-encoded-information-types OriginalEncodedlnformationTypes
DEFAULT built-in-encoded-information-types { ia5-text },
content-type ContentType DEFAULT built-in interpersonal-messaging-1988,
content-identifier ContentIdentifier OPTIONAL,
priority Priority DEFAULT normal,
per-message-indicators PerMessageIndicators DEFAULT { }
extensions [2] PerMessageSubmissionExtensions DEFAULT { } }

PerRecipientMessageSubmissionFields ::= SET {


recipient-name RecipientName,
originator-report-request [0] OriginatorReportRequest OPTIONAL,
explicit-conversion [1] ExplicitConversion OPTIONAL }

PerMessageSubmissionExtensions ::= Extensions

-- Message delivery envelope

MessageDeliveryEnvelope ::= SEQUENCE {


message-delivery-identifier MessageDeliveryIdentifier OPTIONAL,
message-delivery-time MessageDeliveryTime,
other-fields OtherMessageDeliveryFields }

OtherMessageDeliveryFields ::= SET {


content-type DeliveredContentType OPTIONAL,
originator-name OriginatorName,
original-encoded-information-types [1] OriginalEncodedlnformationTypes OPTIONAL,
priority Priority DEFAULT normal,
delivery-flags [2] DeliveryFlags OPTIONAL,
converted-encoded-information-types [6] ConvertedEncodedlnformationTypes
OPTIONAL,
message-submission-time [7] MessageSubmissionTime,
content-identifier [8] ContentIdentifier OPTIONAL
extensions [9] Extensions DEFAULT { } }

-- Report delivery envelope

ReportDeliveryEnvelope ::= SET{


subject-submission-identifier SubjectSubmissionIdentifier,
per-recipient-fields SEQUENCE SIZE (1..ub-recipients) OF
PerRecipientReportDeliveryFields }

PerRecipientReportDeliveryFields ::= SET{


actual-recipient-name [O] ActualRecipientName,
report-type [1] ReportType }

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 27
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ReportType ::= CHOICE{


delivery [0] DeliveryReport,
non-delivery [1] NonDeliveryReport }

DeliveryReport ::= NULL

NonDeliveryReport ::= SET{


non-delivery-reason-code [0] NonDeliveryReasonCode,
non-delivery-diagnostic-code [1] NonDeliveryDiagnosticCode OPTIONAL }

NonDeliveryReasonCode ::= INTEGER {


transfer-failure (0),
unable-to-transfer (1),
conversion-not-performed (2),
physical-rendition-not-performed (3],
physical-delivery-not-performed (4],
restricted-delivery (5),
directory-operation-unsuccessful (6) } (0..ub-reason-codes)

NonDeliveryDiagnosticCode ::= INTEGER {


unrecognised-OR-name (0),
ambiguous-OR-name (1),
mts-congestion (2),
loop-detected (3),
recipient-unavailable (4),
maximum-time-expired (5),
encoded-information-types-unsupported (6),
content-too-long (7),
conversion-impratical (8),
implicit-conversion-prohibited (9),
implicit-conversion-not-subscribed (10),
invalid-arguments (11),
content-syntax-error (12),
size-constraint-violation (13),
protocol-violation (14),
content-type-not-supported (15),
too-many-recipients (16),
no-bilateral-agreement (17),
unsupported-critical-function (18),
conversion-with -loss-prohibited (19),
line-too-long (20),
page-split (21),
pictorial-symbol-loss (22),
punctuation-symbol-loss (23),
alphabetic-character-loss (24),
multiple-information-loss (25),
recipient-reassignment-prohibited (26),
redirection-loop-detected (27],
dL-expansion-prohibited (28),
no-DL-submit-permission (29),
dl-expansion-failure (30),
physical-rendition-attributes-not-supported (31),
undeliverable-mail-physical-delivery-address-incorrect (32),
undeliverable-mail-physical-delivery-office-incorrect-or-invalid (33),
undeliverable-mail-physical-delivery-address-incomplete (34),
undeliverable-mail-recipient-unknown (35),
undeliverable-mail-recipient-deceased (36),
undeliverable-mail-organization-expired (37),
undeliverable-mail-recipient-refused-to-accept (38),
undeliverable-mail-recipient-did-not-claim (39],
undeliverable-mail-recipient-changed-address-permanently (40),
undeliverable-mail-recipient-changed-address-temporarily (41),

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 28
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

undeliverable-mail-recipient-changed-temporary-address (42),
undeliverable-mail-new-address-unknown (43),
undeliverable-mail-recipient-did-not-want-forwarding (44),
undeliverable-mail-originator-prohibited-forwarding (45),
secure-messaging-error (46),
unable-to-downgrade (47) } (0..ub-diagnostic-codes)

-- Envelope fields

OriginatorName ::= ORAddress

OriginalEncodedInformationTypes ::= EncodedInformationTypes

-- Should really be a CHOICE

ContentType ::= CHOICE {


built-in BuiltInContentType,
external ExternalContentType }

BuiltInContentType ::= [APPLICATION 6] INTEGER {


unidentified (0),
external (1), -- identified by the object-identifier of the EXTERNAL content
interpersonal-messaging-1984 (2),
interpersonal-messaging-1988 (22) } (0..ub-built-in-content-type)

ExternalContentType ::= OBJECT IDENTIFIER

DeliveredContentType ::= CHOICE {


built-in [0] BuiltInContentType,
external ExternalContentType
}

ContentIdentifier ::= [APPLICATION 10] PrintableString (SIZE (1..ub-content-id-length))

PerMessageIndicators ::= [APPLICATION 8] BIT STRING {


implicit-conversion-prohibited (1) -- implicit-conversion-prohibited 'one',
-- implicit-conversion-allowed 'zero'.-- }
(SIZE (0..ub-bit-options))

RecipientName ::= ORAddress

OriginatorReportRequest ::= BIT STRING {


report (3),
non-delivery-report (4)
-- at most one bit shall be 'one':
-- report bit 'one' requests a 'report';
-- non-delivery-report bit 'one' requests a 'non-delivery-report';
-- both bits 'zero' requests 'no-report' -- } (SIZE (0..ub-bit-options))

ExplicitConversion ::= INTEGER {


ia5-text-to-teletex (0),
teletex-to-telex (1),
telex-to-ia5-text (2),
telex-to-teletex (3),
telex-to-g4-class-1 (4),
telex-to-videotex (5),
ia5-text-to-telex (6),
telex-to-g3-facsimile (7),
ia5-text-to-g3-facsimile (8),
ia5-text-to-g4-class-1 (9),
ia5-text-to-videotex (10),
teletex-to-ia5-text (11),
teletex-to-g3-facsimile (12),
teletex-to-g4-class-1 (13),

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 29
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

teletex-to-videotex (14),
videotex-to-telex (15),
videotex-to-ia5-text (16),
videotex-to-teletex (17) } (0..ub-integer-options)

Priority ::= [APPLICATION 7] ENUMERATED {


normal (0),
non-urgent (1),
urgent (2) }

MessageDeliveryIdentifier ::= MTSIdentifier

MessageDeliveryTime ::= Time

DeliveryFlags ::= BIT STRING {


implicit-conversion-prohibited (1) -- implicit-conversion-prohibited 'one',
-- implicit-conversion-allowed 'zero' -- }
(SIZE (0..ub-bit-options))

ConvertedEncodedInformationTypes ::= EncodedInformationTypes

SubjectSubmissionIdentifier ::= MTSIdentifier

ActualRecipientName ::= ORAddress

-- Extension fields

ExtensionField :: = SEQUENCE {
type [0] ExtensionType,
criticality [1] Criticality DEFAULT { },
value [2] ANY DEFINED BY type DEFAULT NULL }

ExtensionType ::= INTEGER ( 0 .. ub-extension-types )

Criticality ::= BIT STRING {


for-submission (0),
for-transfer (1),
for-delivery (2) } ( SIZE (0..ub-bit-options ) ) -- critical 'one', non-critical 'zero'

Extensions ::= SET OF ExtensionField

-- Common parameter types

Content ::= OCTET STRING ( SIZE (0..ub-content-length ) )


-- when the content-type has the integer value external, the value of the content
-- OCTET STRING is the ASN.1 encoding of the external-content; an external-
-- content is a data type EXTERNAL whose ASN.1 definition is outside the
-- scope of this document. For the purpose of encoding the same rules apply
-- as for the encoding of an OCTET STRING.

MTSIdentifier ::= [APPLICATION 4] SEQUENCE {


global-domain-identifier GlobalDomainIdentifier OPTIONAL,
-- only present in delivered messages, otherwise not-present
local-identifier LocalIdentifier }

LocalIdentifier ::= IA5String (SIZE (1..ub-local-id-length))

GlobalDomainIdentifier ::= [APPLICATION 3] SEQUENCE {


country-name CountryName,
administration-domain-name AdministrationDomainName,
private-domain-identifier PrivateDomainIdentifier OPTIONAL }

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 30
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

PrivateDomainIdentifier ::= CHOICE {


numeric NumericString (SIZE (1..ub-domain-name-length)),
printable PrintableString (SIZE (1..ub-domain-name-length)) }

Time ::= UTCTime

-- O/R names

ORAddress ::= ORName

ORName ::= [APPLICATION 0] SEQUENCE {


standard-attributes StandardAttributes,
domain-defined DomainDefinedAttributes OPTIONAL,
-- see also teletex-domain-defined-attributes
extension-attributes ExtensionAttributes OPTIONAL }

-- Note: the OR-address is semantically absent from the OR-name if the


-- standard-attribute sequence is empty and the domain-defined-attributes
-- and extension-attributes are both omitted.

-- Standard Attributes

StandardAttributes ::= SEQUENCE {


country-name CountryName OPTIONAL,
administration-domain-name AdministrationDomainName OPTIONAL,
network-address [0] NetworkAddress OPTIONAL,
-- see also extended-network-address
terminal-identifier [1] TerminalIdentifier OPTIONAL,
private-domain-name [2] EXPLICIT PrivateDomainName OPTIONAL,
organization-name [3] OrganizationName OPTIONAL,
-- see also teletex-organization-name
numeric-user-identifier [4] NumericUserIdentifier OPTIONAL,
personal-name [5] PersonalName OPTIONAL,
organizational-unit-names [6] OrganizationalUnitNames OPTIONAL
-- see also teletex-organizational-unit-names -- }

CountryName ::= [APPLICATION 1] EXPLICIT CHOICE {


x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)),
iso-3166-alpha2-code PrintableString (SIZE (ub-country-name-alpha-length))
}

AdministrationDomainName ::= [APPLICATION 2] EXPLICIT CHOICE {


numeric NumericString (SIZE (0..ub-domain-name-length)),
printable PrintableString (SIZE (0..ub-domain-name-length))
}

NetworkAddress ::= X121Address

X121Address ::= NumericString (SIZE (1..ub-x121-address-length))

TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length))

PrivateDomainName ::= CHOICE {


numeric NumericString (SIZE (1..ub-domain-name-length)),
printable PrintableString (SIZE (1..ub-domain-name-length))
}

OrganizationName ::= PrintableString (SIZE (1..ub-organization-name-length))

NumericUserIdentifier ::= NumericString (SIZE (1..ub-numeric-user-id-length))

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 31
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

PersonalName ::= SET {


surname [0] PrintableString (SIZE (1..ub-surname-length)),
given-name [1] PrintableString (SIZE (1..ub-given-name-length)) OPTIONAL,
initials [2] PrintableString (SIZE (1..ub-initials-length)) OPTIONAL,
generation-qualifier [3] PrintableString (SIZE (1..ub-generation-qualifier-length)) OPTIONAL }

OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) OF OrganizationUnitName

OrganizationUnitName ::= PrintableString (SIZE (1..ub-organizational-unit-name-length))

-- Domain-defined Attributes

DomainDefinedAttributes ::= SEQUENCE SIZE (1..ub-domain-defined-attributes) OF


DomainDefinedAttribute

DomainDefinedAttribute ::= SEQUENCE {


type PrintableString (SIZE (1..ub-domain-defined-attribute-type-length)),
value PrintableString (SIZE (1..ub-domain-defined-attribute-value-length)) }

-- Extension attributes

ExtensionAttribute ::= SEQUENCE {


type [0] INTEGER,
value [1] ANY DEFINED BY type }

ExtensionAttributes ::= SET OF ExtensionAttribute

-- Encoded Information Types

EncodedInformationTypes ::= [APPLICATION 5] SET {


built-in-encoded-information-types [0] BuiltInEncodedInformationTypes,
external-encoded-information-types [4] ExternalEncodedInformationTypes OPTIONAL }

-- Built-in Encoded Information Types

BuiltInEncodedInformationTypes ::= BIT STRING {


undefined (0),
telex (1),
ia5-text (2),
g3-facsimile (3),
g4-class-1 (4),
teletex (5),
videotex (6),
voice (7),
sfd (8),
mixed-mode (9) } (SIZE (0..ub-built-in-encoded-information-types))

-- External Encoded Information Types

ExternalEncodedInformationTypes ::= SET SIZE (1..ub-encoded-information-types) OF


ExternalEncodedInformationType

ExternalEncodedInformationType ::= OBJECT IDENTIFIER

END -- of Message transfer service

Figure 18: INMC-MTS-Extensions

INMC-MTS-EXTENSIONS -- { iso:org:dod:internet:private:enterprise:inmarsat:inmc-mts-extensions }

DEFINITIONS IMPLICIT TAGS ::=

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 32
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

BEGIN

IMPORTS

-- upper bounds

ub-common-name-length, ub-integer-options
FROM INMC-MTS-UB;

-- Extensions
-- DLExpansionProhibited extension
-- DEFAULT conversion-with-loss-allowed
-- CRITICAL FOR DELIVERY

DLExpansionProhibited ::= ENUMERATED {


dl-expansion-allowed (0),
dl-expansion-prohibited (1) }

dl-expansion-prohibited INTEGER ::= 3

-- ConversionWithLossProhibited extension
-- DEFAULT conversion-with-loss-allowed
-- CRITICAL FOR DELIVERY

ConversionWithLossProhibited ::= ENUMERATED {


conversion-with-loss-allowed (0),
conversion-with-loss-prohibited (1) }

conversion-with-loss-prohibited INTEGER ::= 4

-- Extension attributes

CommonName ::= PrintableString ( SIZE ( 1 .. ub-common-name-length ) )

common-name INTEGER ::= 1

TerminalType ::= INTEGER {


telex (3),
teletex (4),
g3-facsimile (5),
g4-facsimile (6),
ia5-terminal (7),
videotex (8) } ( 0 .. ub-integer-options )

terminal-type INTEGER ::= 23

END -- of Extensions and Extension attributes

Figure 19: INMC-MTS-UB

INMC-MTS-UB -- { iso:org:dod:internet:private:enterprise:inmarsat:inmc-mts-ub }

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

IMPORTS -- nothing -- ;

-- Upper bounds

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 33
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ub-integer-options INTEGER ::= 256

ub-content-length INTEGER ::= 2147483647 -- the largest integer in 32 bits

ub-bit-options INTEGER ::= 16

ub-recipients INTEGER ::= 32767

ub-content-id-length INTEGER ::= 16

ub-x121-address-length INTEGER ::= 15

ub-reason-codes INTEGER ::= 32767

ub-diagnostic-codes INTEGER ::= 32767

ub-extension-types INTEGER ::= 256

ub-built-in-content-type INTEGER ::= 32767

ub-local-id-length INTEGER ::= 32

ub-country-name-numeric-length INTEGER ::= 3

ub-country-name-alpha-length INTEGER ::= 2

ub-domain-name-length INTEGER ::= 16

ub-terminal-id-length INTEGER ::= 24

ub-organization-name-length INTEGER ::= 64

ub-numeric-user-id-length INTEGER ::= 32

ub-surname-length INTEGER ::= 40

ub-given-name-length INTEGER ::= 16

ub-initials-length INTEGER ::= 5

ub-generation-qualifier-length INTEGER ::= 3

ub-organizational-units INTEGER ::= 4

ub-organizational-unit-name-length INTEGER ::= 32

ub-domain-defined-attributes INTEGER ::= 4

ub-domain-defined-attribute-type-length INTEGER ::= 8

ub-domain-defined-attribute-value-length INTEGER ::= 128

ub-common-name-length INTEGER ::= 64

ub-built-in-encoded-information-types INTEGER ::= 32

ub-encoded-information-types INTEGER ::= 1024

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 34
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

END -- of upper bounds

3.4 Message Identification


The Message Transfer System allocates identifiers for each message submitted to the MTS
(message-submission-identifier), transferred by the MTS (message-identifier), or delivered by the
MTS (message-delivery-identifier). For each message submitted a message-identifier shall be
generated, as a default, by the originating MTA, and shall have the same value as the message-
submission-identifier supplied to the originator of the message when the message was submitted, and
the message-delivery-identifier supplied to the recipient of the message when the message is
delivered. A message-identifier distinguishes a message from all other messages or reports within the
Message Transfer System. When a message is copied for routing to multiple recipients via different
MTAs, each copy of the message bears the same message-identifier of the original.

Within the Inmarsat-C system each LES is responsible for the assignment of a message reference
number to each message originating from a mobile terminal served by that particular LES. The
message reference number is unique within the scope of the responsible LES. Its uniqueness persists
until there is no chance (from the LES point of view) that the message can be referred to again. Within
the Inmarsat-C system each LES is also responsible for the assignment of a message reference
number to each message originating from a terrestrial subscriber and destined for a mobile terminal
served by that particular LES. The assigned message reference number will not be re-used until the
message is delivered to the mobile terminal or is considered undeliverable.

A message-identifier will be used by the MTS to refer to a previously submitted message in (non)-
delivery notifications. For the purpose of delivery of a (non)-delivery-notification the MTS needs only
to be able to correlate a message-identifier with a previously assigned message-submission-identifier.
The value of the message-delivery-identifier is never used by the MTS itself, but it may be used in the
contents of a message to refer to a previously received message. The usage of message-identifiers in
the message-contents is outside the scope of the MTS. However, there are two conditions for the
gateway with respect to the usage of a message-identifier value in the contents of a message
originating from, or destined to a mobile terminal.

o The gateway must offer an efficient service to all users. Therefore the Inmarsat-C Channels
and Signals must be used as efficiently as possible.

o The gateway must offer a consistent service to all users. Message-identifiers must be non-
ambiguous. Therefore it's important that the message-submission-identifier and the message-
delivery-identifier have the same value. This enables the InmC-Gtw to be able to correlate
delivery reports with the messages submitted by the InmC-Users to the MTS and to generate
delivery reports to the terrestrial originators.

3.4.1 From-Mobile Message Identification


For messages originating from a mobile terminal destined for a terrestrial user-agent a message
reference number is assigned by the LES, and shall have the same value as the message-
submission-identifier supplied to the originator of the message when the message was submitted
(conveyed in a 'clear' packet on the LES TDM channel). The InmC-Gtw shall provide a message-
identifier to the originating MTA for assignment, and shall have the same value as the message-
delivery-identifier supplied to the recipient of the message when the message is delivered. This
message identifier shall include the LES reference number and shall be of the format:

<IM><3 Digit LES id><UTC date time string><LES assigned Reference number>

In the event that the message has been accepted by the MTA, no notification is returned by the Inmc-
Gtw; this is to avoid the notification being treated by the MES as a successful delivery notification at
the destination. Otherwise a non-delivery notification specifying the submission error is returned. The
UTC date time string is of the form YYMMDDHHMM; e.g. 9312251200 for noon on 12th. December
1993.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 35
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The standard message-submission-identifier, containing the LES reference number, shall enable the
InmC-Mes to correlate the delivery reports with the messages submitted.

Figure 20: Message Identification

Message- Message-
Submission Transfer
LES MTA
ARGUMENT ARGUMEN{
{ ..... .....
.....} .....
MTA msg-id=mts-
assignments-id id+msg-ref
.....
Message- }
Submission
RESULT { LES
msg-ref assigned
} msg-ref

The Message Transfer System refers to a previously submitted message in (one or more) (non)-
delivery-notification messages. A report received on the MTA's transfer-port is converted into a (non)-
delivery-notification message. The message-submission-identifier contained in the (non)-delivery-
notification shall have the same value as the MTA assigned message-identifier of the previously
submitted message who's delivery is being reported. The non-delivery notification realization is
described in Section 3.7.2 A (non)-delivery-notification which can not be delivered is discarded, see
also Figure 21.

Figure 21: (Non)-Delivery of (Non)-Delivery-Notifications

MES LES (Non-) MTA


(Non-) delivery-
delivery notification
message report

(3) (2) (1)


discard discard

3.4.2 To-Mobile Message Identification


For messages originating from a terrestrial user-agent destined for a mobile terminal a message-
identifier is assigned by the originating MTA, and shall have the same value as the message-
submission-identifier supplied to the originator of the message when the message was submitted, and
the message-delivery-identifier supplied to the recipient of the message when the message is
delivered. The message-delivery-identifier may be conveyed by the InmC-Gtw to the InmC-MES as
defined in the ARGUMENT definition of the Message Delivery abstract operation.

This mechanism enables the use of the same message-identifier value at terrestrial origination and
mobile reception. With this alternative the message-delivery-identifier value may be contained in the

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 36
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

data-part of the 'message' packet which is to be delivered to the mobile terminal. Note that the data-
part of the 'message' packet may contain the text of the actual message, amongst other values.

In addition, the message reference number assigned by the LES responsible for the delivery of the
message (conveyed in the 'announcement' packet on the NCS Common Channel, advised by the LES
in the 'status request + announcement' packet on the ISL) is still available. The presentation and
visibility of this LES assigned reference number is a local implementation of the DTE.

3.4.3 Mobile-To-Mobile Message Identification


The combination of both identifier schemes allows for multiple-crossing a gateway. For messages
originating from a mobile terminal destined for a mobile terminal a message reference number is
assigned by the LES, and shall have the same value as the message-submission-identifier supplied
to the originator of the message when the message is submitted. Following the assignment of a
message reference number by the LES a message-identifier is assigned by the originating MTA. The
assigned message-identifier value shall contain the value of the message-reference number (amongst
other values), and shall have the same value as the message-delivery-identifier supplied to the
recipient of the message when the message is delivered.

3.5 Procedure Description


In section 3.1 the message transfer service in the context of interworking with Inmarsat-C is
described. The message transfer service has different appearances. At the terrestrial side the
message transfer service appears as defined in the base standards and profiles. At the satellite side
the message transfer service appears in a lightweight fashion. The gateway is the functional unit
concerned with service mapping. This section describes the procedures performed by the gateway to
map the terrestrial message transfer service onto the Inmarsat-C MT service, vice versa.

The terrestrial and Inmarsat-C abstract services are described in terms of abstract ports, and
operations. Service mapping is a matter of linking together the abstract ports and operations of the
two separate abstract services, see Figure 22. How each abstract port, and operation is realized
using the underlying service is another issue. The fact that abstract operations actually could be
invoked via ROSE is immaterial in the context of this document. The usage of the ROSE, RTSE, and
services of the Presentation layer in realizing the terrestrial MT abstract service is described in
recommendation X.419. The usage of Inmarsat-C Channels and Signals in realizing the Inmarsat-C
MT abstract service is described in section 3.6.

Figure 22: Scope of this Section

GTW

Submission (import)
li nk age

submission
Delivery (export)
delivery

Scope of
Scope of section 3.5 Scope of
Section 3.6 X.419

In order to link the various abstract ports and operations a gateway must perform certain processing
on each message or report that enters it. The procedures described focus on the processing of a

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 37
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

single message in the Message Transfer System for other purposes than transferring a Interpersonal
Message (i.e. the message content is not interpersonal-messaging-1984 nor interpersonal-
messaging-1988). In case the message content is interpersonal-messaging-1984 or interpersonal-
messaging-1988) the employment of the Message Transfer System is slightly different. The
realization of the InterPersonal Messaging System and the usage of the Message Transfer System is
described in Section 4.

This paragraph identifies the following mapping procedures:

1. Direct mapping of information elements with no loss of information

2. Direct mapping of information elements with possible loss of information due to different
character-sets used in the originating and receiving mail system.

3. Mapping of information elements using cross-reference tables or algorithmic rules. Partial


information is derived from values generated by the originating mail system. This partial
information is used either as a key pointing to a table entry or as a parameter in an algorithm.

4. Default values are used to generate this information element or values are generated based on
information pertinent to the particular transmission session.

5. Optional or 'missing' element in receiving mail system, therefore not generated by the gateway.

Rules 1-3 are applicable for information elements which are generated in the originating mail system,
i.e. are present in a particular instance of communication. Whereas rules 4-5 apply to information
elements which are not generated in the originating mail system, i.e. are not present in a particular
instance of communication, but are Mandatory/Optional in the receiving mail system, i.e. must or may
be present in the receiving mail system. therefore rules 1-3 and rules 4-5 belong to different classes
characterised by the presence of an information element in the originating mail system. If rules of
different classes are applicable for a particular information element, then which rule to follow depends
on the presence of the particular information element in an instance of communication. If present rule
1, 2 or 3 is applied, if not present rule 4 or 5 is applied.

Tables 7 through 9 describe how the above mentioned mapping procedures are employed for the
MessageSubmission, MessaDelivery and ReportDelivery operation.

3.5.1 Processing of the MessageSubmission Operation


This paragraph describes the behaviour of the Gateway when the Inmarsat-C MessageSubmission
operation is invoked by the MES on the Gateway's Submission port.

The invocation of this operation will trigger the MT-service mapping procedures of the gateway. These
procedures perform the mapping of the Inmarsat-C MessageSubmission operation onto the terrestrial
X.400 MessageSubmission operation. After a successful mapping of the MessageSubmission
operation ARGUMENT the Gateway will invoke the X.400 MessageSubmission operation on the
MTA's Submission (Import) port. On completion of the MTA's MessageSubmission operation the
gateway will map the ERRORS onto the Inmarsat-C MessageSubmission ERRORS.

Table 7 shows the detailed mapping of the Inmarsat-C MessageSubmission information elements
onto the terrestrial X.400 MessageSubmission information elements.

Table 7: MessageSubmission Abstract Handling Summary

Operation/Element if present if not present

MessageSubmission
ARGUMENT

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 38
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

originator-name 1 4
original-encoded-information-types 1 4
content-type 1 4
content-identifier 1 5
priority 1 4
per-message-indicators
implicit-conversion-prohibited 1 5
extensions
dl-expansion-prohibited 1 5
conversion-with-loss-prohibited 1 5
per-recipient-fields
recipient-name 1 -1
originator-report-request 1 4
explicit-conversion 1 5
ERRORS
ElementOfServiceNotSubscribed 1 -
OriginatorInvalid 1 -
RecipientImproperlySpecified 1 -
InconsistentRequest 1 -

1 Recipient-name must be present if content-type is something else than ipm.

3.5.2 Processing of the MessageDelivery Operation


This paragraph describes the behaviour of the Gateway when the X.400 MessageDelivery operation
is invoked by the MTA on the Gateway's Delivery port.

The receipt of this operation will trigger the MT-service mapping procedure of the Gateway. These
procedures perform the mapping of the X.400 MessageDelivery operation ARGUMENT onto the
Inmarsat-C MessageDelivery operation ARGUMENT. After a successful mapping the Gateway will
invoke the Inmarsat-C MessageDelivery operation on the Gateway's Delivery (Export) port.

Table 8 shows the mapping of the X.400 MessageDelivery protocol elements on the Inmarsat-C
MessageDelivery protocol elements.

Table 8: Message Delivery Abstract Handling Summary

Operation/Element if present if not present

MessageDelivery
ARGUMENT
message-delivery-identifier 3 -
message-delivery-time 1 -
content-type 1 5
originator-name 1 -
original-encoded-information-types 1 5

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 39
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

priority 1 4
delivery-flags 1 5
implicit-conversion-prohibited 1 5
converted-encoded-information-types 1 5
message-submission-time 1 -
content-identifier 1 5
extensions 1 4
dl-expansion-prohibited 1 4
conversion-with-loss-prohibited 1 4
content 2 5

The MTA is responsible for sending a (non)-delivery-notification to the originator of the message.
However the decision when to send a (non)-delivery-notification can only be made by the Gateway
(advised by the LES). Hence the Gateway stipulates the sending of (non)-delivery-notifications by the
MTA . A confirmation of message delivery is stipulated by the Gateway on delivery to the MES,
following the final 'acknowledgement' from the MES in the context of a To-Mobile call procedure (see
section 3.6). A confirmation of non-delivery may be stipulated by the Gateway when the LES
determines the MES is not logged into the ocean region. If a logged-in MES does not respond to an
'announcement', the LES may make further attempts to send the stored message to the MES within a
certain time period. A confirmation of non-delivery is stipulated by the Gateway when the message
cannot be delivered within the overall retry period.

3.5.3 Processing of the Report Delivery Operation


This paragraph describes the behaviour of the Gateway when the X.400 ReportDelivery operation is
invoked by the MTA on the Gateway's Delivery port.

The receipt of this operation will trigger the MT-service mapping procedure of the Gateway. These
procedures perform the mapping of the X.400 ReportDelivery operation ARGUMENT onto the
Inmarsat-C ReportDelivery operation ARGUMENT. After a successful mapping the Gateway will
invoke the Inmarsat-C ReportDelivery operation on the Gateway's Delivery (Export) port.

Table 9 shows the mapping of the X.400 ReportDelivery protocol elements on the Inmarsat-C
ReportDelivery protocol elements.

Table 9: Report Delivery Abstract Handling Summary

Operation/Element if present if not present

ReportDelivery
ARGUMENT
subject-submission-identifier 1 -
per-recipient-fields 1 -
actual-recipient-name 1 -
report-type 1 -
delivery 1 -
non-delivery 1 -

non-delivery

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 40
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

non-delivery-reason-code 1 -
non-delivery-diagnostic-code 1 5

3.5.4 MTS-Bind and MTS-UnBind


Before the gateway and MTA can invoke operations on one another, they must be bound into an
abstract association. The binding of an association establishes a relationship between the gateway
and MTA which lasts until the association is released. The MTS-bind enables either the gateway or
MTA to establish an association between them. The MTS-unbind enables the release of an
established association. An established association can only be released by the initiator of the
association. The MTS-bind ARGUMENTs and RESULTs for the purpose of the establishment of an
association between gateway and MTA is a local implementation issue. The MTS-unbind returns an
empty RESULT as indication of release of the association. For the description of procedures
performed by the gateway an association with an MTA is assumed.

3.6 Realization of Abstract Operations


How the terrestrial Message Transfer System concretely realizes the ports it supplies is specified in
Recommendation X.419. How an InmC-Gtw realizes the Submission and Delivery ports by means of
which it interacts with an InmC-Mes via the satellite link is specified in Section 3 and sub-sections.

Section 3.3 describes the abstract operations provided at the abstract ports supplied by the Inmarsat-
C Message Transfer System. The realization of an abstract port can be thought of as the collection of
procedures realizing the abstract operations provided by the abstract port. Abstract operations are
realized via the exchange of Inmarsat-C Application Protocol Data Units (IAPDUs) between the
Gateway (InmC-Gtw) and the MES (InmC-Mes) using the Inmarsat-C Store-and-Forward protocol.
Abstract information elements contained in abstract operations ARGUMENTs, RESULTs, and
ERRORS are realized by means of protocol elements contained in IAPDUs. The relationship between
abstract operations ARGUMENTs, RESULTs, ERRORS and associated IAPDUs are summarized in
Table 10. For each abstract information element there is a corresponding protocol element. The
encoding of protocol elements and the exact mapping with abstract information elements is described
in Section 3.7.

Table 10: Summary of IAPDUs

submission port MTS' MTS'-user


IAPDU name
abstract operation (InmC-Gtw) (InmC-Mes)
MessageSubmission (I)Submit-IAPDU M O
(E)SubmitError-IAPDU M C(1)

delivery port MTS' MTS'-user


IAPDU name
abstract operation (InmC-Gtw) (InmC-Mes)
MessageDelivery (I)Deliver-IAPDU M M
ReportDelivery (I)Report-IAPDU M M

In Table 10 (I) indicates an IAPDU which is generated on invocation of an operation, it contains the
protocol elements associated with the ARGUMENT argument of the associated operation. If an
operation was successfully performed, no reply is necessary since the LES reference number
supplied in the clear packet, at message submission time, is part of the message-submission-
identifier. An (E)rror IAPDU indicates cause of operation failure.

The concept of IAPDUs is used for two reasons.

o to de-couple the transfer and encoding of protocol elements from the abstract information
elements described in Section 3.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 41
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

o to group protocol elements which are logically related, but are transferred in separate Inmarsat-
C 'packets'.

Figure 23 shows the steps to define the Inmarsat-C Message Transfer System protocols. The main
objects are defined in Section 3.2 using an OBJECT macro. The entry points, or ports, to or from an
object are defined in a PORT macro. A port offers a number of operations which can be executed.
They are defined in section 3.3 using ABSTRACT-OPERATION macros. These steps are used to
explain the functionality of the system in a top down manner. The next steps are to start constructing
the components of the protocol in a bottom-up manner. Abstract ARGUMENTs, and ERRORS now
become IAPDUs and abstract operations become Inmarsat-C call procedures. The LES resources
used to control a call procedure represent the abstract ports and objects.

Figure 23: The Steps to Define the Inmarsat-C Message Transfer System Protocols

Abstract All LES


Objects resources used
by a terrestrial
Access Unit to
Abstract control a call
Ports procedure

Abstract Call
Operations Procedures

Abstract
ARGUMENTs (I)IAPDUs

Abstract
ERRORS (E)IAPDUs

The Inmarsat-C System employs different call procedures for From-Mobile and To-Mobile 'message'
transfer. A call procedure involves the exchange of Inmarsat-C 'packets' via different 'channels'.
During the lifetime of a call procedure 'channels' exist between LES and MES, LES and NCS, and
NCS and MES. The gateway can be thought of as comprising the following Inmarsat-C system
resources:

o the LES,

o resources of the NCS assigned to communicate with the LES,

o resources of the NCS assigned to communicate with a MES.

This way IAPDUs can be considered to be transferred between gateway and MES, whilst conveyed
by 'packets' exchanged between LES, NCS, and MES.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 42
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 24: Employment of the Inmarsat-C Channels and Signals by the Gateway

NCS/NCS Signalling Links


NCS

NCS Common Channel


Interstation MES Signalling Channel
Signalling Links

MES Sign. Ch.


DTE
LES MES Message Ch. MES
X.400 MHS (DCE)
Network LES TDM Channel
EGC

Scope of this Section


Terrestrial Networks

An abstract operation is always performed within the context of a single call procedure. Hence all
IAPDU exchanges necessary to realize an abstract operation are mapped on 'packet' transfers
controlled by one call procedure. The MessageSubmission abstract operation is performed within the
context of the From-Mobile call procedure. The MessageDelivery and ReportDelivery abstract
operations are performed within the context of the To-Mobile call procedure. The appropriate call
procedure is performed on each invocation of an abstract operation. Within the context of a call
procedure, some Inmarsat-C 'packets' are assigned to convey the protocol elements belonging to a
particular IAPDU, protocol elements belonging to one IAPDU may be conveyed by one or more
Inmarsat-C 'packets', see Figures 25 and 26:

o the protocol elements contained in the Submit-IAPDU are conveyed by one or more 'message'
packets on the MES message channel within the context of a From-Mobile call procedure,

o the protocol elements contained in the SubmitError-IAPDU are conveyed by one or more
'message' packets on the LES TDM channel within the context of a To-Mobile call procedure,

o the protocol elements contained in the Deliver-IAPDU are partly conveyed by the
'announcement' packet on the NCS common channel (advised by the LES in the 'status request
+ announcement' packet on the ISL) and partly by one or more 'message data' packets on the
LES TDM channel within the context of a To-Mobile call procedure,

o the protocol elements contained in the Report-IAPDU are conveyed by one or more 'message'
packets on the MES message channel within the context of a From-Mobile call procedure

The MessageSubmission abstract operation involves the transfer of the message from the MES to the
LES and from the LES to the X.400 network. The 'clear' packet is used to convey the acceptance or
rejection of a message at the LES. In the subsequent event that the message cannot be transferred
by the LES to the X.400 network, the failure will be conveyed by the SubmitError IAPDU.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 43
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 25: From-Mobile Call Procedure

NETWORK LAND EARTH MOBILE EARTH


COORDINATION STATION STATION
STATION

NCS Common Channel

LES TDM
Channel

ASSIGMENT REQUEST

MES Signalling
Channel
MES BUSY
ISL
LOGICAL CHANNEL ASSIGNMENT
LES TDM
Channel

MESSAGE
MES Message
Packets convey the
Channel
Submit-IAPDU
ACKNOWLEDGEMENT
LES TDM
Channel

LOGICAL CHANNEL
CLEAR Packets convey
the Submit
LES TDM
Result-IAPDU
Channel

MES IDLE
ISL

An abstract port in the Inmarsat-C MTS' is not any different than an abstract port in the terrestrial
MTS, except for handling connections. In the terrestrial MTS an operation provided at a particular port
can only be invoked on an established connection. For the purpose of establishing and de-
establishing a connection the abstract BIND and UNBIND operations are provided at each port. Any
number of different operations can be invoked for the duration of a connection. An operation can only
be disrupted by an UNBIND operation (which can only be invoked by the initiator of the connection),
but can not be disrupted by another operation invoked on the same connection.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 44
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

With respect to connections there are three reasons why there are no BIND and UNBIND operations
employed in the Inmarsat-C MTS:

o In the Inmarsat-C system the procedures to establish a connection between a MES and LES,
differ according to the type of message transfer involved.

o In addition, each 'message' transfer in the Inmarsat-C system requires the establishment of
another connection between MES and LES.

o In the Inmarsat-C system connections are only concerned with LES to MES channel
assignment, whereas for the purpose of ports realization 'packets' are transferred on other
(common) channels as well.

Instead, an appropriate connection is established on invocation of a particular operation, and will be


de-established when the operation concerned has been successfully performed, or failed.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 45
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 26: To-Mobile Call Procedure

NETWORK LAND EARTH MOBILE


COORDINATION STATION EARTH
STATION STATION

MES STATUS REQUEST


+ ANNOUNCEMENT
ISL

Packets convey
first part of
Deliver-IAPDU MES STATUS
ISL

ANNOUNCEMENT
NCS Common Channel

ASSIGNMENT RESPONSE
MES Signalling Channel

MES STATUS (Busy)


ISL

MESSAGE
LES TDM
Channel
Packets convey
second part of REQUEST FOR ACKNOWLEDGEMENT
Deliver-IAPDU
LES TDM
Channel

ACKNOWLEDGEMENT
MES Signalling Channel

LOGICAL CHANNEL
CLEAR
LES TDM
MES STATUS (Idle) Channel

ISL

3.7 Encoding of IAPDUs


The majority of protocol elements contained in Inmarsat-C Application Protocol Data Units is placed
into the [Data] fields of the message packets transferred in the context of From-Mobile or To-Mobile
call procedure. A few protocol elements are conveyed by available control fields in other packets.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 46
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.7.1 General Encoding Rules


This subsection describes the general rules covering the format of the [Data] field of message packets
transferred in From-Mobile and To-Mobile messaging. The general format of the [Data] field is:

{addressing and other information}


"STX:<eol>"
{the actual message text or data}

The absolute minimum Inmarsat-C/X.400 message is thus:

"STX:<eol>"

(no addressing and other information, no message text and data), this translates by gateway
procedures to an empty message being sent to a default recipient or list of recipients using default
attributes. Note that managing default values is a local implementation issue in the basic service,
except those values for which default values are supplied in the Basic Inmarsat-C MTS abstract
syntax definition in Section 3.3.3.

The {addressing and other information} part represents the addressing and other information which
relates to the delivery of the message. This part is IA5 (printable subset of the CCITT T.61
recommendation with the most significant bit or parity bit set to zero) encoded up to and including the
separator string "STX:<eol>". Directly following the string "STX:<eol>" is the {actual message text and
data} part which contains the message text or data which need not necessarily be IA5 encoded.

The general encoding syntax is described as follows:

[X.400 abstract operation] ::= [argument element list][end of header]


| [end of header]

[argument element list] ::= [<eol>][argument element]


| [argument element list]

[end of header] ::= [<eol>]"STX:"[<eol>]

[argument element] ::= [element keyword]":"[parameter item]


| [element keyword]":"[parameter set]
| [element keyword]":"[parameter set]","[parameter set]

[parameter set] ::= {[parameter item] of related information. Each item is separated
by a a semi-colon (";"). Table 14 is an example of a parameter
set.}

[element keyword] ::= {Keywords appropriate to the abstract operation are listed in
the element keyword column of tables 11 through 14}

[parameter item] ::= [<value>


| [parameter element]

[parameter element] ::= [parameter keyword]"="[<value>]

[parameter keyword] ::= {Keywords appropriate to the argument element of the abstract
are listed in the parameter keyword column of tables 11
through 14.}

[<value>] ::= {The data appropriate for the [parameter keyword] is depicted
in the value column of tables 11 through 14.}

[<eol>] ::= <CR><LF> | <CR> | <LF>

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 47
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The encoding rules operating on the syntax are as follows:

1. The content of an argument element is of free form. Spaces and tabs can be inserted before
and after parameter keywords, "=", "," and <value>. No space is allowed between [IPM
element keyword] and ":".

2. The content of an argument element can be contained on multiple lines provided the end of
each line is delimited by <eol> and a "-" (hyphen); spaces and tabs between or around these
two delimiter characters are allowed. Furthermore the delimiter rules for separating parameter
sets and contents of parameter sets must be observed across the continuation lines.

The following is illegal because the delimiter, ";" is not present after the "C=UK" parameter item:

TO:G=GHAZIA; S=AHMED; C=UK<CR><LF>


- O=INMARSAT

3. A <value> containing one or more of ":", ";", "," or leading or trailing spaces or tabs shall be
enclosed in double quotes. Double quotes shall also be contained in double quotes and
replaced with two consecutive double quotes.

Concatenation of two pieces of <value> is allowed so that a <value> can be continued on the
next line. The simple rule is that the concatenation text, quoted or unquoted strings, must be
specified consecutively and can be delimited by spaces or tabs, eg.

• free = """INM"<CR><LF>
- "ARSAT"";"
will yield free = "INMARSAT"; with ";" part of the value.

• free = INM <CR><LF>


- ARSAT will yield free = INMARSAT

4 Keywords can be encoded in two forms. The full or long form is the complete keyword depicted
in Tables 22 through 24. The short form is the underlined portion of the long form keyword.
Either form of keyword can be presented to an InmCA. Conversely, the choice of keyword
presentation by an InmCA is a local implementation issue. It is recommended that an InmCA
should, at least, allow its registered mobiles to decide on the actual keyword form of
presentation.

5. The InmCA shall accept all keywords in upper or lower or a mixture of cases on origination.

6. For upward compatibility with Inmarsat-C Message Headers and future enhancements,
unrecognised argument element keywords should be ignored and processing resumed from the
next argument element; i.e. next [<eol>][IPM argument element].

[Presentation] field

a value of 80H in the [Presentation] field of the message packets indicates that the above described
structure rules are imposed on the contents of the [Data] field.

[Last Count] field

The Inmarsat-C protocol requires the use of the field [Last Count] to allow the receiving software to
determine where the end of the [Data] field occurs within the last message packet. The interpretation
of [Last Count] depends on the value given in [Presentation], in this case 80H.

The receiving software must assume that the [Data] field is byte aligned, and that [Last Count] is the
number of bytes in the [Data] field of the last message packet.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 48
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

There are potential difficulties which arise out of this, for instance, the transmission of a message in
ITA2 could be problematic. The same is true for any character code which is not an integral number of
bytes.

3.7.2 Employment of Inmarsat-C Channels and Signals


Transmission of the Submit-IAPDU

For the purpose of sending a Submit-IAPDU the assignment request packet and first message packet
are utilised as follows. In the assignment request packet the 'destination network' field is set to the
value 4H, the 'destination extension' field is set to the value 80H, the value of 'destination extension'
field is repeated in the 'presentation' field of the first message packet.

Keywords can be specified in the submit-iapdu in two forms. The full or long form is the complete
keyword depicted in Tables 11 and 12. The short form is the underlined portion of the long form
keyword. An InmCA must be able to recognise keywords presented to it in either forms.

The 'class' field in the first message packet, when set to 'deferred delivery', has no relation with
deferred delivery in X.400; i.e. the corresponding X.400 deferred delivery indication is not set
accordingly. Notice that deferred delivery in the X.400 is not supported in the basic service (although
this restriction is not applicable for terrestrial originators). Care should be taken when setting the
'class' field to 'deferred delivery' since this may interfere with other timing-constraints inside the
message contents, e.g. an x.400 message, having been deferred by the LES, may be rejected by a
MTA due to the expiry of a delivery time limit (IPM Element of Service). In general the 'class' field
should set to 'immediate delivery'.

A delivery-report is requested per-recipient and the request shall be encoded as shown in section
3.7.3. However when the first delivery packet is set to the value 'delivery confirmation required', this
should be sufficient for the InmCA to request a delivery report on each and every recipient specified.

Transmission of the Submit-Error-IAPDU and Report-IAPDU

For the purpose of transmitting a Submit_Error-IAPDU and a Report-IAPDU, the announcement


packet is utilised as follows:

In the announcement packet the 'presentation' field is set to the value 80H.

Keywords can be displayed in the iapdu in two forms. The full or long form is the complete keyword
depicted in Tables 12 through 14. The short form is the underlined portion of the long form keyword.
The choice of keyword form in the construction of a iapdu is an InmCA implementation. It is
recommended that an InmCA should provide an option on the choice of forms; such an
implementation is a local InmCA issue.

Each reported recipient address is a subset of Table 14 and shall be encoded as shown in section
3.7.3.

For message data packets the same rules apply as for message channel packets.

Transmission of the delivery-iapdu

For the purpose of transmitting a delivery-IAPDU the announcement packet is utilised as follows. In
the announcement packet the 'presentation' field is set to the value 80H.

Keywords can be displayed in the delivery-iapdu in two forms. The full or long form is the complete
keyword depicted in Tables 12 through 14. The short form is the underlined portion of the long form
keyword. The choice of keyword form in the construction of a delivery-iapdu is an InmCA
implementation. It is recommended that an InmCA should provide an option on the choice of forms;
such an implementation is a local InmCA issue. The content of the delivery report is given in section
3.7.4.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 49
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

A delivery-report is requested per-recipient and the request shall be encoded as shown in section
3.7.3. However when delivery-reports are required from all recipients of this message, it should be
sufficient just to set the 'confirmation request' field in the first message packet to the value 'delivery
confirmation required'.

For message data packets the same rules apply as for message channel packets.

3.7.3 A Textual Encoding of IAPDUS


The tables used in this section to describe in detail the encoding of each iapdu comprise 6 or 7
columns. The first column provides a reference to the associated ASN.1 construct of a particular
element. The second column shows the keyword associated with each element. The third column
specifies what will happen if a keyword is repeated in the same message. In this case an argument
following a repeated keyword may either replace (replacement) the previous argument of the same
keyword or the argument may be added to the list of arguments following the same keyword
(concatenation). This column is not present for the delivery-iapdu since the gateway will not generate
messages with repeated keywords. The next three columns are pertinent to the parameters which can
be part of a particular argument. The ‘parameter’ column gives the ASN.1 name of the parameter
concerned. Followed by a column giving the parameter keyword, if any. The ‘value’ column gives the
encoding of parameter values. Some parameters take values out of a set of predefined values, these
values are indicated between quotes. Other parameter values are more generic, such as printable-
string. Notice that all values shall be IA5 encoded. A generic value such as printable-string implicates
that the gateway has to convert between the IA5 encoding of parameter values and the encoding
used by the terrestrial network. The last column contains some specific remarks per parameter.

3.7.4 A Textual Encoding of Delivery and Non-Delivery Reports


Delivery and non-delivery reports should have the message header encoded as described in section
3.7.3 (the content-type values "CMCDR" and "CMCNDR" should be used for delivery and non-
delivery reports respectively, and the subject should be the original message subject prefixed by
"DR:" or "NDR:"). The body of a delivery report message (following "STX:") shall have the following
syntax:

TITLE:Delivery Report
ADDRESS:[destination address]
LES:[LES ID]
MSGREF:[reference number]
LESATTEMPTS:[number of attempts]
=

where [reference number], [LES ID] and [number of attempts] are decimal numbers, and [destination
address] is the O/R address. The value [number of attempts] reflects the number of attempts made
by the LES to deliver the message to the destination address.

Non-delivery reports should have the following:

TITLE:Non-delivery Report
ADDRESS:[destination address]
LES:[LES ID]
MSGREF:[reference number]
LESATTEMPTS:[number of attempts]
REASON:[non-delivery reason code] [non-delivery reason string]
=

where [reference number], [LES ID], [number of attempts] and [destination address] are as above,
[non-delivery reason code] is a four digit decimal code (with leading zeroes if necessary) and [non-
delivery reason string] is a user readable string identifying the cause of failure.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 50
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The following are valid Basic X.400 error code numbers and their corresponding strings. The strings
may have diagnostic reasons appended.

0400 Transfer failure

0401 Unable to Transfer

0402 Conversion not performed

0403 Physical rendition not performed

0404 Physical delivery not performed

0405 Restricted delivery

0406 Directory operation unsuccessful

Additional diagnostic reasons (may be appended to above error codes):

- Unregonised O/R name

- Ambiguous OR name

- Mts congestion

- Loop detected

- Recipient unavailable

- Maximum time expired

- Encoded information types unsupported

- Content too long

- Conversion impratical

- Implicit conversion prohibited

- Implicit conversion not subscribed

- Invalid arguments

- Content syntax error

- Size constraint violation

- Protocol violation

- Content type not supported

- Too many recipients

- No bilateral agreement

- Unsupported critical function

- Conversion with loss prohibited

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 51
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

- Line too long

- Page split

- Pictorial symbol loss

- Punctuation symbol loss

- Alphabetic character loss

- Multiple information loss

- Recipient reassignment prohibited

- Redirection loop detected

- DL expansion prohibited

- No DL submit permission

- Dl expansion failure

- Physical rendition attributes not supported

- Undeliverable mail physical delivery address incorrect

- Undeliverable mail physical delivery office incorrect or invalid

- Undeliverable mail physical delivery address incomplete

- Undeliverable mail recipient unknown

- Undeliverable mail recipient deceased

- Undeliverable mail organization expired

- Undeliverable mail recipient refused to accept

- Undeliverable mail recipient did not claim

- Undeliverable mail recipient changed address permanently

- Undeliverable mail recipient changed address temporarily

- Undeliverable mail recipient changed temporary address

- Undeliverable mail new address unknown

- Undeliverable mail recipient did not want forwarding

- Undeliverable mail originator prohibited forwarding

- Secure messaging error

- Unable to downgrade

The original message (excluding the original header) may follow the equals sign (starting on a new
line) at the end of the delivery or non-delivery information.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 52
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Table 11: Message Submission Envelope Fields

Concatenation
Element Parameter
Element or replacement Parameter Value Remarks
Keyword Keyword
of argument
originator-name "FROM:" replacement ORName <see ORName> <see ORName>
If absent, the default encoded type is
constructed from the bodypart type
"undefined" as follows:
"tlx"
"ia5"
"g3" IA5 body := IA5 (default)
original-encoded- built-in-encoded- "g4" ITA2 body := TLX
"EIT:" concatenation
information-types information-types "ttx" G3 body := G3
"vtx" G4 body := G4
"voice" TTX body := TTX
"sfd" MSG body := as enclosed msg
"mixed" mixed body := mixed
bilat body := undefined
nat body := undefined
external-encoded-
"ext=" object-identifier
information-type
If absent, IPM84 or IPM88 shall be
"CONTENTTY built-in-content- "unidentified"
content-type replacement selected according to CCITT X420
PE:" type "external"
section 20.2 on content type.
external-content-
"ext=" object-identifier
type
content-identifier "CID:" replacement ContentIdentifier printablestring
"normal"
priority "PRIORITY:" replacement Priority "nonurgent"
"urgent"

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 53
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Table 11: Message Submission Envelope Fields, continued…

Concatenation
Element Parameter
Element or replacement Parameter Value Remarks
Keyword Keyword
of argument
Presence of this keyword
means that implicit-
per-message- "NOCONVERS conversion is prohibited.
replacement <no parameters>
indicators IN:" Absence means that implicit-
conversion is allowed, this is
also the default in x.400.
Presence of this keyword
means that DL-expansion is
dl-expansion- prohibited. Absence means
"NODL:" replacement <no parameters>
prohibited that DL-expansion is
allowed, this is also the
default in x.400.
Presence of this keyword
means that conversion-with-
conversion-with- loss is prohibited. Absence
"NOLOSS:" replacement <no parameters>
loss-prohibited means that conversion-with-
loss is allowed, this is also
the default in x.400.
Characters following the
colon ":" and <eol> may not
be in ia5 encoding. In this
case the "EIT:" argument will
content "STX:<eol>" Content <any type>
indicate the encoding used.
If content-type is "ipm84/88"
the "STX:" is provided as a
result of the IPM encoding.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 54
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Table 12: Per Recipient Message Submission Fields

Concatenation
Element Parameter
Element or replacement Parameter Value Remrks
Keyword Keyword
of argument
per-recipient- <see <see
"TO:" concatenation recipient-name
fields ORName> ORName>
If absent, NDR is assumed for
originator-report-
"DR" the return of delivery failure back
request
to the MES.
"ia5-ttx"
"ttx-tlx"
"tlx-ia5"
"tlx-ttx"
"tlx-g4"
"tlx-vtx"
"ia5-txl"
"tlx-g3"
Conversions are performed by
"ia5-g3"
explicit-conversion the MTS, and not by the
"ia5-g4"
gateway.
"ia5-vtx"
"ttx-ia5"
"ttx-g3"
"ttx-g4"
"ttx-vtx"
"vtx-tlx"
"vtx-ia5"
"vtx-ttx"

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 55
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Table 13: Message Delivery Envelope Fields

Element Parameter
Element Parameter Value Remarks
Keyword Keyword
message-delivery- See chapter about message
"MSGID:" MTSIdentifier mts-identifier
identifier identification
UTC time of the form with single
message-delivery-time "DELTIME: Time utc-time space between date and time.
"YYMMDD HHMM"
"CMCDR"
"CMCNDR"
"unidentified"
content-type "CONTENTTYPE:" built-in-content-type
"external"
"ipm84"
"ipm88"
external-content-type "ext=" object-identifier
originator-name "FROM:" ORName <see ORName> <see ORName>
"undefined"
"tlx"
"ia5"
"g3"
original-encoded- built-in-encoded- "g4"
"EIT:"
information-types information-types "ttx"
"vtx"
"voice"
"sfd"
"mixed"
external-encoded-
"ext=" object-identifier
information-type

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 56
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Table 13: Message Delivery Envelope Fields, continued…

Element Parameter
Element Parameter Value Remarks
Keyword Keyword
"normal"
priority "PRIORITY:" Priority "nonurgent"
"urgent"
Presence of this keyword means
that implicit-conversion is prohibited.
"NOCONVERSI
delivery-flags <no parameters> Absence means that implicit-
ON:"
conversion is allowed, this is also
the default in x.400.
"undefined"
"tlx"
"ia5"
"g3"
converted-encoded- "g4"
"CONVERTED:" <no parameters>
information-types "ttx"
"vtx"
"voice"
"sfd"
"mixed"
external-encoded-
"ext=" object-identifier
information-type
UTC time of the form with single
message- space between date and time.
"SUBTIME:" Time utc-time
submission-time
"YYMMDD HHMM"

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 57
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Table 13: Message Delivery Envelope Fields, continued…

Element Parameter
Element Parameter Value Remarks
Keyword Keyword
content-identifier "CID:" ContentIdentifier printablestring
Presence of this keyword means
that DL-expansion is prohibited.
dl-expansion-
"NODL:" <no parametres> Absence means that DL-expansion
prohibited
is allowed, this is also the default in
x.400.
Presence of this keyword means
that conversion-with-loss is
conversion-with-loss-
"NOLOSS:" <no parameters> prohibited. Absence means that
prohibited
conversion-with-loss is allowed, this
is also the default in x.400.
Characters following the colon ":"
content "STX:<eol>" Content <any type> and <eol> may be in different
encoding

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 58
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Table 14: ORNames

Containing ASN.1 Parameter


Parameter Value
element keyword
x121-dcc-code
ORName country-name "C="
iso-3166-alpha2-code
admin-domain-name "A=" numeric printable
network address "X121=" numeric
terminal-id "TID=" printable
private-domain-name "P=" numeric printable
organisation "O=" printable
user agent numeric id "NID" numeric
surname "S=" printable
given name "G=" printable
initials "I=" printable
generation qualifier "Q=" printable
organisational unit 1 "OU1=" printable
organisational unit 2 "OU2=" printable
organisational unit 3 "OU3=" printable
organisational unit 4 "OU4=" printable
1
domain defined attribute "DDA:<TYPE>=" printable
common name "CN=" printable
"tlx"
"ttx"
"g3"
terminal type "TTY=" "g4"
"ia5"
"vtx"

1: where <type> will be substituted by the name of the domain defined attribute, e.g. "DDA:Internet:"

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 59
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Table 15: Delivery-Report Fields

Element Parameter
Element Parameter Value Remarks
Keyword Keyword
message-delivery- message identification of
"MSGID:" MTSIdentifier mts-identifier
identifier the message being reported
<see <see the originating address of this
originator-name "FROM:" ORName
ORName> ORName> delivery report.
used only for message
submission error
"01" Submission Control Violation
"02" Originator Invalid
"03" Recipient Improperly Specified
submission-error SUBERROR:
"04" Element Of Service Not Subscribed
"11" Inconsistent Request
"12" Security Error
"13" Unsupported Critical Function
"15" Remote Bind Error
per-reported-recipient- <see used only for X.400
"TO:" concatenation recipient-name
fields ORName> delivery reports
used only in the case of a
success-delivery DELIVERED
successful delivery
used only for failed
non-delivery-reason-code NDRC= three digits delivery, reason code as
depicted in see Fig. 17.
used only for failed delivery
non-delivery-diagnostic-code. NDDC= three digits diagnostic code, as
depictded in Fig. 17.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 60
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4 Interpersonal Messaging System in the Context of Inmarsat-C


Interworking with MHS
In this section a Basic Inmarsat-C Interpersonal Messaging System (IPMS) is described. The Basic
Inmarsat-C IPMS is based on the selected subset of IPMS Elements described in Section 2.2. Section
4.2 describes the abstract information objects supported in the Basic Inmarsat-C IPMS. Sections 4.3
through 4.5 describe the Basic Inmarsat-C IPMS abstract service. Section 4.6 provides a reference
between abstract information objects and their encoding in a textual representation. Identification of
originators and recipients in the IPMS is given in Section 4.7.

Recommendation T.300 is one of the CCITT Recommendations dealing with telematic interworking.
Inmarsat-C access to and participation in the Interpersonal Messaging System is one of the telematic
interworking applications. This section describes telematic interworking application based on the
concepts and description techniques of T.300.

A functional model of Basic Inmarsat-C access to the InterPersonal Messaging System is given in this
section. The purpose of this functional model is to give a general description of the functional entities,
which are then explicitly defined using the definitions and conventions of CCITT Recommendation
X.407. These conventions provide a descriptive tool for the specification of information processing
tasks in abstract terms. This ensures that the task's functional requirements are stated independently
of its realization.

In the IPMS abstract information objects are exchanged between IPM end-users as shown in Figure
27.

Figure 27: InterPersonal Messaging Scenario

IPM Information objects

MT Information
objects

IPM- IPM-end IPM-end IPM-


user system MT System system user

Strictly speaking interpersonal messaging is an end-to-end scenario. To access the IPMS from a
mobile terminal the InmCA is involved. In principle an InmCA performs a similar task as an IPM-User-
Agent. In addition the InmCA transforms the information objects exchanged between end-users into
another presentation. To reduce protocol overhead it may even act on behalf of the end-user, please
refer to Figure 28.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 61
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 28: InterPersonal Messaging Scenario To or From a Mobile User

IPM Information objects

MT Information
objects

Mobile Mobile IPM-end IPM-


IPM- IPM-end Gateway MT System system user
user system

4.1 Abstract Information Objects


This section describes the Basic Inmarsat-C information objects that mobile users exchange in
interpersonal messaging. Information objects are associated with Elements of Service which are
classified based on the classification of Elements of Service described in Section 2.2. Several
dependences exist as illustrated in Figure 29.

Figure 29: Dependencies Between Elements of Service and Associated Information


Elements

Origination Reception

elements
of
service
(1) (3)
associated
information
elements
(2)

An arrow "A-(1)->B" depicts that B depends on A in relation (1). Figure 29 shows that the following
dependencies exist:

o For elements of service as well as information objects the classification at Origination is


independent from the classification at Reception.

o For elements of service the classification at Reception is independent from the classification at
Origination.

o For information objects the classification at reception is dependent from the classification at
origination,; please see following note 2.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 62
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

o For information objects the classification at origination and reception is dependent from the
classification for elements of service at origination and reception respectively; please refer to
note 1 and 3.

Note 1: When an element of service is available at origination either (O)ptional or (M)andatory the
originating side must be able to generate the associated information objects. The classification for
these information objects becomes (C)onditional and (M)andatory respectively. The condition is that
when the (O)ptional element of service is made available the classification for the associated
information objects becomes (M)andatory. In short, (O)-1->(C) where (C) becomes (M) when (O) is
implemented, and (M)-1->(M).

Note 2: When an information object may be generated at origination the reception side must always
be prepared to handle the information object, i.e. the reception side must be able to decode the
information object. In short, (M/O/C)-2->(M). Strictly speaking an information object which is (O)ptional
or (C)onditional for origination should be (C)onditional at reception, (O/C)-2->(C), where (C) becomes
(M) when the information object concerned is generated. However due to the fact that this
classification involves two separate systems and many systems may intercommunicate with many
other systems it is very likely or at least uncontrollable that one originator may generate the
information object. All recipients should then be prepared to handle the information object.

Note 3: When an element of service is available at reception either (O)ptional or (M)andatory the
reception side must make the information objects available. The classification for these information
objects becomes (C)onditional and (M)andatory respectively. The condition is that when the
(O)ptional element of service is made available the classification for the associated information
objects becomes (M)andatory. In short, (O)-3->(C) where (C) becomes (M) when (O) is implemented,
and (M)-1->(M). Note that when an information object is available at the reception side the recipient is
not forced to make the element of service available, the classification of the element of service is
independent of the classification of the associated information object.

The Inmarsat-C information objects defined in this Section 4 are a redefinition of the information
objects defined in CCITT Recommendation X.420. Information objects are of two kinds, interpersonal
messages (IPMs) and interpersonal notifications (IPNs). An IPN acknowledges a user's receipt of an
IPM. In the Basic Service, IPNs are not supported, therefore a Inmarsat-C information object is
defined as:

InformationObject ::= CHOICE


ipm [0] IPM }

An IPM comprises a heading, containing information about the IPM, and a sequence of body parts,
containing the actual information conveyed between users.

IPM ::= SEQUENCE{


heading Heading,
body Body }
Body ::= SEQUENCE OF BodyPart

Tables 16 and 17 specify the behaviour of an MES (InmC-Mes) and an Inmarsat-C-Agent (InmCA)
associated with information objects in processing. The following abbreviations are used in this
classification:

Not supported (N): The gateway or MES is not able to handle the information object. The
information object is ignored by the gateway or MES if presented.

Mandatory (M): The gateway and MES shall handle the information object, i.e. the gateway
and MES are able to encode and decode the information object, the
gateway shall transfer the information object.

Optional (O): The gateway and MES may handle the information object, i.e. the gateway
and MES may be able to encode and decode the information object, the

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 63
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

gateway may transfer the information object. If an information object is


received by the gateway or MES and the necessary procedures to
handle the information object are not implemented the receipt of the
information object results in a protocol error.

Table 16: Inmarsat-C IPM Heading Fields

Information Object Orig Rec

IPM M M
heading M M
this-IPM M M
originator M M
authorising-users N M
primary-recipients M M
copy-recipients M M
blind-copy-recipients M M
replied-to-IPM M M
obsoleted-IPMs N N
related-IPMs N N
subject M M
expiry-time N N
reply-time N N
reply-recipients N N
importance N N
sensitivity N N
auto-forwarded N M
extensions
incomplete-copy M M
languages N N

IPM....

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 64
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Table 17: Inmarsat-C IPM Body Part Types

Information Object Orig Rec

IPM
body M M
body-part M M
ia5-text M M
voice N N
g3-facsimile N N
g4-class1 N N
teletex N N
videotex N N
encrypted N N
message N O
delivery-time N M
delivery-envelope N M
data
N M
(forwarded-ipm)
mixed-mode N N
bilaterally-defined N N
nationally-defined N N
externally-defined N O

A forwarded IPM may not contain another forwarded IPM, hence the body-part type of the forwarded
IPM must be one of a 'primitive' type (ia5-text), The delivery-envelope reveals the MTS-originator, and
the MTS-recipients of the forwarded IPM.

Figure 30: Information Objects

INMC-IOB -- { iso:org:dod:internet:private:enterprise:inmarsat:inmc-iob }

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

IMPORTS

-- upper boundsI

ub-free-form-name, ub-local-ipm-identifier, ub-subject-field, ub-telephone-number

FROM INMC-IOB-UB
Time ::= UTCTime
-- Information object

InformationObject ::= CHOICE {


ipm [0] IPM
}
-- IPM

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 65
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

IPM ::= SEQUENCE {


heading Heading,
body Body
}

-- Heading

Heading ::= SET {


this-IPM ThisIPMField OPTIONAL,
originator [0] OriginatorField OPTIONAL,
authorizing-users [1] AuthorizingUsersField OPTIONAL,
primary-recipients [2] PrimaryRecipientsField DEFAULT {},
copy-recipients [3] CopyRecipientsField OPTIONAL,
blind-copy-recipients [4] BlindCopyRecipientsField OPTIONAL,
replied-to-IPM [5] RepliedToIPMField OPTIONAL,
subject [8] EXPLICIT SubjectField OPTIONAL,
auto-forwarded [14] AutoForwardedField DEFAULT FALSE,
extensions [15] ExtensionsField DEFAULT {}
}

-- Note: The heading set is a subset of the CCITT X420 set. Any heading field not listed is not handled
by the InmCA.

-- Heading components types

IPMIdentifier ::= PrintableString (SIZE (0..ub-local-ipm-identifier))

RecipientSpecifier ::= SET {


recipient [0] ORDescriptor,
-- notification-requests [1] NotificationRequests DEFAULT {},
reply-requested [2] BOOLEAN DEFAULT FALSE
}

NotificationRequests ::= BIT STRING {


-- rn(0),
-- nrn(1),
ipm-return(2)
}

ORDescriptor ::= SET {


formal-name ORName OPTIONAL,
free-form-name [0] FreeFormName OPTIONAL,
telephone-number [1] TelephoneNumber OPTIONAL
}

FreeFormName ::= TeletexString (SIZE (0..ub-free-form-name))

TelephoneNumber ::= PrintableString (SIZE (0..ub-telephone-number))

-- This IPM heading field

ThisIPMField ::= IPMIdentifier

-- Originator heading field

OriginatorField ::= ORDescriptor

--Authorizing users heading field

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 66
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

AuthorizingUsersField ::= SEQUENCE OF ORDescriptor

-- Primary recipients heading field

PrimaryRecipientsField ::= SEQUENCE OF RecipientSpecifier

-- Copy recipients heading field

CopyRecipientsField ::= SEQUENCE OF RecipientSpecifier

-- Blind copy recipients heading field

BlindCopyRecipientsField ::= SEQUENCE OF RecipientSpecifier

-- Replied-to ipm heading field

RepliedToIPMField ::= IPMIdentifier

-- Subject heading field

SubjectField ::= TeletexString (SIZE (0..ub-subject-field))

-- Auto-forwarded heading field

AutoForwardedField ::= BOOLEAN

-- Extensions heading field

ExtensionsField ::= SET OF HeadingExtension

-- HeadingExtension ::= SEQUENCE {


-- type OBJECT IDENTIFIER, -- an OID requires registration
-- value ANY DEFINED BY type
-- }

HeadingExtension ::= SEQUENCE {


type INTEGER,
value ANY DEFINED BY type
}
-- Body

Body ::= BodyPart

BodyPart ::= CHOICE {


ia5-text [0] IA5TextBodyPart,
g3-facsimile [3] G3FacsimileBodyPart,
g4-class1 [4] G4Class1BodyPart,
teletex [5] TeletexBodyPart,
message [9] MessageBodyPart,
mixed-mode [11] MixedModeBodyPart,
bilaterally-defined [14] BilaterallyDefinedBodyPart,
nationally-defined [7] NationallyDefinedBodyPart,
externally-defined [15] ExternallyDefinedBodyPart
}

-- body part types

IA5TextBodyPart ::= SEQUENCE {


parameters IA5TextParameters,

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 67
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

data IA5TextData
}

IA5TextParameters ::= SET {


repertoire [0] Repertoire DEFAULT ia5
}

IA5TextData ::= IA5String

Repertoire ::= ENUMERATED {


ita2 (2),
ia5 (5)
}

-- G3 Facsimile body part


G3FacsimileBodyPart ::= SEQUENCE {
-- parameters G3FacsimileParameters,
data G3FacsimileData }

-- G3FacsimileParameters ::= SET {


-- number-of-pages [0] INTEGER OPTIONAL,
-- non-basic-parameters [1] G3FacsimileNonBasicParameters OPTIONAL }

G3FacsimileData ::= SEQUENCE OF BIT STRING

-- G4 class 1 and mixed mode body parts

-- G4Class1BodyPart ::= SEQUENCE OF ProtocolElement

G4Class1BodyPart ::= ANY

-- MixedModeBodyPart ::= SEQUENCE OF ProtocolElement

MixedModeBodyPart ::= ANY

-- Teletex body part

TeletexBodyPart ::= SEQUENCE {


-- parameters TeletexParameters,
data TeletexData }

-- TeletexParameters ::= SET {


-- number-of-pages [0] INTEGER OPTIONAL,
-- telex-compatible [1] BOOLEAN DEFAULT FALSE,
-- non-basic-parameters [2] TeletexNonBasicParameters OPTIONAL }

TeletexData ::= SEQUENCE OF TeletexString

-- Message body part

MessageBodyPart ::= SEQUENCE {


parameters MessageParameters,
data MessageData
}

MessageParameters ::= SET {


delivery-time [0] MessageDeliveryTime OPTIONAL,
delivery-envelope [1] OtherMessageDeliveryFields OPTIONAL
}

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 68
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

MessageData ::= IPM -- may not contain another another message body part

-- Bilaterally defined body part

BilaterallyDefinedBodyPart ::= OCTET STRING

-- Nationally defined body part

NationallyDefinedBodyPart ::= ANY

-- Externally defined body part

-- ExternallyDefinedBodyPart ::= SEQUENCE {


-- parameters [0] ExternallyDefinedParameters OPTIONAL
-- data ExternallyDefinedData
-- }

--ExternallyDefinedParameters ::= EXTERNAL

--ExternallyDefinedData ::= EXTERNAL

ExternallyDefinedBodyPart ::= ANY

END -- of Information objects

Figure 31: Extensions

INMC-IOB-EXTENSIONS -- { iso:org:dod:internet:private:enterprise:inmarsat:inmc-iob-extensions }

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

IMPORTS -- nothing

-- Extensions

-- Incomplete Copy

-- incomplete-copy ::= OBJECT IDENTIFIER { id-hex-incomplete-copy }

incomplete-copy INTEGER ::= 1

IncompleteCopy ::= NULL

END -- of Extensions

Figure 32: Upper Bounds

INMC-IOB-UB -- { iso:org:dod:internet:private:enterprise:inmarsat:inmc-iob-ub }

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 69
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

IMPORTS -- nothing -- ;

-- Upper bounds

ub-free-form-name INTEGER ::= 64

ub-local-ipm-identifier INTEGER ::= 64

ub-subject-field INTEGER ::= 128

ub-telephone-number INTEGER ::= 32

END -- of upper bounds

4.2 Abstract Service Definition


This paragraph defines the Basic Inmarsat-C IPM Service, and describes the environment in which
the Basic Inmarsat-C IPMS is provided.

4.2.1 Secondary Object Types


The InterPersonal Messaging System (IPMS) is the abstract object by means of which all ipms-users
communicate with one another. The IPMS object can be modelled as comprising lesser objects which
interact with each other by means of ports. The lesser objects are referred to as the secondary
objects types of interpersonal messaging. The secondary objects types are defined in CCITT
Recommendation X.420, except for the Inmarsat-C agent which is defined in Section 4..2.2.The IPMS
is functionally decomposed into the following objects:

ipms-refinement REFINE ipms AS


mTS
submission [S] PAIRED WITH ipms-ua, ipms-ms
delivery [S] PAIRED WITH ipms-ua, ipms-ms
administration [S] PAIRED WITH ipms-ua, ipms-ms
import [S] PAIRED WITH tlma, tlxau, pdau, InmCA
export [S] PAIRED WITH tlma, tlxau, pdau, InmCA
ipms-ua RECURRING
origination [S] VISIBLE
reception [S] VISIBLE
management [S] VISIBLE
ipms-ms RECURRING
submission [S] PAIRED WITH ipms-ua
retrieval [S] PAIRED WITH ipms-ua
administration [S] PAIRED WITH ipms-ua
tlma RECURRING
origination [S] VISIBLE
reception [S] VISIBLE
management [S] VISIBLE
tlxau RECURRING
origination [S] VISIBLE
reception [S] VISIBLE
management [S] VISIBLE
pdau RECURRING
reception [S] VISIBLE
InmCA RECURRING
origination [S] VISIBLE
reception [S] VISIBLE
::= id-ref-secondary

The structure of the extended IPMS is depicted in Figure 40.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 70
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 33: The InterPersonal Messaging System Extended with the InmCA

IPM System

Import
InmC- IPMS- IPMS
InmCA MTS
User UA User
Export

Origination Origination
Reception
Reception
Management
Submission
Delivery
Administration

4.2.2 Inmarsat-C Agent


An Inmarsat-C agent (InmCA) is the functional unit that helps a user engaged in InterPersonal
Messaging from a (mobile) Inmarsat-C terminal. It helps the mobile Inmarsat-C user (InmC-user) to
originate, receive, or both originate and receive messages containing information objects of the types
defined in Section 4.1. The InmCA comprises two secondary objects, the mobile terminal (InmC-Mes)
and the gateway (InmC-Gtw), see Figure 31.

Figure 34: Refinement of the InmCA

InmCA(Inmarsat-C
Agent)
Submission
InmC-U InmC- InmC- MTS
ser MES Delivery Gtw

Origination Import

Reception Export

inmca-refinement REFINE inmca AS


inmc-gtw
submission [S] PAIRED WITH inmc-mes
delivery [S] PAIRED WITH inmc-mes
import [C] VISIBLE
export [C] VISIBLE
inmc-mes RECURRING
origination [S] VISIBLE
reception [S] VISIBLE
::= id-ref-inmca

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 71
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.2.3 Inmarsat-C User


The Inmarsat-C user (inmc-user) is associated with the InmCA by means of the origination, reception,
management and subscription ports. The origination, reception and management port services and
operations are a subset of the port services and operations defined in X.420. The subscription port
services and operations are for further study.

inmc-user OBJECT
PORTS {
origination [C],
reception [C] }
::= id-ot-inmc-user

4.3 Abstract Ports and Operations


The abstract operations available at the ports which the IPMS (by means of the InmCA) supplies to
and invokes from the InmC-user are specified in this paragraph.

4.3.1 Abstract Ports


The origination port abstract operations are invoked by the user and performed by the IPMS (InmCA).

origination PORT
CONSUMER INVOKES {
OriginateIPM }
::= id-pt-inmca-origination

The reception port abstract operations are invoked by the IPMS (InmCA) and performed by the user.

reception PORT
SUPPLIER INVOKES {
ReceiveReport,
ReceiveIPM }
::= id-pt-inmca-reception

4.3.2 Abstract Operations


This subsection specifies the operations provided at each abstract port. Each abstract operation
conveys a number of abstract information objects, belonging to the Message Transfer Service or
Interpersonal Messaging Service. A detailed classification of the abstract information objects
belonging to the MTS is given in Section 3. A detailed classification of the abstract information objects
belonging to the IPMS is given in this section. Note that the classification of any object is relative to
the classification of its superior or encapsulating object. Hence the classification of an abstract
information object is relative to the classification of an abstract operation conveying the abstract
information object.

In Table 18. the abstract information objects are classified in relation to the abstract operations
supplied by the origination port. The ARGUMENT depicts the abstract information that the InmC-Mes
can construct and present (to the InmC-Gtw) on origination and the InmC-Gtw can expect to receive
(from the InmC-MES) and handle the abstract information. The ERRORS definition depicts the
information provided by the InmC-Gtw when apprising the InmC-MES of the failure of the abstraction
operation; please see Figure 35.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 72
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 35: Origination & Reception for the OriginateIPM Abstract Operation

OriginateIPM
InmC-Agent

InmC-User
Argument
R O

Errors
O R

Scope of
Table 7.4

Table 18: Classification of Abstract Operations Supplied by the Origination Port

IPMS'-user
Operation / Element IPMS' (InmCA)
(InmCA-user)
OriginateIPM M M
ARGUMENT
envelope M M
content M M
ERRORS
RecipientImproperlySpecified M M

The OriginateIPM abstract operation originates a message whose content is an IPM from an
Inmarsat-C user to the IPMS (InmCA).

OriginateIPM ::= ABSTRACT-OPERATION


ARGUMENT SET {
envelope [0] MessageSubmissionEnvelope,
content [1] IPM }
ERRORS {
RecipientImproperlySpecified }

In Table 19, the abstract information objects are classified in relation to the abstract operations
supplied by the reception port. The ARGUMENT definition shows the ability of the InmC-user to
handle the abstract information object on reception and the ability of the InmCA to handle the abstract
information object on origination. There are no abstract information objects associated with abstract
RESULTs and ERRORS, see Figure 36.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 73
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 36: Origination and Reception for ReceiveIPM and ReceiveReport Abstract
Operations

Receive
IPM/Report

Argument

InmC-User
O R
InmC-Agent

Scope of
Table 7.5

Table 19: Classification of Abstract Operations Supplied by the Reception Port

IPMS'-user
Operation / Element IPMS' (InmCA)
(InmCA-user)
ReceiveReport M M
ARGUMENT
envelope M M

ReceiveIPM M M
ARGUMENT
envelope M M
content M M

The ReceiveIPM abstract operation receives a message whose content is an IPM at an Inmarsat-C
user from the IPMS (InmCA).

ReceiveIPM ::= ABSTRACT-OPERATION


ARGUMENT SET {
envelope [0] MessageDeliveryEnvelope,
content [1] IPM }
RESULT
ERRORS { }

The ReceiveReport abstract operation receives a report at the Inmarsat-C user from the IPMS
(InmCA).

ReceiveReport ::= ABSTRACT-OPERATION


ARGUMENT SET {
envelope [0] ReportDeliveryEnvelope }
RESULT
ERRORS { }

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 74
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.4 Message Identification in the IPMS


This section describes message identification in the context of Inmarsat-C interworking with the IPMS.
An IPM identifier is an information object that unambiguously and uniquely distinguishing it from all
other IPMs generated by another user. IPM identifier values are assigned by users. References of
two kinds appear throughout the heading of an Inmarsat-C IPM:

• The this-IPM heading field identifies this particular IPM from any other IPM.

• The replied-to-IPM heading field identifies the IPM to which the present IPM is a reply.

The following IPM and MTS information objects are generated by, or supplied to the mobile user when
engaged in interpersonal messaging:

1. On origination of an IPM, a IPM identifier may be assigned by the user to the this-IPM heading
field.

2. On origination of an IPM the user may optionally refer to any other IPM by assigning an IPM
identifier value to the replied-to-IPM heading field.

3. On reception of a delivery report, only the MTS identifier of the message conveying an IPM is
revealed to the user.

4. On reception of an IPM, the heading reveals the IPM identifier of this-IPM, and possibly any
replied-to-IPM to the user.

4.4.1 From-Mobile Message IPM Identification


An IPM identifier can be specified in the this-IPM and in the replied-to-IPM heading fields of the IPM
message. No changes are made by the IPM-Gtw to the this-IPM and the replied-to-IPM fields
provided by the user. If the this-IPM heading field is omitted, the InmC-Gtw shall generate a unique
reference on behalf of the mobile user.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 75
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 37: Message Identification of a Mobile Originated IPM

InmC- MTA UA
MTA MS
agent

Origination
of message

Optionally user
assigned ipm-id
Submission
of message

generation of
ipm-id if not
assigned by user

LES assigned
msg-ref

msg-ref
Import of
message

ipm-id, user assigned or


generated by agent

MTS assigned mts-id


=<admd>!msg-ref

Transfer of
message
ipm-id, mts-id
Delivery of
message ipm-id, mts-id

ipm-id, mts-id

Reception
of message

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 76
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 38: Delivery Notification of a Mobile Originated IPM

InmC- UA
MTA MTA
agent MS

Transfer of delivery
notification

Subject mts-id,
Export of ipm-id in contents
delivery which is optionally
notification returned.

mts-id, contents not


returned, hence
ipm-id is not
revealed.

Delivery of delivery
notification

Derive msg-ref from


mts-id. delivery notification
conveyed by messaging
protocol
Receipt of
delivery
notification

msg-ref depicts
mts-id'

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 77
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.4.2 To-Mobile Message IPM Identification


An IPM identifier can appear in the this-IPM and in the replied-to-IPM. heading fields of the IPM
message.

Figure 39: Message Identification of a Terrestrial Originated IPM

InmC- MTA UA
MTA
agent MS

Origination of
message

User assigned
ipm-id .
Submission
of message

ipm-id .

MTS assigned
mts-id
mts-id

Transfer of
message
mts-id, ipm-id
Export of
message

mts-id, ipm-id

Delivery of
message
ipm-id and optionally present
mts-id. LES assigned msg-ref
in 'announcement' packet
Receipt of ignored.
message

ipm-id and optionally


present mts-id.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 78
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 40: Delivery Notification of a Terrestrial Originated IPM


InmC- MTA MTA UA
agent MS

Transfer of
delivery
notification

mts-id , ipm-id

Delivery of
delivery
notification

mts-id, ipm-id

Receipt of
delivery
notification

mts-id, ipm-id

4.4.3 Mobile To Mobile Message IPM Identification


The combination of both scenarios, Sections 4.5.2 and 4.5.3 allows for IPM-identifiers to multiple-
cross an InmCA.

4.5 Inmarsat-C Agent Operation in Provision of the IPM Abstract Service


An InmCA helps an Inmarsat-C user to originate and receive messages containing information objects
of the types defined in section 4.2. Therefore it can be said that an InmCA performs a similar task as
an interpersonal messaging user agent (IPMS-UA). The tasks performed by the InmCA in provision of
the IPMS abstract service are realized by the collective operation of the secondary objects comprising
the InmCA, the InmC-Mes and the InmC-Gtw.

4.5.1 Procedures of the InmC-MES - Realization Of Abstract Operations


The InmC-Mes must employ the (Inmarsat-C) MTS in a particular way, in order to provide the IPMS
abstract service to the InmC-user. Each InmC-Mes individually performs the procedures described in
this Section 4. Since the procedures performed by an InmC-Mes are similar to the procedures
performed by an IPMS-UA considerable detail has been omitted. Chapter 18 of X.420 should be
consulted for a detailed description of the operation of an InmC-Mes in the capacity of an IPMS-UA.

How an InmC-Mes concretely realizes the origination and reception ports it supplies is beyond the
scope of this document. (it is up to the manufacturer of the InmC-Mes). Realization is not bound to a
particular InmC-Mes component (DTE/DCE/DTE-DCE-interface). Ports may be realized inside the
DTE or DCE, or at the DTE-DCE interface, but will most likely be realized inside the DTE.

The InmC-Mes shall perform the originateIPM abstract operation by invoking the
LightMessageSubmission abstract operation. The operation ARGUMENTS and ERRORS are
described in clause 18.2.2 of X.420, and are subject to the redefinitions of Sections 2 and 3.2.

Whenever the Inmarsat-C MTS invokes the ReportDelivery abstract operation at a InmC-MES's light-
delivery port, the InmC-Mes shall invoke the ReceiveReport abstract operation. The operation
ARGUMENTS are described in clause 18.4.1 of X.420, and are subject to the redefinitions of Sections
2 and 4.1.

Whenever the Inmarsat-C MTS invokes the LightMessageDelivery abstract operation at a InmC-
MES's light-delivery port, and its content type argument denotes an IPM, the InmC-Mes shall invoke

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 79
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

the ReceiveIPM abstract operation. The operation ARGUMENTS are described in clause 18.4.2 of
X.420, and are subject to the redefinitions of Sections 2 and 4.1.

4.5.2 Procedures of the InmC-GTW - Mapping Of Abstract Information Objects


With respect to the IPM abstract service the tasks of the gateway are twofold. All information objects
supplied to the InmC-Mes, are reformatted into a textual representation by the InmC-Gtw, governed
by the rules described in Section 4.6. Some information objects associated with elements of service
which are provided 'on behalf of' the mobile user, in order to reduce the overhead across the satellite
link, and are handled by the InmC-Gtw.

The gateway acts on behalf of the user in constructing (and deriving) the MTS recipient OR-names
based on the IPM OR-descriptor. In particular this may be done when the free-form, or telephone-
number OR-descriptor is used. If an MTS OR-name is not filled in by the mobile user it must be filled
in by the InmCA, since the message containing an IPM cannot be transferred through the MTS based
on telephone-number or free-form OR-names.

See section 3.5 for a clarification of the numbers used in Tables 20 and 21.

Table 20: Mapping of Inmarsat-C IPM Heading Fields

Information Object if present If not present


this-IPM 1 5
originator 1 5
authorising-users 1 5
primary-recipients 1 5
copy-recipients 1 5
blind-copy-recipients 1 5
replied-to-IPM 1 5
subject 1 5
auto-forwarded 1 5
extensions 1 5
incomplete-copy 1 5
languages 1 5

Table 21: Mapping of Inmarsat-C IPM Body-Part Types

Information Object if present if not present


ia5-text 1 5
g3-facsimile 1 5
g4-class1 1 5
teletex 1 5
message 2 5
delivery-time 1 -
delivery-envelope 2 -
data
1 -
(forwarded-ipm)
mixed-mode 1 5
bilaterally-defined 1 5

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 80
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

nationally-defined 1 5
externally-defined 1 5

4.6 A Textual Representation of Abstract Information Objects


The majority of Inmarsat-C abstract information objects is placed into the [Data] fields of the message
packets transfered in the context of a From-mobile or To-mobile call procedure. A few protocol
elements are conveyed by available control fields in other packets.

4.6.1 General Encoding Rules


This paragraph describes the general rules covering the format of the [Data] field of message packets
transferred in From-mobile, To-Mobile and Mobile-To-Mobile interpersonal messaging. The general
format of the [Data] field is defined in Section 2. For the purpose of transferring an Inmarsat-C IPM by
means of the Inmarsat-C MTS this format is redefined to the following:

{MTS-envelope fields and IPM-heading fields}


"STX:<eol>"
{the IPM body-part}

The absolute minimum Inmarsat-C IPM is thus:

"STX:<eol>"

(No MTS-envelope fields and IPM-heading fields, no IPM body-part), this translates by gateway
procedures to an empty IPM being sent to a default recipient or list of recipients using default
attributes. Note that managing default values is a local implementation issue in the basic service,
exempt those values for which default values are supplied in the Inmarsat-C MTS abstract syntax
definition in Section 3 and the Inmarsat-C IPM information objects in Section 2.

The {MTS-envelope fields} represent the addressing and other information which relates to the
delivery of the message using the Inmarsat-C MTS. The {IPM-heading fields} represent the Inmarsat-
C IPM heading fields exchanged between IPM users. The {MTS-envelope fields and IPM-heading
fields} part is IA5 encoded (printable subset of the CCITT T61 recommendation with the most
significant bit or parity bit set to zero) up to and including the separator string "STX:<eol>". Directly
following the string "STX:<eol>" is the {IPM body-part} part which contains the message text or data
which need not necessarily be ia5 encoded.

The encoding syntax and rules for the MTS envelope fields are described in section 3.7. The
encoding syntax and rules for the IPM-heading fields followed a similar approach:

The general encoding syntax is described as follows:

[IPM-header] ::= [IPM argument element list][end of header]


| [end of header]

[IPM argument element list] ::= [<eol>][IPM argument element]


| [IPM argument element list]

[end of header] ::= [<eol>]"STX:"[<eol>]

[IPM argument element] ::= [IPM element keyword]":"[IPM parameter item]


| [IPM element keyword]":"[IPM parameter set]
| [IPM element keyword]":"[IPM parameter set]","
[IPM parameter set]

[IPM parameter set] ::= {[IPM parameter item] of related information. Each item is
separated by the semi-colon (";"). Table 14 is an

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 81
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

example of a parameter set.}

[IPM element keyword] ::= {IPM keywords are listed in the element keyword column of
tables 22 through 24}

[IPM parameter item] ::= [<value>]


| [parameter element]

[IPM parameter element] ::= [IPM parameter keyword]"="[<value>]

[IPM parameter keyword] ::= {Keywords appropriate to the IPM argument element are listed
in the parameter keyword column of tables 22 through 24.}

[<value>] ::= {The data appropriate for the [parameter keyword] is depicted
in the value column of tables 22 through 24.}

[<eol>] ::= <CR><LF> | <CR> | <LF>

The encoding rules operating on the syntax are as follows:

1. The content of an argument element is of free form. Spaces and tabs can be inserted before
and after parameter keywords, "=", "," and <value>. No space is allowed between [IPM
element keyword] and ":".

2. The content of an argument element can be contained on multiple lines provided the end of
each line is delimited by <eol> and a "-" (hyphen); spaces and tabs between or around these
two delimiter characters are allowed. Furthermore the delimiter rules for separating parameter
sets and contents of parameter sets must be observed across the continuation lines.

The following is illegal because the delimiter, ";" is not present after the "C=UK" parameter item:

TO:G=GHAZIA; S=AHMED; C=UK<CR><LF>


- O=INMARSAT

3. A <value> containing one or more of ":", ";", "," or leading or trailing spaces or tabs shall be
enclosed in double quotes. Double quotes shall also be contained in double quotes and
replaced with two consecutive double quotes.

Concatenation of two pieces of <value> is allowed so that a <value> can be continued on the
next line. The simple rule is that the concatenation text, quoted or unquoted strings, must be
specified consecutively and can be delimited by spaces or tabs, eg.

• free = """INM"<CR><LF>
- "ARSAT"";"
will yield free = "INMARSAT"; with ";" part of the value.

• free = INM <CR><LF>


- ARSAT will yield free = INMARSAT

4 Keywords can be encoded in two forms. The full or long form is the complete keyword depicted
in Tables 22 through 24. The short form is the underlined portion of the long form keyword.
Either form of keyword can be presented to an InmCA. Conversely, the choice of keyword
presentation by an InmCA is a local implementation issue. It is recommended that an InmCA
should, at least, allow its registered mobiles to decide on the actual keyword form of
presentation.

5. The InmCA shall accept all keywords in upper or lower or a mixture of cases on origination.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 82
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6. For upward compatibility with Inmarsat-C Message Headers and future enhancements,
unrecognised argument element keywords should be ignored and processing resumed from
the next argument element; i.e. next [<eol>][IPM argument element].

4.6.2 A Textual Encoding of Abstract Information Objects - Introduction to the Tables


The tables used in this section describe in detail the encoding of each abstract information object
defined in section 4.2. The 'Element' column provides a reference to the associated ASN.1 construct
of a particular element. The 'Element Keyword' column shows the keyword associated with a
particular element. The 'Concatenation or replacement of argument' column specifies what will
happen if a keyword is repeated in the heading part. In this case an argument following a repeated
keyword may either replace (replacement) the previous argument of the same keyword or the
argument may be added to the list of arguments following the same keyword (concatenation).
Received IPMs will not contain repeated keywords. The other columns are pertinent to the
parameters which can be part of a particular argument. The ‘parameter’ column gives the ASN.1
name of a parameter. A keyword may be associated with a parameter, in this case the 'parameter
keyword' column gives the keyword identifying the particular parameter. The ‘value’ column gives the
encoding of parameter values. Some parameters take values out of a set of predefined values, these
values are indicated between quotes. Other parameter values are more generic, such as printable-
string. Notice that all values shall be IA5 encoded. A generic value such as printable-string implicates
that the gateway has to convert between the IA5 encoding of parameter values and the encoding
used by the terrestrial network. The last column contains some specific remarks per parameter.

Each keyword, except the "TO:" and "FROM:" keywords, identifies a single information object
belonging to either the MTS (defined in Section 2) or belonging to the IPMS. The "TO:" and "FROM:"
keywords may however be followed by a MTS parameter or an IPM parameter, depending on the
MTS 'content-type' the parameter is either related to the IPM or to the MTS. A parameter following the
"TO" or "FROM" keyword belongs to the MTS if and only if the MTS content-type is not 'interpersonal-
messaging-1984' or 'interpersonal-messaging-1988', in any other case the parameter belongs to the
IPMS.

TO: G=Ghazia S=Ahmed;P=INMARSAT;A= ;C=UK, -- belongs to IPMS --


- free="INMARSAT CESD" -- belongs to IPMS --
CONTENT: ipm88

TO: G=Ghazia;S=Ahmed;P=INMARSAT;A= ;C=UK -- belongs to MTS --


CONTENT: unidentified

TO: free="INMARSAT CESD" -- free-form-name not allowed if content is not ipm --


CONTENT: unidentified

A parameter following the "TO:" or "FROM:" keywords may be followed by both MTS-flags and IPM-
flags. Hence, a purely IPM address (e.g. free-form-name or telephone-number) may be followed by
only a MTS-flag (delivery-notification requested)

TO: G=Ghazia;S=Ahmed;P=INMARSAT;A=;C=UK;RR,
free=INMARSAT CESD;DR

4.6.3 X.400 InmC-MES Address Specification


The specification of the InmC-MES IPM recipient address is a local implementation issue for the basic
implementation of the Inmarsat-C and X.400 interworking. The subject on the mobile address format
is for further study. This section provides some considerations to be aware of when sending
messages to the MES.

Terrestrial users forwarding messages to the InmC-MES must be informed on the required IPM
information. The address information must have the capabilities to route to the LES and be
recognised by the LES.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 83
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Mobile to Mobile message transfers can occur as follows:

1. The 'destination network' and 'destination extension' fields of the assignment request packet
specified the X.400 network together with the encoding of an X.400 InmC-MES address. In this
case analysis of the destination InmC-MES address may be required if the two InmC-Gtws
involved are not connected as private domains but via an administration domain. An example of
an undesirable effect is when an X121 numeric telex formatted address such as 581488800001
is specified. This may cause an administration domain to route the messages back to the
originating LES instead of forwarding them to the destination LES.

2. The InmC-MES is logged onto the ocean region served by a co-operating LES. In this case the
destination MES address is encoded by the originating LES. The format of the destination
address should have been bilaterally agreed between the two LES's.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 84
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Table 22: IPM Heading Fields

Concatenation
Parameter
Element Element Keyword or replacement Parameter Value Remarks
Keyword
of argument
If absent, the InmC-
this-IPM "OURREF:" replacement user-IPM-identifier printablestring Gtw inserts an
identifier.
<see
Originator "FROM:" replacement ORDescriptor <see ORDescriptor>
ORDescriptor>
authorizing- <see
"AUTHORIZING:" concatenation ORDescriptor <see ORDescriptor>
users ORDescriptor>
primary- <see <see
"TO:" concatenation RecipientSpecifier
recipients RecipientSpecifier> RecipientSpecifier>
<see <see
copy-recipients "CC:" concatenation RecipientSpecifier
RecipientSpecifier> RecipientSpecifier>
blind-copy- <see <see
"BCC:" concatenation RecipientSpecifier
recipients RecipientSpecifier> RecipientSpecifier>
replied-to-IPM "YOURREF:" replacement user-IPM-identifier printablestring
conversion may loose
subject "SUBJECT:" replacement SubjectField teletexstring
info
if present, this IPM is
"AUTOFORWARD:
auto-forwarded <to mobile only> <no parameters> the result of auto-
"
forwarding.
eg. 2nd body-pt of type
incomplete-copy "INCOMPLETE:" <to mobile only> ia5-string
'mixed' was lost"

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 85
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Table 23: Body-Part Fields

Element
Element Parameter Parameter Keyword Value Remarks
Keyword
"ia5"
body "BODYTYPE:" ia5-text
"ita2"
g3-facsimile "g3"
g4-class1 "g4"
teletex "ttx"
message "msg"
mixed-mode "mixed"
ascii-coded-decimal
"acd"
bilaterally- ascii-coded-
"bilat=" "ach"
defined hexadecimal
"bin"
binary
nationally-
"nat="
defined
externally-
"ext="
defined
Text after <eol> may
not be ia5, then
"STX:<eol>" "BODYTYPE:"
indicates encoding
used.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 86
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Table 24: ORDescriptor and RecipientSpecifier Fields

Parameter
Element Parameter Value Remarks
Keyword
ORDescriptor formal-name <see ORName> <see ORName>
The gateway will
free-form-name "free=" transform any of these
forms to an ORName,
telephone- which can be used in
"tel="
number the message envelope
<see <see
RecipientSpecifier ORDescriptor
ORDescriptor> ORDescriptor>
reply-requested "REP"

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 87
Chapter 4: Inmarsat C / Basic X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 5: Inmarsat-C / Enhanced X.400


Interworking

Contents

0 General ................................................................................... 5

1 Service Design Concepts ......................................................... 5


1.1 Introduction .......................................................................................................5
1.2 Mailbox Service .................................................................................................5
Figure 1: Local Mailbox Service ..............................................................................6
Figure 2: Multi-LESs Remote Mailbox Service ........................................................7
1.2.1 Mailbox Configurations..................................................................................7
1.2.2 Inmarsat-C and X.400 Message Confirmation ..............................................7
1.2.3 Advantages/Disadvantages for Using Mailbox Service .................................7
Figure 3: MTA Concept ...........................................................................................9
1.3.1 Unregistered MTA Services ...........................................................................9
1.3.2 Registered MTA Service ...............................................................................9
1.3.4 Confirmation of Message Delivery .............................................................. 10
1.3.5 Advantages / Disadvantages for Using MTA Service .................................. 10
1.4 Common X.400 Issues .................................................................................... 10
1.4.1 X.400 Message Size Reduction .................................................................. 11
1.4.3 Protocol Data Units ..................................................................................... 11

2 Mailbox Implementation ........................................................ 12


2.1 Configuration Flexibility ................................................................................... 12
Figure 4: Local Mailbox Implementation................................................................ 13
Figure 5: Local Message Store Mailbox Implementation....................................... 13
Figure 6: Remote Mailbox Implementation............................................................ 14
2.2 MES Software ................................................................................................. 15
Figure 7: MES Detail ............................................................................................. 15
2.3 Mailbox Operation ........................................................................................... 15

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 1
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.3.1 Access Information ..................................................................................... 16


2.3.1.1 MSAP Server Binding .......................................................................................................... 17

2.3.2 Retrieval ...................................................................................................... 17


2.3.2.1 Summary List ....................................................................................................................... 17

Figure 8: Mailbox Summary List Operation ........................................................... 18


Table 1: P7 SummaryRequest PDU Realization ................................................... 19
2.3.2.2 Fetch .................................................................................................................................... 20

2.3.2.3 Delete ................................................................................................................................... 20

2.3.3 Message Submission .................................................................................. 21


2.3.3.1 Probe Submission ................................................................................................................ 22

2.4 Auto-Summary ................................................................................................ 22


2.5 Multiple-LES Operation ................................................................................... 22
2.5.1 Message Identification ................................................................................. 22
Figure 9: Message Submission to Mailbox............................................................ 24
Figure 10: Indirect Submission of Delivery Report ............................................... 25
2.5.2 Message Status Enquiry .............................................................................. 25

3 MTA Implementation .............................................................. 26


Figure 11: MTA Implementation ............................................................................ 26
3.1 Multiple-LES Operation ................................................................................... 27
3.2 Unregistered MTA service............................................................................... 27
Figure 12: Out-of-Region Working - UnRegistered ............................................... 27
3.3 Registered MTA Service ................................................................................. 28
Figure 13: Out-of-Region Working - Registered .................................................... 28
3.4 X.400 Delivery Reports ................................................................................... 29
3.5 Message Identification .................................................................................... 29
3.6 MTA Service Operation ................................................................................... 30
3.6.1 MES-to-IWU X. 400 Message Transfers ...................................................... 31
3.6.2 IWU-to-MES X.400 Message Transfers ....................................................... 31
3.6.3 Registration .................................................................................................. 32

4 Protocol Data Units ............................................................... 33

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 2
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.1 MTA Service PDUs - MES to IWU .................................................................. 33


4.1.1 Message, Report, and Probe PDUs ............................................................. 33
4.1.2 MTARegister PDU ....................................................................................... 34
4.1.3 MTAProblemReport PDU ............................................................................. 34
4.2 MTA Service PDUs - IWU to MES .................................................................. 35
4.2.1 Message, Report, Probe, and MTAProblemReport PDUs ........................... 35
4.2.2 MTARegister Response PDU ...................................................................... 36
4.3 Mailbox Service PDUs - MES to MSAP Server ............................................... 36
4.3.1 DeletionRequest PDU .................................................................................. 37
4.3.2 MESRegister PDU ....................................................................................... 37
4.3.3 MessageSubmission PDU ........................................................................... 39
4.3.4 ProbeSubmission PDU ................................................................................ 39
4.3.5 RetrievalRequest PDU ................................................................................. 40
4.3.6 SummaryRequest ........................................................................................ 40
4.3.7 MbxProblemReport ...................................................................................... 41
4.4 Mailbox Service PDUs - MSAP Server to MES ............................................... 41
4.4.1 DeletionResult PDU ..................................................................................... 42
4.4.2 MesRegisterResponse PDU ........................................................................ 42
4.4.3 RetrievedMessage PDU............................................................................... 43
4.4.4 SummaryReport ........................................................................................... 44
4.4.5 SubmitResult ................................................................................................ 45
4.4.6 MbxProblemReport ...................................................................................... 46

5 Reference Definitions for Services ........................................ 46


5.1 Reference Definition of ASN.1 for MTA Protocol ............................................ 46
5.2 Reference Definition of ASN.1 for Mailbox Protocol ........................................ 47

6 Conformance ......................................................................... 51
6.1 General Requirements .................................................................................... 51
6.2 MTA Service ................................................................................................... 52
6.3 Mailbox Service ............................................................................................... 52

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 3
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6.4 X.400 Conformance ........................................................................................ 52

7 Encoding and Mapping onto Inmarsat-C Channels and Signals53


7.1 Outline............................................................................................................. 53
7.2 Detailed Procedures........................................................................................ 54
Figure 14: Inmarsat-C Message Format ............................................................... 54
7.2.1 Transmitting Station Procedure .................................................................... 55
Figure 15: Encoding Procedure ............................................................................ 55
7.2.2 Receiving Station Procedure........................................................................ 55
7.3 Mapping onto Inmarsat-C Signals ................................................................... 56
7.3.1 LES to MES Transfer ................................................................................... 56
7.3.2 MES to LES Transfer ................................................................................... 56
Annex A : Support of X.400/F.400 Elements of Service........................................ 58
1 Introduction ........................................................................................................ 58
2 Notation.............................................................................................................. 58
3 Mailbox Service .................................................................................................. 58
Annex B: Registration of Identifiers ....................................................................... 62
1 Interworking Unit and Message Service Access Point Numbers ........................ 62
2 X.400 Domains with Inmarsat Country ............................................................... 62
3 Private Registration Numbers ............................................................................ 62
Annex C: Compression Parameters ...................................................................... 63

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 4
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

0 General
This document describes an enhanced X.400 facility which integrates the Inmarsat-C messaging
system with the X.400 MHS.

Two mechanisms for interworking with Inmarsat-C are identified. One is based on forced-delivery of
messages between two Message Transfer Agents (MTAs) across the satellite link. The other
mechanism is based on a remote message store, whereby the mobile user initiates the message
transfer over the satellite link.

It is assumed that the reader is knowledgeable in both the operations of X.400 and of the Inmarsat-C
protocols. Before reading this document, it is recommended that the reader is familiar with the
Inmarsat-C Basic X.400 Internetworking SDM. For further information on Inmarsat-C protocols the
Inmarsat-C System Description Manuals are recommended.

1 Service Design Concepts

1.1 Introduction
This section outlines the main services that may be provided within the Inmarsat-C network under the
Inmarsat-C X.400 Enhanced Service. Two main services may be offered:

• Mailbox Service

• MTA Service

A LES may provide either or both the services. In the case of Mailbox Service. The mailbox may be
located locally or remotely. In order for both the MES and the LES to recognise, receive, transmit and
process the data used in these services the following presentation codes are used to identify the type
of service protocol being conveyed within the Inmarsat-C message:

- 83H Mailbox Service

- 82H Registered MTA Service

- 81H Unregistered MTA Service

1.2 Mailbox Service


This service allows the transfer of X.400 messages between a MES and a LES via an intermediary
message store (see Figure 1). LES functionality required to support the mailbox service is referred to
as the Message Store Access Protocol (MSAP) server. In this scheme, X.400 messages destined for
the MES are delivered to a message store which is connected to the terrestrial networks; the mobile
user can then retrieve the messages from the mailbox via the Inmarsat-C system and the terrestrial
networks. Conversely, X.400 messages destined for terrestrial destinations traverse from the MES to
the LES/MSAP Server and then onwards to the destination. Standardised protocols for mailbox
access are not suitable for use with Inmarsat-C (due to their excessive bandwidth demands, and its
non-realtime nature), so a special protocol has been defined.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 5
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: Local Mailbox Service

DELIVERY
REQUEST

MSAP SELECTIVE
RETRIEVAL
MAILBOX

The Mailbox service has two main advantages over delivering messages directly to the MES when
they arrive at the LES:

• Allows for the MES to be unavailable - possibly switched off, or the equipment in use for
another purpose.

• Selective retrieval - allowing the user to choose which messages are retrieved and in which
order1.

In practice, a MES subscriber has to register with a mailbox system operator. The registration details,
at the Mailbox System, including the definition of the MES address and translation to the equivalent
MES number is not in the scope of this document.

The MES subscriber should be provided with a list of LESs through which message submissions to
the X.400 terrestrial network and message retrievals or collections from the mailbox system can be
initiated. It is envisaged that a MES will be provided periodically with an updated list of LESs2.

1Some messages may be insufficiently important to justify the cost of receiving them at all; others
may be forwarded to a terrestrial user instead.

2 How a MES is informed is beyond the scope of this document and is considered as an issue
between the Mailbox/MSAP operation and their registered MES subscribers. Prior to the
commencement date, the MES subscriber shall ensure both the hardware and software on the mobile
are capable of supporting this Mailbox service.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 6
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 2: Multi-LESs Remote Mailbox Service

REQUEST

DELIVERY TERRESTRIAL SELECTIVE


NETWORKS
RETRIEVAL

MSAP

MAILBOX

1.2.1 Mailbox Configurations


There are a number of ways in which the mailbox service may be configured. Figure 1 shows a
configuration consisting of a Mailbox system within a single LES. This configuration shall be referred
as the Local Mailbox Service. Figure 2 shows a configuration consisting of multiple LESs with access
to the same Mailbox system via the terrestrial network; i.e. a MES can gain access via any of the
LESs. This configuration shall be referred to as the Remote Mailbox Service.

1.2.2 Inmarsat-C and X.400 Message Confirmation


Terrestrial-originated messages secured at the mailbox system are regarded as having been
delivered successfully. Therefore, a positive delivery report shall be returned to the originator if one
has been requested, even though the message has not been retrieved by the MES3.

For MES-originated messages (From-Mobile), the confirmation of the X.400 messages is a two-stage
process. In the first stage, a MES can be informed on the success of the message being forwarded to
the Mailbox System. This is achieved by setting the request-required element of the
MessageSubmission PDU (See Section 4.3.3). Subsequently the success or failure of the delivery at
the destination is known from the X.400 delivery report. However this delivery result must be indicated
within a X.400 message4.

1.2.3 Advantages/Disadvantages for Using Mailbox Service


The advantages in employing the Mailbox service concept are:

• Most efficient use of satellite link due to selective transfer (and because Delivery Reports do
not need to transit the link);

3 The management of the messages within the mailbox system is not within the scope of this
document, especially with regards to the removal of messages due to outage or storage resource
congestions.

4 The Inmarsat-C confirmation packet is only used in the case when a message submission operation
fails. For other Mailbox operations, if a result is required, this is returned in the form of a PDU.
Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 7
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

• Suitable for use with mobiles which are only intermittently available - such as the land mobile
"briefcase terminal" or small maritime installations where power consumption is an issue;

• Messages may be retrieved via terrestrial networks where this is more convenient or cost-
effective than using the satellite link. Many mobile users will spend part of their time at a home
base location and will benefit from having a single messaging system whether they are at home
or out in the field; and,

• Message integrity is assured even where the mobile DTE may be unreliable - portable PCs
have limited storage capacity, and where used in harsh environments or without mains power data is
often lost. Messages are retained in the central Message Store until deleted by the user and
may be retrieved again if lost from the mobile.

The disadvantages in employing the Mailbox service concept are:

• Increased delay before messages are made available to the mobile user;

• Limited suitability where single MES DCE is shared between multiple users or activities;

• Limited compatibility with existing software implementations. Operation at the "P1" (MTA) level
is provided as a published interface by many manufacturers and is widely used by suppliers of
EDI applications, gateways etc. Operation at the "P3" (UA only) level is less standard;

• Relatively high development costs, due to a complex proprietary protocol; and

• Provides X.400 services only to those MES subscribers who are registered with a mailbox
system associated with one or more LESs.

1.3 MTA Service

This service, as in the Mailbox service, allows the transfer of X.400 messages between MESs and
LESs. However, the MTA service adopts the approach to deliver messages directly to the MES, rather
than waiting for the mobile user to request them - "push" rather than "pull". A typical configuration is
shown in figure 3. In this configuration, there is nothing Inmarsat-specific at the X.400 level. The
equipment at both the LES and mobile comprise of standard X.400 MTAs, with the Reliable Transfer
Service and underlying OSI communications stack replaced with a process of encapsulating the
messages and transmission by means of the normal Inmarsat-C message protocol5. There is also an
InterWorking Unit (IWU) which provides services to integrate the use of X.400 messages over the
Inmarsat-C system.

It is also possible to use this configuration with just a User Agent (rather than complete UA/MTA
combination) at the MES.

5For more information, see CCITT Blue Book - Data Communication Networks Message Handling
Systems, Recommendations X.400-X.420
Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 8
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 3: MTA Concept

DELIVERY

MTA
IWU

TEMPORARY
QUEUE

The MTA service has two tiers of service:

• UnRegistered MTA service

• Registered MTA service

1.3.1 Unregistered MTA Services


The Unregistered MTA Service allows MES subscribers to send and receive X.400 messages without
the need for prior LES registration. An unregistered MES subscriber needs only to identify a LES (via
LES Bulletin Boards) that provides this unregistered service in its ocean region. Conversely, a LES
can send X.400 messages to an unregistered MES if the MES had either been commissioned or
logged in with the Inmarsat-C X.400 Enhanced Service capability.

A LES offering the MTA Unregistered Service should advertise this service in its Bulletin Board
broadcast. If the Enhanced X.400 supported indicator located at Byte 2 of the TDM descriptor field of
the Bulletin Board is set, the LES is providing the MTA unregistered service. Conversely, a LES can
check whether an X.400 message can be delivered to a particular unregistered MES. If the Enhanced
X.400 supported indicator located at the 'Options' field of the MES's 'Class' descriptor is set, the MES
supports the MTA Unregistered Service.

1.3.2 Registered MTA Service


For registered MES users, a LES can provide additional services to those for its unregistered users.
These include:

• Redirection of messages, e.g. large messages above a certain size, to another destination;

• Reformatting messages to further reduce the size of satellite transmissions. This includes the
translation into a non-X.400 format (e.g. IA5 text description containing only the FROM
information and the message text ); and

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 9
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

• Automatic generation of confirmation report once the MES has acknowledged the reception of
each message in accordance with the Inmarsat-C protocol6.

For the registered Inmarsat-C X.400 Enhanced Service, contractual registration will enable a MES to
have knowledge on the LESs that provide the X.400 MTA service.

1.3.4 Confirmation of Message Delivery


For the terrestrial telex network, the Inmarsat-C confirmation indicates the success or failure of the
delivery to the designated destination. However this schema is not practical for the MTA service
design due to logistical reasons, such as the possibility of receiving multiple delivery reports for one
single X.400 message delivery, and the conveyance of the X.400 delivery failure reason and
diagnostic codes which are different to those defined for the Inmarsat-C message transfer protocol.
Therefore, the confirmation of a delivery can only be known through the evaluation of an X.400
delivery report; the request for the X.400 delivery report being indicated within the X.400 message7.

In the MTA service, when a MES transfers an X.400 message for delivery to the X.400 network, the
initial LES's clear packet shall indicate that the IWU will make attempts to submit the message to the
IWU's MTA. If the MTA does not accept the message, the IWU shall generate and return an X.400
delivery report back to the MES. Once a message has been accepted by the MTA, the LES/IWU will
have no further visibility on the message. Message status inquiries during this period will be
responded with an UNK condition.

If any X.400 delivery reports are returned, these are delivered to the MES individually or combined
into a single delivery report, using the Inmarsat-C messaging protocol.

1.3.5 Advantages / Disadvantages for Using MTA Service


The advantages in employing the MTA service concept are:

• Very minimal development effort if only MTA-to-MTA connection required;

• Easiest integration with existing applications software;

• Convenient support for multiple users or multiple applications on a single MES; and,

• Provides X.400 services to both registered an unregistered MES subscribers.

The disadvantages in employing the MTA service concept are:

• Possible higher cost of software for mobile system (although offset by the ability to use off-the-
shelf applications);

• No selective retrieval; junk mail filtering and queue prioritisation is limited to simple constraints
that can be programmed into the MTA at the LES;

• Less efficient use of the space segment, due to lack of selective retrieval and the need to pass
Delivery Reports across the link; and

• Less satisfactory for the case of MESs which are only intermittently available.

1.4 Common X.400 Issues

6 This may also be offered to unregistered subscribers during the period the MES is logged in.
7 Inmarsat-C confirmation packet is not used and the specification of the Confirmation Request bit in
the Message Header is ignored.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 10
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

There are a number of issues that relate to both the MTA and Mailbox Service:

• X.400 Message Size Reduction;

• MES X.400 addressing; and

• Protocol Data Units.

1.4.1 X.400 Message Size Reduction


One objective for the Inmarsat-C X.400 Enhanced Service is to reduce the size of X.400 messages in
order to obtain more efficient use of the space segment and to reduce the cost incurred for the
satellite transfer. The size of an X.400 message can be effectively reduced by taking into account the
following considerations:

• An Inmarsat-C message can be encoded to contain multiple PDUs. This improves efficiency
when a single transmission generates multiple transactions;

• In the case of X.400 message packaging, the following encoding actions are specified:

• The list of recipient addresses shall be encoded either in the envelope (P1) or content (P2)
portion (but not both) of an X.400 message. The envelope portion should be used in preference
if none of the recipients require special IPM categorisation, e.g. primary recipients, copy
recipients, etc.;

• In the To-Mobile direction, encode only those recipient addresses which are destined to one
mobile. The recipient list in the envelope portion contains marked recipients for which the IWU
is responsible. Only the recipients associated with the target mobile need be sent;

• Where the recipient list in the content portion contains a list of blind recipients, this list can be
removed or reduced if all or some of the destination MES addresses are either primary or copy
recipients, respectively;

• In the From-Mobile direction, the originator address shall be omitted and be generated at the
LES or the IWU or MSAP Server;

• Optional attributes should not be specified when the default values suffice. Where attributes are
present specifying the default values, these shall be removed.

• In the case of X.400 delivery report transfer, the following encoding actions are specified:

• In the case of X.400 delivery reports being returned to the MES, where practical the IWU shall
combine multiple delivery reports, with the same message submission identifier. This operation
will need an imposition of a short period of time subject to the CCITT F.410 definition of quality
of service for collection and summarisation of all the returning X.400 delivery reports.

1.4.3 Protocol Data Units


The Protocol Data Units (PDUs) are the information packets that are used to carry out the operation of
the system. Section 4 describes the structures of the protocol data units that interface between the
MES and the LES. There are two categories of PDUs:

• Data PDUs; and,

• Acknowledgement PDUs.

Data PDUs contain service processing details such as messages, summary and delete requests, etc.
Acknowledgement PDUs report on the result of the operation on the associated Data PDU. An

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 11
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Inmarsat-C message can contain a number of PDUs (with the exception of the registration PDUs8),
subject to the Inmarsat-C message size restriction. The clear packet shall be used to convey the
arrival of an Inmarsat-C message.

2 Mailbox Implementation
The mailbox service comprises two logical units:

• A Message Store - handling message storage and interface to the terrestrial X.400 networks for
submission and delivery; and

• An MSAP Server - which decodes the protocol used across the Inmarsat-C system into the
required operations on the mailbox.

2.1 Configuration Flexibility


The choice of implementation centres on either the construction of a dedicated Inmarsat-C specific
mailbox system, or the use of a standard X.400 Message Store accessed via the P7 protocol with a
MSAP Server which maps the bespoke access protocol onto the standard P7 operations. The options
for implementing a mailbox configuration are:

• Local mailbox implementation:

- MSAP which interfaces the existing store and forward equipment using a
dedicated protocol, as shown in Figure 4.

- MSAP which interfaces to a proprietary message store using a standard protocol


such as P7, as shown in Figure 5.

• Remote mailbox implementation:

- MSAP only at LES. Remote message store, connected by P7, as shown in Figure
6.

The choice between the types of implementation is a cost/performance, trade-off to be made by each
group of LES operators and the availability of an existing message store system. An entirely
dedicated implementation (shown in figure 4) will lead to simpler equipment at the LES; however, the
development costs are likely to be lower for the P7 approach (shown in Figures 5 and 6). In the latter
case, the LES equipment can be produced in small numbers, and the implementation of the front-end
processing to the P7 protocol is simpler than implementing the entire mailbox store. The cost savings
in buying proprietary the storage capability 'off the shelf' are likely to far outweigh the additional
hardware cost due to lower efficiency.

8 For more information see Chapter 4


Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 12
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 4: Local Mailbox Implementation

LES
TERRESTRIAL
NETWORKS
X.400
GLOBAL
MES DCE
BACKBONE MSAP

SPECIAL
PURPOSE
MAIL BOX
PROTOCOL SPECIAL
PURPOSE
USER AGENT

Figure 4 is an extension to an existing LES implementation. The LES will have implemented an
existing message store and forward capability, including message routing and transfer between the
MESs and terrestrial networks, this can be used by the MSAP server to provide a mailbox service.

Figure 5: Local Message Store Mailbox Implementation

LES

MSAP MES DCE


(P7)
SPECIAL
TERRESTRIAL PURPOSE
X.400 NETWORKS MAILBOX
PROTOCOL SPECIAL
GLOBAL (P7) Message Store
PURPOSE
BACKBONE USER AGENT

Figure 5 is similar to the local mailbox implementation with the exception that a X.400 message store
system is located within or is an integrated part of a LES.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 13
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The description for implementing the Mailbox Service concentrates on the MSAP Server functionality.
Figure 4 pictures the LES as being responsible for the delivery and reception of X.400 messages.
Figure 5 shows the responsibility as being with the MSAP Server. In terms of functionality, both
statements are identical.

The Mailbox access protocol and procedures have been specified in terms of a P7 message store,
but this does not preclude the possibility of using this specification to access a proprietary mailbox
system. Interworking with MESs rely on the special-purpose protocol specified in Section 4; the P7
protocol (if used) is not visible to the mobile user.

Figure 6: Remote Mailbox Implementation

PRIVATE
MESSAGE
STORE

X.400 P7
GLOBAL TERRESTRIAL MSAP
LES MES DCE
BACKBONE NETWORKS
P7
P1 OPERATOR
SPECIAL
PROVIDED
MESSAGE STORE PURPOSE
MAILBOX
P7 PROTOCOL
SPECIAL
PURPOSE
OTHER UA USER AGENT
(TERRESTRIAL)

Figure 6 provides the capability of accessing both public and private message store systems.

The Remote Mailbox implementation enables the LES and its MSAP Server to provide MES
subscribers with access to message store systems that could be reached by the LES. An obvious
disadvantage of remote access capabilities is the response time which is affected by both the volume
of information conveyed and the remoteness of the mailbox system.
Use of a standard Message Store also allows for some further options, shown in Figure 6.

• Possibility of access from terrestrial User Agents. If a standard Message Store is used, it may
be accessed by conventional UAs via the terrestrial networks - thus allowing a terrestrial user to
process messages on behalf of the mobile user, particularly for the case of messages which
are too large or otherwise unsuitable for downloading into the MES. This also allows for the mobile
user to by-pass the satellite link when in a location where lower cost access to the terrestrial
networks is available.

• Flexibility to interwork with customer-provided message store. Organizations which already


have X.400 systems for their non-mobile users may wish to incorporate their mobile users into
the same system - particularly for the case of land-mobile MESs where the user may only be
away from fixed installations for limited periods. If the LES installation is P7 based, this allows
the LES operator the option to offer an alternative form of service where the mailbox resides on
the customer's Message Store and only the front-end processing is provided by the LES
operator. Similarly, it may be the case that the LES operator already provides public Message
Store services unconnected with their satellite operations; in this case, the cost of providing and
administering a separate store for Inmarsat purposes can be avoided.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 14
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.2 MES Software

Figure 7: MES Detail

PC
INCOMING
MESSAGES,
SUMMARIES TRANSMISSION X.400
MANAGEMENT
MES UTILITY UA

SUBMITTED
MESSAGE

INTRAY

OUTTRAY

Given the message store access protocol being used, some bespoke software will be necessary.
However, it may be possible to reduce costs and provide more functionality by using an off-the-shelf
X.400 user agent (Figure 7). A bespoke utility would be provided to manage the transmission and
reception of messages - when complete messages are received they are placed in 'intray' files on the
DTE's local storage, where they can be processed by the standard User Agent. In the absence of
generally accepted APIs, such an implementation would typically be customised for a particular
manufacturer’s User Agent. Some practical facilities that could be suitable for implementation at the
MES are:

• Report on the messages queued at the mailbox. This feature maintains an ongoing summary
report on the messages that have been retrieved from the message store, viewed by the MES
subscriber, and are still at the message store. This summary report is updated from summary
inquiries made at the mailbox system. The maintenance of a summary report saves the MES
subscriber from making frequent full inquiries to the message store; and,

• Report on the delivery results by correlating the X.400 messages sent by the MES with the
X.400 delivery reports returned from the X.400 network. This feature is extremely useful for
tracking those message submissions to more than one destination (See Sections 4.3 and 4.4).

2.3 Mailbox Operation


Mailbox operations are carried out via Protocol Data Units (PDU) described in Section 4. The P7
message store interfaces form the basis for a common set of PDUs that can be used across the
different suggested Mailbox Service implementations.

In general, the four basic MSAP Server operations and their sub-services are:

• Access information

• Retrieval

- Summarise

- Fetch

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 15
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

- Delete

• Message Submission

• Auto-Summary

2.3.1 Access Information


Access information is required in order for the MSAP Server to interface with the desired Mailbox
system on the MES's behalf. In the case of a Registered Mailbox MES, where all its Mailbox access
details are registered at the MSAP Server, there is no necessity for a MES to send registration
information. In the case of an unregistered MES the access information must be conveyed to the
MSAP Server before any mailbox operation requests can be initiated (in form of a MESRegister PDU -
see Sections 4.3.2 and 4.4.2). In all cases, access information is also used by the MES to amend
existing registered values stored at the MSAP Server (also by means of MESRegister PDU).

In practice there may be volatile and permanent sets of information held at the LES. In such cases,
the MES will be allowed to amend the volatile set but not the permanent set. This volatile information
is defined in the MESRegister PDU. Permanent information can only be amended by the LES
operator. An example of permanent information is the additional mailbox system's registration details
that are included automatically by the LES when communicating with the target mailbox system.
Therefore, the control of the registration details is a MSAP Server implementation consideration; i.e.
the MSAP Server may need to parse the registration command to ensure prohibited items have not
been specified.

The sequence of events in a registration operation is as follows:

• If the MES is unregistered, or a registered MES wishes to change its volatile registration
information, the MES transmits a MESRegister PDU (within an Inmarsat-C message) to the
LES. This operation needs only be issued once for all subsequent Mailbox request operations
(unless volatile access information needs to be subsequently changed).

• The LES shall accept the Inmarsat-C message by transmitting a clear response. The clear
packet shall contain the LES allocated reference number for this PDU. Acceptance at this stage
is not a signal for the MES to proceed with any other mailbox operations.

• The MES shall wait for the corresponding confirmation packet from the LES before proceeding
with any other mailbox operation requests.

• The presentation code shall enable the LES to route the Inmarsat-C message to the MSAP
Server for processing (depending on the implementation of the MSAP Server, a quick response
may not be readily available).

• The MSAP Server extracts the MESRegisterResponse PDU from the Inmarsat-C message and
processes the given registration details by updating the MSAP's and/or the Mailbox System's
registration database.

• The MSAP Server shall return a MESRegisterResponse PDU indicating the success or failure
of the registration PDU for the LES to send to the MES. The MESRegisterResponse PDU
contains the PDU reference number of the associated MESRegister PDU (the PDU sequence
number is not required because there can only be one PDU within the Inmarsat-C message).

• The MES can initiate subsequent mailbox operations only when the registration has been
successful.

The Inmarsat-C "From-Mobile Message Transfer" protocol is used to initiate the access information
operation. All the mentioned PDUs are contained in the Data portion of the message packet and the

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 16
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Presentation and Additional Information fields of the Message Header are set to 81H and X.400
destination, respectively.

If a MESRegister PDU has to be issued by the MES, it must first be accepted by the LES before any
other PDUs can be send. Therefore this PDU, if issued, cannot reside with the other types of PDUs
and must be the only PDU specified in an Inmarsat-C message.

2.3.1.1 MSAP Server Binding

A MSAP Server implementation should provide for the facility to store the set of bind details for each
of its registered MES subscribers' mailbox systems. Where a MES has a choice of mailbox systems,
the MESRegister PDU is required to identify the desired mailbox system unless a default system has
been indicated at the MSAP Server. The MESRegister PDU allows the identification to a particular
Mailbox system using either the PresentationAddress, the X.121-Address, and/or the NetworkType. A
MES can also use this PDU to amend the registration details stored at the MSAP Server.

After a successful access operation, the MES is said to be connected 'logically' with the specified
Mailbox system until the next access operation. The connection between the MSAP Server and the
mailbox system is an implementation issue. A Basic and Local Mailbox implementations may have the
connection 'opened' from one Mailbox operation to another. The connection is closed either when
requested by the MES or when the MES logs out. However for the Advanced Mailbox implementation
and for remote mailbox systems, it may not be practical for the connection to be in the 'open' state.
Therefore each subsequent mailbox operations will have to be wrapped between bind and unbind
operations.

Since the MES cannot proceed with any other mailbox operations until the result of this operation is
known, the Inmarsat-C message can only contain this PDU and no other types. If this PDU is found to
reside with other PDUs in the same Inmarsat-C message, the access operation is rejected with the
MbxProblemReport PDU specifying "bad-message".

2.3.2 Retrieval
The retrieval operation enables a MES subscriber to obtain a summary of messages at the message
store, to collect messages from the message store, and to delete messages from the message store.

2.3.2.1 Summary List

This section describes the presentation of a summary list report which is suitable for use with the
Inmarsat-C protocol. This description may be applicable to the implementation of the Basic and the
Local Message Store Mailbox Services but may be unsuitable for communication with public or other
private message stores9.

9This is because certain summary constructions may require a lengthy dialogue between the MSAP
and the Mailbox system and certain summary filters may not be supported by the mailbox system.
Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 17
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 8: Mailbox Summary List Operation

SUMMARY
1: 2: 3: 4:

REQUEST
1, 2, 4

MESSAGE DATA
2 1

The intent is the message summary is very small - the bare minimum of information to allow the user
to determine whether or not to retrieve the message. Hence a summary includes the first few words of
the message subject; values of priority, importance and sensitivity indications; date/time; the sender's
identity; and a reference to be used to request the full message. Two modes of operation are
specified:

• Message summaries are only sent when explicitly requested by the mobile user; and,

• Summaries are automatically sent by the LES either when the MES has logged in to the
system, and subsequently when new messages arrive.

It would be an inefficient use of resources to announce each new message when it arrives, as the
overheads of the call set-up might exceed the amount of data to be actually transmitted describing the
message. A set of criteria may be established that will cause the transmission of all outstanding
message summaries. These criteria might include:

• Length of time that the oldest message has been waiting;

• Values of Importance or Priority attributes of the messages;

• Originator addresses;

• Content type (IPMS, EDI etc.); and

• Volume of message summaries to be transmitted.

Similarly, for very small messages it is inefficient to send first a summary and then the whole message
- it is more efficient to send the whole message in the first place. Small messages which are sent
along with the summary are said to have been transferred completely and successfully to the MES.

As mentioned, the provision of a concise report depends on the message store. In order to compile
the details mentioned in this section, the MSAP Server will have to open a dialogue with the message
store. In some cases (and depending on the message store implementation) it may even be
necessary to fetch the (small size) messages in order to determine the information; e.g. message
size, subject, etc. Therefore such a concise report will likely to succeed with Basic or Local Mailbox
implementations, rather than the Advanced implementation.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 18
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

For the compatibility with the use of the P7 protocol, Table 1 identifies the realisation of the
MessageSummary PDU using the services of the Message Store Retrieval port as defined in CCITT
X.413.

Table 1: P7 SummaryRequest PDU Realization

MessageSummary
MS Service MS Service Attribute Description
Attribute
Ms-reference-number List Sequence-number
Time when the message is entered
Arrival-time List Creation-time
into the message store
A large message is one whose
envelope and content exceed the
Content-length size limitation of an Inmarsat-C
List message. Therefore if the size of the
Too-large-to-retrieve Message-delivery
Fetch content exceeded a certain
envelope threshold, the message may have to
be fetched to check that it can be
transmitted over the satellite.
Originator List Originator-name
List and
Content-type
summarised
Content-Length List Content-length
The subject is in the content portion
of the message. A fetch operation
Subject Fetch may be necessary to extract the
subject field from the IPM
information.
Importance
Sensitivity
For messages less than 50
characters, the whole message is
Message-text Fetch
fetched and send as part of the
summary.

The Inmarsat-C "From-Mobile Message Transfer" protocol is used to initiate the summary operation.
All the mentioned PDUs are contained in the Data portion of the message packet and the
Presentation and the Additional Information fields of the Message Header are set to 81H and the
X.400 destination respectively. The sequence of events in a summary operation is as follows
(assuming that the MES has a logical connection with the desired mailbox system):

• MES transmits a SummaryRequest PDU within an Inmarsat-C message;

• The LES shall accept the Inmarsat-C message by transmitting a clear response. The clear
packet shall contain the LES allocated reference number for this Inmarsat-C message. This
clear response is not an indication of success nor that a summary report will be returned. This
response is an indication that the PDU has been accepted and will be forwarded to the MSAP
Server for processing;

• The presentation code shall enable the LES to route the Inmarsat-C message to the MSAP
Server where this PDU will then be extracted;

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 19
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

• The MSAP Server shall formulate the required summary report by inquiring at the target
mailbox system;

• A null summary report or a null report on a particular message is generated if the MSAP Server
encounters difficulties obtaining the information from the Mailbox System; depending on the
severity and the type of error encountered; and

• The MSAP Server shall always construct a MessageSummary PDU for the LES to transmit to
the MES.

2.3.2.2 Fetch

The Inmarsat-C "From-Mobile Message Transfer" protocol is used to initiate the fetch operation. All
the mentioned PDUs are contained in the Data portion of the message packet and the Presentation
and the Additional Information fields of the Message Header are set to 81H and the X.400 destination,
respectively. The sequence of events in a fetch operation is as follows:

• A list of message store reference numbers is required to identify the messages for retrieval,
therefore, the MES should have a summary report on the messages at the message store prior
to the fetch operation. If not, the MES should obtain a report as mentioned in Section 2.3.2.1;

• The MES transmits a RetrievalRequest PDU (within an Inmarsat-C message) listing the choice
of message store reference numbers for the MSAP Server to fetch from the message store;

• The LES shall accept the Inmarsat-C message by transmitting a clear response. The clear
packet shall contain the LES allocated reference number for this Inmarsat-C message.
Acceptance at this stage is not an indication that the list of required messages will be, or can be
delivered;

• The presentation code shall enable the LES to route the Inmarsat-C message to the MSAP
Server where this PDU will then be extracted;

• The MSAP Server shall formulate the necessary mailbox request(s) to retrieve the desired
messages by passing the whole list of message references (or one at a time) to the mailbox
system, via the logical connection;

• For each successful retrieval, the MSAP Server encloses the retrieved message in a
RetrievedMessage PDU. The RetrievedMessage PDU shall include the PDU reference number
of the originating RetrievalRequest PDU for correlation purposes. A MSAP Server
implementation may optionally pack a number of these PDUs into one Inmarsat-C message to
reduce overheads. A RetrievedMessage PDU is also formulated to report on each unsuccessful
retrieval. The delivery order of the RetrievedMessage PDUs cannot be guaranteed to be the
same as the given list.

2.3.2.3 Delete

The Inmarsat-C "From-Mobile Message Transfer" protocol is used to initiate the delete operation. All
the mentioned PDUs are contained in the Data portion of the message packet and the Presentation
and the Additional Information fields of the Message Header are set to 81H and X.400 destination,
respectively. The sequence of events in a delete operation is as follows:

• A list of message store reference numbers is required to identify the message(s) for deletion.
Therefore, the MES should have a summary report on the messages at the message store. If
not, the MES should obtain a report as mentioned in Section 2.3.2.1;

• The MES transmits a DeletionRequest PDU (within an Inmarsat-C message) listing the choice
of message store reference numbers for the message store to delete. These reference
numbers must correspond to the reference numbers detailed in the summary report;

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 20
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

• The LES shall accept the Inmarsat-C message by transmitting a clear response. The clear
packet shall contain the LES allocated reference number for this PDU. Acceptance at this stage
is not an indication that the list of required messages will be or can be deleted;

• The presentation code shall enable the LES to route the Inmarsat-C message to the MSAP
Server where this PDU will then be extracted;

• The MSAP Server shall formulate the necessary mailbox request(s) to delete the desired
message by passing the whole list of message references (or one at a time) to the mailbox
system, via the logical connection;

• The MSAP Server shall gather the results of all the deletion operations to formulate and return
the DeletionResult PDU to the MES.

2.3.3 Message Submission


The message submission operation enables a MES subscriber to send a message to the X.400
network via the LES/MSAP Server, and the Mailbox system. The Inmarsat-C "From-Mobile Message
Transfer" protocol is used to initiate the message submission operation. All the mentioned PDUs are
contained in the Data portion of the message packet and the Presentation and the Additional
Information fields of the Message Header are set to 81H and X.400 destination, respectively. The
sequence of events in a submission operation is as follows:

• MES transmits a MessageSubmission PDU within an Inmarsat-C message;

• If the delivery result is required, the MES should indicate this requirement within the X.400
structure. Returning X.400 delivery reports will be deposited in the message store for
subsequent access by the MES;

• The LES shall accept the Inmarsat-C message by transmitting a clear response. The clear
packet shall contain the LES allocated reference number for this PDU. Acceptance at this stage
is not an indication that the message has been successfully forwarded to the X.400 network via
the mailbox system;

• The presentation code shall enable the LES to route the Inmarsat-C message to the MSAP
Server where this PDU will then be extracted;

• The MSAP Server shall formulate the necessary mailbox request(s) to perform the indirect
message submission to the X.400 network via the mailbox system;

• If the message cannot be submitted via the mailbox system or if the MES requires a mandatory
acknowledgement, the MSAP Server shall generate a SubmitResult PDU to return the failure
reason or success code to the MES. Otherwise the submission operation is deemed to be
completed;

• As mentioned in Section 2.4, Message Status Inquiries are not fully supported.

A single Inmarsat-C message can accommodate a number and a mixture of the other PDUs to reduce
satellite overheads; so long as the total size of all the PDUs is within the Inmarsat-C message size
limit10. Each PDU shall be identified implicitly by a PDU reference number; i.e. the PDU definition
does not allocate a field to hold this PDU reference number. The use of the PDU reference number is
to correlate the success or failure of PDUs sent by the MES with PDU responses returned by the LES
and vice versa. Since the MESRegister and the MESRegisterResponse PDUs occupy a single
Inmarsat-C message, their PDU reference numbers will simply be the Inmarsat-C message reference
numbers and "001". The MbxProblemReport PDU is used for reporting unrecognised PDUs, including
new PDU types which are not currently supported.

10 Except for the MESRegister and the MESRegisterResponse PDUs


Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 21
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.3.3.1 Probe Submission

The scenario for probe submission is similar in context to the message submission scenario in
Section 2.3.3. The only difference is that the ProbeSubmission PDU is used by the MES to send the
Probe message.

2.4 Auto-Summary
Auto-Summary is a service whereby the MSAP Server makes a periodic check for new messages
arriving at its message store(s). Each new message is checked against the MES registration details
such as Message Inclusion Criteria and Expedited Transmission Criteria to determine whether
unwanted messages should be ignored and to generate an immediate transmission of a summary
report to the MES; the report can only be sent if (and when) the MES has logged in.

2.5 Multiple-LES Operation


The existing Inmarsat-C service allows users to 'roam' from one region to another without the need to
subscribe separately to the service in the new region. It is clearly desirable to retain this characteristic
for the X.400 service. However, in the case of the mailbox service it is not possible to treat X.400
interworking in an equivalent manner to interworking with other networks - the mailbox fundamentally
resides at a particular physical location, and all transactions have to be routed through it. Also, the
nature of the mailbox operation (with summaries and subsequent retrieval requests) involves a
number of related transactions - this requires that only those MSAPs that can service the particular
mailbox system be used for all of the connected transactions; the worst case is when there is only one
MSAP Server that can communicate with the Mailbox.

As mentioned, a registered MES must be provided with a list of LESs which the MES can login for the
Mailbox service. A MES identifies itself to the mailbox via one of the following methods:

• In the case where the MES is registered at the mailbox serviced by the LES (the Basic and
Local Mailbox implementations), the MES can usually initiate mailbox requests such as
message submissions and retrievals without further need for registration. The LES conveys the
requests to its Basic or Local mailbox implementation for verification and processing;

• In the case where the MES requires the co-operation of a LES's MSAP Server to access the
remote MSAP Server and the mailbox (Advanced Mailbox implementation), the MSAP Server
interworking interface is for further study.

If a MES is registered with more than one mailbox systems that can be accessed by the same MSAP
Server, then either a registered default mailbox system is used or for the MES to indicate its choice
via the MESRegister PDU.

2.5.1 Message Identification


In the course of traversing between the MES and the X.400 network, a message is tagged with
reference numbers and identities. This section provides a recommendation for the generation of
message reference in the path between the MES and the LES or MSAP Server.

There are two protocols that rely on message identifiers in the system - the underlying Inmarsat-C
message transfer protocol, and the mailbox protocol. In the case of the Inmarsat-C message transfer
protocol, each Inmarsat-C message is tagged with a message reference number when the LES
accepts the message (conveyed in a 'clear' packet on the LES TDM channel). In the case of the
mailbox protocol, each PDU within an Inmarsat-C message is tagged with a sequence number, which
is used to correlate requests with responses.

There is an essential requirement which necessitates the need to adopt a coherent relationship
between the various reference numbers and identities. This requirement is for the correlation between
message submission and its subsequent delivery report(s) from the X.400 network. The fact that a

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 22
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

delivery report is stored at the Mailbox means a MES subscriber must be able to correlate it with the
message PDU that was sent previously. With the Mailbox design proposed in this document, the MES
subscriber has visibility only on the PDU and the LES reference numbers. References are created at
the following areas:

• Each PDU within an Inmarsat-C message that is created at the MES is tagged with an implicit
sequence number;

• By the Inmarsat-C protocol definition, an Inmarsat-C message is tagged with a message


reference number when the LES accepts the message.

• When the MSAP Server performs an indirect message submission at the Mailbox system, a
message reference number can be assigned as reference to the entry made at the Mailbox
system or message store;

• By the X.400 protocol definition, upon submission to an MTA the message is tagged with a set
containing a message submission identifier, message submission time, and optionally a content
identifier.

To provide a mechanism for the correlation of all of these references, this section recommends the
following approach:

• From-Mobile direction

• Each PDU is implicitly assigned a sequence number within a byte range; i.e. 1 to 255. This
limits the number of PDUs within an Inmarsat-C message to 255. (Sequence number zero is
reserved).

• The PDU reference number shall be a combination of the message reference number supplied
by the LES in the clear packet and the PDU sequence number. The LES reference number
being the most significant digits and the PDU sequence number being the least three significant
digits.

• The Mailbox system's assigned reference number is not conveyed to the MES . The MES can
obtain reference numbers of the stored messages via the SummaryRequest PDU.

• The content identifier for a message submission can either be supplied by the MES, or a default
is generated by the MSAP Server. If required, the MSAP Server should generate the identifier
in the following format:

<IM><3 Digit LES id><UTC date time string><PDU Ref. number>11

• To-Mobile direction

• In the To-Mobile direction, the MES retrieves messages using the message store reference
numbers provided by the Mailbox system via the summary feature. The conveyance of the
messages after fetching from the mailbox are sent to the MES via the Inmarsat-C protocol
definition. In this direction no special consideration or attention is needed for the MES to
perform any correlations.

To explain the use of reference numbers, two examples are given - one for messages being sent in
the terrestrial direction. The other example describes the use of message references being sent in the
MES direction.

11The format of the UTC time shall be YYMMDDHHMM; eg. 9312311200 for noon on 31st December
1993.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 23
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Example 1: To-Mobile Direction

A terrestrial user foo sends a message from a terrestrial site to a mobile subscriber bar. This is sent to
the MSAP Server, which deposits the message in its local mailbox.

Later on, the mobile user bar request a list of the messages on his/her mailbox. The message request
is sent from the MES to the LES. This message is an Inmarsat-C message, containing one PDU, with
PDU sequence number X. The LES returns a clear packet when this message has been successfully
transferred over the satellite link. The clear packet contains a reference number, Y for example. This
reference number is used to correlate the Inmarsat-C confirmation packet, which is sent at a later
date to tell the MES subscriber if the LES has successfully forwarded this message to its destination
or not. The MES user then stores the combination of the request PDU sequence number and the
Inmarsat-C message reference to make a PDU reference number - XY.

Figure 9: Message Submission to Mailbox

TERRESTRIAL
NETWORKS
MSAP LES MES DCE

Message

Message
Store

If the message reaches the MSAP Server successfully, the request is processed. The results of this
process - a reference to the message deposited by user foo - are enclosed in another Inmarsat
message. The PDU reference number of this response is the same number as that stored by the MES
user - XY. This message is forwarded on to the LES, and finally to user bar.

The mobile user receives this response. The user knows that the response is in regard to his previous
summary request, because he/she can correlate the PDU reference number of this message with
those stored by the mobile user.

Example 2: From-Mobile Direction

If the mobile user bar wishes to send a message to terrestrial user foo, the message is sent via a
LES. The contents of the message submitted to the LES is a PDU(s) with sequence number P. If the
LES receives the full message, then the LES returns a clear packet with an Inmarsat-C message
reference number Q. The MES may then store a PDU reference number, which is the combination of
the PDU sequence number and the Inmarsat-C message reference number - i.e. PQ.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 24
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 10: Indirect Submission of Delivery Report

Message

TERRESTRIAL
NETWORKS
MSAP LES MES DCE

Delivery
Report

Message
Store

If the mobile user bar specifies in the message submission that he/she wishes a delivery report, then
this delivery report is not immediately sent to the MES user. Instead, the MSAP Server agent
indirectly delivers the report to the mailbox. The reference for this delivery report is a reference
containing this PDU reference number:

<IM><LES-id><UTC><PDU Ref.Number>

Later on the user may send a request to the mailbox to see if he/she has any stored messages in the
mailbox. This report will include the delivery report for the message submit operation, with the
reference entry mentioned previously. As the MES user has stored the original PDU reference
number, the user is able to correlate the delivery report (for cases where there is more than one
delivery report stored in the mailbox)

2.5.2 Message Status Enquiry


Message Status Inquiries on messages submitted to the X.400 network are not fully supported for two
reasons. First of all, the Inmarsat-C protocol for inquiries does not accommodate the PDU reference
number; the LES reference number cannot uniquely identify a PDU within a multiple PDU Inmarsat-C
message. Secondly the LES can only respond confidently if the message has not been submitted to
the Mailbox system for delivery to the X.400 network. Once the message has been transferred to the
Mailbox system, the LES will no longer have visibility on the message and will be forced to return the
UNK status code.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 25
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3 MTA Implementation

Figure 11: MTA Implementation

MESSAGES IN P1
PROTOCOL
COMPRESSED &
ENCAPSULATEDTO
USEINMARSAT-C
MESSAGING SERVICE

LES MES DCE

X.400 ENCAPSULATION
P1 ENCAPSULATION
GLOBAL MTA COMPRESSION
COMPRESSION P1
BACKBONE
(OPTIONAL)
IWU
MTA

STANDARDAP
PLICATIONS

The configuration using a full MTA at each end has the advantage of requiring the very minimum of
Inmarsat-specific software. PC-based MTAs are available from several manufacturers which can
simply deposit P1-encoded messages into a disc file and accept inbound messages from another file;
all that is needed in addition is a simple utility to collect these files and feed them to the DCE for
transmission.

Another point is that many third party applications (EDI systems, gateways to proprietary mail systems
etc.) use the same "P1 in file" interface to the MTA. Hence in the case where only one such
application is required, the need for an MTA at the mobile can be eliminated.

Some additional features are desirable in the IWU for improved efficiency:

• One important facility is to impose some constraints on the messages which can be delivered
to the mobile, in particular, a constraint on maximum size. The normal size limit on X.400
messages is 2Mbytes - a message of this size would take approximately a whole day to
transmit at the speed of an Inmarsat C channel, and in fact the protocols impose a limit of 32K
bytes on the size of a compressed message. Queuing algorithms require more careful attention
than in typical standard MTAs: it will be inefficient to send each X.400 message in a single
Inmarsat C message as soon as it arrives. Small messages can be held in the queue for a short
time so that if another message arrives the two (or more) can be combined into a single Inmarsat
C message for transmission, saving the call set up overhead.

• The X.400 message sent from a MES may not conform to the CCITT X.400 specification due to
the size saving feature mentioned in Section 1.4.1. The IWU must make the appropriate
adjustments when submitting the messages to the MTA. Conversely, the IWU should
repackage the X.400 messages to reduce the satellite transmission size.

• A MES can authorise the LES to generate a confirmation report on its behalf once a message
delivery has been acknowledged by the Inmarsat-C protocol. This service should be available
to both the registered and unregistered subscribers. An unregistered MES must instruct the LES
via the MTARegister PDU for the duration of its login period. With registered subscribers, the
IWU shall refer to the registered option unless changed, thereafter, by a MTARegister.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 26
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.1 Multiple-LES Operation


As mentioned in section 1, there are two mode of operation with the MTA service:

• Unregistered MTA service

• Registered MTA service

In all cases, the protocol used across the satellite is the same (although different to that used for the
Mailbox service); the distinction between the services is in the mode of connection to the terrestrial
X.400 backbone.

3.2 Unregistered MTA service


If an addressing scheme is chosen that allows any LES to identify the mobile corresponding to a
particular X.400 address, it is possible to treat X.400 interworking in a similar manner to other
telematic services, and to operate a service where no additional registration is needed for a
commissioned MES to start using X.400. In this case, any LES in the ocean region where the MES is
logged in may be used, providing a connection directly to the terrestrial X.400 networks at that LES.
This type of service is known as Unregistered MTA Service.

Figure 12: Out-of-Region Working - UnRegistered

AOR

MTA IWU

ACTIVE
SHIP
LIST

NCS IOR

MTA
IWU

For this service, the MES X.400 address definition as specified in Section 1.4.2 enables messages
that have been routed to the IWU to be delivered to the MES organisation. These messages may
include additional address attributes, such as personal name attributes, for distribution at the MES.
The destination MES can be determined directly from the address (using the organisation attribute),
without recourse to tables or registration information, by any IWU supporting the unregistered MTA
service.

In the From-Mobile direction, the MES selects a LES by referencing this service availability from the
LES Bulletin Board broadcast, and transmits an Inmarsat-C message containing one or more X.400
messages. The LES accepts the message with a clear packet in accordance to the normal Inmarsat-

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 27
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

C message transfer protocol. The LES forwards the Inmarsat-C message to the IWU who then
extracts and delivers the X.400 message(s) to the terrestrial X.400 network.

In the To-Mobile direction, messages will be routed by the terrestrial networks to a convenient IWU.
The IWU will determine the destination MES from the address, and consult the Active Ships List to
see whether the MES is active in the local ocean region. If the MES is logged in, the IWU shall
construct an Inmarsat-C message and transfer it to the LES for transmission to the mobile. If the MES
is active in another ocean region, the X.400 message can, optionally, be routed directly or indirectly to
a IWU serving that region; a IWU not providing this re-routing service will have to reject and return a
Non-Delivery report if one has been requested by the originator.

The behaviour in cases where a mobile logs out from an ocean region while there are messages in
transit is left as a matter of service operator policy. Where the mobile moves from one ocean region
to another, the message may either be re-routed to the appropriate IWU serving the new region or be
non-delivered. If a message arrives when the MES is not logged in, the message may be non-
delivered or held in storage for a short time awaiting a login from the mobile; subject to the expiry time
limitation of the message.

3.3 Registered MTA Service


If the mobile user is registered with a particular terrestrial service provider, additional services can be
provided, for example: filtering to eliminate unwanted messages; use of more natural X.400
addresses (which do not have an algorithmic mapping to MES IDs). To allow for these possibilities, a
second class of service is defined - Registered MTA Service.

Figure 13: Out-of-Region Working - Registered

AOR

Terrestrial IWU
X.400
networks IOR

In the Registered MTA service, all access to the terrestrial X.400 system is through a single point. The
user is registered with a particular Interworking Unit, which is able to perform any additional services
desired by the user. The X.400 addresses of mobile users are unconstrained; the sole requirement is
that messages must be routed to the IWU that has the translation of the X.400 addresses to the target
mobiles. This allows for addresses that explicitly identify the IWU, or other addresses for which
special routing arrangements are made (such as integration into a corporate PRMD).

In the From-Mobile direction, the MES logs onto to the LES which is known to offer a connection to
the IWU and transmits an Inmarsat-C message. The LES performs no X.400 processing on the
message, but instead transfers it unchanged to the IWU - the required IWU is indicated by an address

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 28
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

field in the Inmarsat-C message. The IWU decodes the Inmarsat-C message, performs any required
processing, and transfers the X.400 message to its MTA.

In the To-Mobile direction, an X.400 message arrives at the IWU. The IWU determines the intended
MES from the X.400 addressing, from the message’s origin, and from registration information held at
the IWU. If the user has not specified some alternative action (such as re-direction), the IWU consults
the Active Ships List and chooses a suitable LES for the ocean region where the MES is logged in.
The IWU then constructs an Inmarsat-C message containing the X.400 message, and transfers it to
the chosen LES for transmission. Behaviour in the case where the MES is not logged in may be
specified on a per-MES basis; this allows possibilities such as redirection to a terrestrial address.

There is no constraint on the physical location of an IWUs; typically, these will be provided by LES
operators, but may be located anywhere convenient (e.g. as part of an ADMD operation). The
method used to connect an IWU to the LESs which it uses is not constrained. It is desirable for each
IWU to connect to as many LESs as possible, to provide a more openly accessible service and
provide resilience against LES failure. To provide global coverage, each IWU will need to connect to
at least one LES in each ocean region.

3.4 X.400 Delivery Reports


Delivery reports required by the MES must be indicated in the originating X.400 messages. For the
registered MTA service the default indication can be a registration option. When a MES requests for a
confirmation, this indication is conveyed within the X.400 message during message generation. For
an IWU to request a confirmation, the indication shall be treated as a request from an MTA and be
indicated appropriately in the 'MessageTransferEnvelope'12.

In practice a delivery report is usually transferred via the originating IWU to the originating MES. This
can be achieved by the appropriate specification of the originator address as follows:

• The originator address is omitted by the MES and inserted by the IWU.

• The major X.400 attributes such as Country, Administration Domain, and Private Domain are
omitted by the MES and are inserted by the IWU.

However, if a LES cannot transfer the delivery report to the MES (e.g. MES equipment switched off or
not logged in) and the IWU cannot forward the delivery report to another IWU or LES that can perform
the transfer then the disposal of the delivery report is a local IWU implementation.

Note that if an X.400 message is rejected or failed to be transferred to the IWU's MTA, then the IWU
is responsible for returning an X.400 delivery report (if confirmation has been requested) whose
content is the Result information of the CCITT X.411 MTABind abstract service.

3.5 Message Identification


In the course of traversing between the MES and the X.400 network, a message can be tagged with
one or more message reference numbers and identities. This section provides a recommendation for
the generation of message references in the path between the MES and the LES or IWU.

In the From-Mobile direction, message references are created at the following areas:

• Each PDU within an Inmarsat-C message that is created at the MES is tagged with an implicit
sequence number.

• By the Inmarsat-C protocol definition, an Inmarsat-C message is tagged with a message


reference number when the LES accepts the message.

12 If this confirmation request is treated as an MTA request, the request will be seen as being initiated
by the MES - resulting in the MES being charged.
Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 29
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

• By the X.400 protocol definition, upon submission to the MTA the message is tagged with a set
containing a message submission identifier, message submission time, and optionally a content
identifier. However this identifier is or can be supplied by the MES itself.

Unlike the case of the Mailbox service, a coherent relationship between the various references and
identities is not essential because the MES has visibility on the X.400 message identifier which the
MES can construct. If the MES omits specifying the X.400 message identifier, the format of the
identifier generated by the IWU should be adequate for the MES to correlate the submitted messages
and their delivery reports.

To provide a uniform approach to X.400 message identifiers associated with Inmarsat-C, this section
recommends the following approach:

• Each PDU is implicitly assigned a sequence number within a byte range; i.e. 1 to 255. This
limits the number of X.400 messages within a single Inmarsat-C message to 255. Sequence number
zero is reserved.

• The PDU reference number shall be a combination of the message reference number supplied
by the LES in the clear packet and the PDU sequence number. The LES reference number
being the most significant digits and the PDU sequence number being the least three significant
digits.

• The X.400 message identifier shall be the same format as the content identifier mentioned in
Section 2.5.1.

In the To-Mobile direction, the conveyance of the X.400 messages are transferred within Inmarsat-C
messages. In this direction no special consideration or attention is needed for the MES to perform any
correlations.

3.6 MTA Service Operation


MTA service operations are carried out via the Protocol Data Units (PDU) described in Section 4. In
general, the basic IWU operations are:

• X.400 message transfer

• Registration

The X.400 message transfer operation is the main operation of the MTA service and is associated
with the transfer of messages, delivery reports, and probes between the MES and the LES/IWU. The
messages, delivery reports, and probes are encoded as PDUs and more than one PDU can be
contained within one Inmarsat-C message. The restriction is that no single PDU can span across
multiple Inmarsat-C messages.

Both a registered and an unregistered MES can perform registration operations. For an unregistered
MES, the registration operation has a limited choice of services. This choice includes:

• Authorizing the IWU to generate X.400 delivery reports for all messages delivered and
acknowledged by the MES

• To inform the IWU that the MES is available for X.400 transfers

• To inform the IWU that the MES is suspending X.400 transfers

The last two options apply only for the duration that the MES is logged in at the LES or between
registration operations. For a registered MES, the registration operation extends the unregistered
MES choice to include the amendment of registration informations held at the IWU.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 30
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.6.1 MES-to-IWU X. 400 Message Transfers


The Inmarsat-C "From-Mobile Message Transfer" protocol is used to initiate the X.400 message
transfer operation. All the mentioned PDUs are contained in the Data portion of the message packet
and the Presentation and the Additional Information fields of the Message Header are set to 82H and
X400 destination respectively. The sequence of events in a message transfer operation is as follows:

• MES transmits a Message, Report, and Probe PDU within an Inmarsat-C message; please
refer to Section 1.4.1 for encoding recommendations.

• If a confirmation is required, the MES should indicate this requirement within the X.400
structure. Returning X.400 delivery reports will be forwarded to the MES.

• The LES shall accept the Inmarsat-C message by transmitting a clear response. The clear
packet shall contain the LES allocated reference number for this PDU. Acceptance at this stage
is an indication that the message is en route to its X.400 destination(s).

• The presentation code shall enable the LES to route the Inmarsat-C message to the IWU
where this PDU will then be extracted.

• The IWU shall transform the PDU into an X.400 message taking into such considerations as:

• Inserting essential X.400 attributes that have been omitted,

• Transferring the recipient addresses from the content portion to the envelope portion if
these have been omitted from the envelope.

• Copying the recipient address from the envelope portion to the content portion if these
have been omitted from the content.

• If the message cannot be submitted to the IWU's MTA, the IWU shall generate an X.400
delivery report on the result as defined in the CCITT X.411 MTABind Result abstract service.

Where the originating message has requested for reports, the following sequence of events applies
when its X.400 delivery reports are returned:

• Optionally, a IWU may choose to defer actioning each X.400 delivery report for a period of time
subject to the CCITT Quality of Service for Delivery Reports. At the end of the period the IWU
then combines all the delivery reports with the same Message Submission Identifier into one
delivery report. In case where the number of recipients are known by the IWU, then the
combination process can be initiated when the complete delivery result is known.

• For each delivery report, the IWU generates a Report PDU and inserts the PDU into an
Inmarsat-C message; please refer to Section 1.4.1 for encoding recommendations.

• The IWU passes the Inmarsat-C message containing the delivery report to the LES for delivery
to the MES.

• The MES is responsible for the decoding of the Report PDU and the presentation of the
delivery report to the MES user.

• If the transfer fails, e.g. MES has logged out, the disposal of the Report PDU is a local
LES/IWU implementation.

3.6.2 IWU-to-MES X.400 Message Transfers


The Inmarsat-C "Mobile-Message Transfer" protocol is used to initiate the X.400 message transfer
operation. All the mentioned PDUs are contained in the Data portion of the message packet and the

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 31
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Presentation and the Additional Information fields of the Message Header are set to 82H and X.400
destination, respectively. The sequence of events in a message transfer operation is as follows:

• IWU generates the corresponding Message, Report, and Probe PDU from the appropriate
X.400 message type; please refer to Section 1.4.1 for encoding recommendations.

• To reduce satellite transmission, it would be preferable for the IWU to combine multiple PDUs,
to the same MES, together as one Inmarsat-C message. This operation will need an imposition
of a short period of time subject to the CCITT F.410 definition of quality of service for message
delivery.

• The IWU passes the Inmarsat-C message to the LES for transmission to the MES.

• The LES reports the success or failure of the transmission to the IWU. In the case of a failure,
the IWU has a choice of re-routing the message (e.g. in the case where the MES has logged
into another LES) or to return an X.400 delivery report to the originator of the message. In the
case of a success and if authorized by the MES, the IWU shall return an X.400 delivery report
to the originator of the message.

In the case where the MES has elected to generate and return an X.400 delivery report, the following
sequence of events applies:

• The MES is expected to return only one X.400 delivery report for the list of recipients for which
it is responsible; see Section 1.4.1 for encoding recommendation. This delivery report is encoded
in a Report PDU and is inserted into an Inmarsat-C message on its own or among other PDUs.

• The MES transmits the Inmarsat-C containing the Report PDU to the LES. Responsibility of the
MES ends when the LES acknowledges the transfer with the clear packet.

• The LES passes the Inmarsat-C message to the IWU.

• The IWU parses the Inmarsat-C message and extracts the Report PDU. This Report PDU is
then transformed to an X.400 delivery report; see Section 1.4.1 for encoding recommendation.
The IWU transfers the X.400 delivery report to its MTA for delivery into the X.400 network.

• If the Report PDU is rejected by the IWU's MTA, the disposal of the delivery report is a local
IWU implementation and the MES will not be informed.

3.6.3 Registration
The Inmarsat-C "From Mobile Message Transfer" protocol is used to initiate the registration operation.
All the mentioned PDUs are contained in the Data portion of the message packet and the
Presentation and the Additional Information fields of the Message Header are set to 82H and X.400
destination, respectively.

The sequence of events in a summary operation is as follows:

• MES transmits a MTARegister PDU (within an Inmarsat-C message) to the LES. This operation
can be omitted for registered MES users who have the details at the IWU.

• The setting of the Confirmation Request bit in the Message Header is ignored since the
MTARegisterResponse PDU is returned.

• The LES shall accept this PDU like a normal message by transmitting a clear response if the
PDU is recognisable. The clear packet shall contain the LES allocated reference number for
this PDU. Acceptance at this stage is not an indication that the registration details have been
accepted.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 32
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

• The LES shall pass the PDU to the IWU for processing. Depending on the implementation of
the IWU, a quick response may not be readily available.

• The IWU shall return a MTARegisterResponse PDU indicating the success or failure of the
registration PDU for the LES to send to the MES. The MTARegisterResponse PDU shall
contain
the Inmarsat-C reference number of the associated MTARegister PDU; this information is
useful when a MES had sent more than one such PDU in sequence.

Unlike the MESRegister PDU used in the Mailbox service, the MTARegister PDU can be embedded
among other PDUs within an Inmarsat-C message. However there is no guarantee that this
registration PDU shall be processed before other PDUs. Where private registration details require the
MTARegister PDU to be contained within a single Inmarsat-C message, this arrangement is a
bilateral agreement between the IWU operators and the registered MES users.

An IWU implementation should provide for the facility to store the set of registration details for each of
its registered MES subscribers.

4 Protocol Data Units


The description of the MTA service and the Mailbox service are in terms of Protocol Data Units
(PDUs) which are exchanged between LES and MES, and the procedures for processing them. This
allows for the system to have several features in common, but allow either service to be implemented
independently.

PDUs are assembled into Inmarsat-C store-and-forward messages. Where there are multiple PDUs
waiting to be sent, they may be combined into a single Inmarsat-C message, subject to the length
constraints imposed by the Inmarsat-C system.

The encoding of PDUs for transmission, and their mapping onto Inmarsat-C channels and signals is
described in Section 7 of this specification. All PDUs are carried within the data portion of Inmarsat-C
messages, with the exception that under some circumstances the Forced Clear or Confirmation
signals may be used in place of the DecodeProblem or DecodeConfirmation PDUs.

4.1 MTA Service PDUs - MES to IWU


Five PDU types are available in this direction:

MTAmEStoLES ::= CHOICE {


[0] Message,
[1] Report,
[2] Probe,
[3] MTARegister
[4] MTAProblemReport
-- Implementations should expect additional PDU types to be defined in future protocol
versions
}

Future extensions to the protocol may result in the introduction of additional PDU types. If a PDU is
received which is not valid within the version of the protocol that has been implemented, an
appropriate MTAProblemReport PDU shall be generated.

4.1.1 Message, Report, and Probe PDUs


These PDUs are imported from X.411, where they form the arguments of the MessageTransfer,
ReportTransfer and ProbeTransfer abstract operations of the MTA Abstract Service. They serve
exactly the same purpose in the Inmarsat-C MTA service.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 33
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.1.2 MTARegister PDU


This PDU is used by the MES to register (or amend registration details) at a IWU. An unregistered
MES may use this PDU to register as 'temporary guest' of the IWU; subject to the IWU providing this
feature.

This PDU must be specified solely within an Inmarsat-C message; i.e. no other PDUs are expected.

MTARegister ::= SEQUENCE {


reports-at-LES [0] BOOLEAN DEFAULT FALSE,
mES-inactive [1] NULL OPTIONAL,
private-information [2] SET OF PrivateRegistration OPTIONAL
mES-protocol-version [3] INTEGER OPTIONAL,
}

PrivateRegistration ::= SEQUENCE {


type [0] INTEGER,
value [1] OCTET STRING (SIZE (1....1024)) OPTIONAL
}

mES-protocol-version indicates the protocol version that has been implemented at the MES; the
IWU may use this information to avoid transmitting protocol enhancements which will not be
understood by the MES. No special provision needs to be catered for if this element is omitted.

reports-at-LES is True then the IWU shall generate an X.400 delivery report when the message has
been transmitted successfully to the MES. If reports-at-LES is False (the default value), the MES
implementation is a standard MTA and will take responsibility for generating the reports. For
registered MES subscribers, this amendment is a permanent amendment and will remain in force
across subsequent login sessions until the next amendment is issued; misalignment of this element
can result in the X.400 delivery reports generated from both IWU and MES or none at all.

mES-inactive indicates that the MES is ceasing to operate within the MTA service, and the LES
should no longer attempt to deliver X.400 messages to it. In the absence of this protocol element, an
MTARegister PDU implicitly indicates that the MES wishes to become active in the MTA service. For
registered MES subscribers, this amendment is a permanent amendment and will remain in force
across subsequent login sessions until the next amendment is issued; misalignment of this element
may result in the MES being prohibited from the MTA service.

private-information may be used to register any additional parameters required for additional
proprietary services offered by the LES operator. Within each PrivateRegistration, the type is an
integer value which identifies the type of information being registered, and the value contains that
information, the interpretation of which is determined by the type. When a new type of private
registration is defined by a LES operator or equipment manufacturer, application should be made to
Inmarsat for the assignment of a type value.

4.1.3 MTAProblemReport PDU


This PDU is used by the MES (or the IWU) to indicate that it is unable to process an Inmarsat-C
message or one or more PDU within the message.

MTAProblemReport ::= SEQUENCE {


message-reference [0] INTEGER,
PDU-sequence-number [1] INTEGER OPTIONAL,
problem [2] ENUMERATED {
bad-message (0)
unrecognised-PDU-type (1),
unsupported-protocol-version (2)

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 34
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

},
protocol-version [3] INTEGER OPTIONAL
supplementary-information [4] PRINTABLESTRING (size 1...132) OPTIONAL
}

message-reference identifies the Inmarsat-C message reference of the message that contained the
problem PDU.

PDU-sequence-number is the implicit sequence number of the PDU within the Inmarsat-C message.
If this is present, then the problem is associated with the particular PDU and not the Inmarsat-C
message as a whole.

problem indicates the problem issue. The issues at present are:

bad-message indicates that the Inmarsat-C message has been rejected; e.g. the Inmarsat-C
message contained a MTARegister (or a MTARegisterResponse) PDU together with other
PDUs. A precise reason can be included using the supplementary-information element.

unrecognised-PDU-type indicates the PDU is not supported or not known. The unrecognition
of one PDU will invalidate subsequent PDUs that follow within the Inmarsat-C message. For
some implementations, to invalidate the whole Inmarsat-C message may not be possible as the
preceding PDUs may have been processed and cannot be recalled. Therefore implementations
must handle this situation for the remaining PDUs that follow this problem PDU to be re-
submitted. For those IWU implementations that wish to reject the whole message, this can
easily be achieved by not specifying the PDU-sequence-number which instead can be
inserted as supplementary-information.

unsupported-protocol-version may be used by the other station to determine an alternative


encoding which will allow the original message to be re-transmitted successfully.

protocol-version may be used to indicate the version of the protocol that has been implemented at
the station.

supplementary-information is additional information that could be helpful in the diagnosis of the


problem.

4.2 MTA Service PDUs - IWU to MES


Five PDU types are provided in this direction:

MTAlEStoMES ::= CHOICE {


[0] Message,
[1] Report,
[2] Probe,
[3] MTARegisterResponse
[4] MTAProblemReport
-- Implementations should expect additional PDU types to be defined in future protocol
versions
}

Future extensions to the protocol may result in the introduction of additional PDU types. If a PDU is
received which is not valid within the version of the protocol that has been implemented, an
appropriate MTAProblemReport PDU shall be generated.

4.2.1 Message, Report, Probe, and MTAProblemReport PDUs


The Message, Report, Probe and MTAProblemReport PDUs are identical to those used in the
opposite direction, as the protocol is broadly symmetrical; see Section 4.1.1.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 35
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.2.2 MTARegister Response PDU


A MTARegisterResponse PDU is issued by the LES in response to each MTARegister PDU that is
received.

RegisterResponse ::= SET {


message-reference [0] INTEGER,
PDU-sequence-number [1] INTEGER,
status [2] INTEGER {
registration-accepted (0),
requested-facility-not-supported (1),
registration-not-permitted (2),
invalid argument (3)
},
lES-protocol-version [3] INTEGER OPTIONAL
supplementary-information [4] IA5String (SIZE (1....128)) OPTIONAL,
}

message-reference identifies the Inmarsat-C message reference of the message that contained the
associated MTARegister PDU.

PDU-sequence-number is the implicit sequence number of the MTARegister PDU within the
Inmarsat-C message.

status indicates the success or otherwise of the registration operation. supplementary-information


may be used to carry additional information relating to a failure, or in the case where the registration
has been accepted, it may convey other service information. The status information at present is one
of the following:

registration-accepted indicates the registration or amendment details have been accepted


and are effective henceforth.

requested-facility-not-supported indicates either certain or all registration details have not


been accepted. The cause or reason is expected to be specified in the supplementary-
information.

registration-not-permitted indicates the registration has been rejected. This applies to the case
when the IWU does not support 'temporary guest' registration for unregistered MES.

invalid argument indicates that one or more elements of the registration details is invalid.

lES-protocol-version indicates the protocol version that has been implemented at the LES; the MES
may use this information to avoid transmitting protocol enhancements which will not be understood by
the LES.

supplementary-information is additional information that could be helpful in the diagnosis of the


problem.

4.3 Mailbox Service PDUs - MES to MSAP Server


Seven PDUs are provided in this direction:

MailboxMEStoLES ::= CHOICE {


[0] DeletionRequest
[1] MESRegister,
[2] MessageSubmission,
[3] ProbeSubmission,

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 36
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

[4] RetrievalRequest,
[5] SummaryRequest,
[6] MbxProblemReport
-- Implementations should expect additional PDU types to be defined in future protocol
versions
}

Future extensions to the protocol may result in the introduction of additional PDU types. If a PDU is
received which is not valid within the version of the protocol that has been implemented, an
appropriate MbxProblemReport PDU shall be generated.

4.3.1 DeletionRequest PDU


This PDU specifies a list of messages to be deleted from the mailbox. The messages are identified
by the message store reference numbers (small integers) from a previous summary.

DeletionRequest ::= SEQUENCE OF INTEGER

4.3.2 MESRegister PDU


This PDU allows the user to change the values of the registration parameters maintained by the IWU.

MESRegister ::= SEQUENCE {


[0] SET OF RegisterRequest
mES-protocol-version [1] INTEGER OPTIONAL,
}

RegisterRequest ::= CHOICE {


[0] MailboxAccessInfo,
inclusion-criteria [1] Filter,
no-summary-criteria [2] Filter,
expedited-tx-criteria [3] Filter,
[4] SummaryControls,
default-forward-destination [5] ORName,
default-retrieval-type [6] RetrievalType,
auto-ipm-notifications [7] BOOLEAN,
private-info [7] PrivateRegistration,
terminate-service [8] NULL
}

MailboxAccessInfo ::= SEQUENCE {


[0] MSBindArgument OPTIONAL, -- If either is absent, LES defaults for
[1] PresentationAddress OPTIONAL, -- this MES are used
x121-address [2] NumericString (SIZE (1..16)) OPTIONAL,
[3] NetworkType OPTIONAL
}

NetworkType ::= INTEGER {


x25 (0),
ISDN (1),
dial-up-APS (2)
-- Other standard values for further study
-- Values 100..199 are reserved for private use by LES operators
}

SummaryControls ::= SEQUENCE {


summary-on-login [0] BOOLEAN DEFAULT FALSE,

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 37
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

auto-summary-interval [1] INTEGER -- In hours


}

PrivateRegistration ::= SEQUENCE {


type [0] INTEGER,
value [1] OCTET STRING (SIZE (1..1024)) OPTIONAL
}

MailboxAccessInfo is the set of information required to access a target mailbox system using the
elements of the MSBindArgument. The location of the mailbox system can be indicated by specifying
the PresentationAddress, x121-address, and/or the NetworkType element.

x121-address may be supplied in addition to PresentationAddress for use in networks which do not
employ NSAP addressing (e.g. using CCITT X.25(1980) ).

NetworkType may be used to specify the type of network connection to be used if this cannot be
determined from the presentation address.

inclusion-criteria specifies those messages which should be included in summaries sent to the
MES. It allows unwanted types of message to be excluded - this is of particular relevance when the
mailbox is also being monitored by a terrestrial user who can deal with unimportant or over-size
messages. The parameter syntax is a FILTER (see CCITT X.413). The default value is null - all
messages are included.

no-summary-criteria specifies those messages which should be transmitted to the MES directly,
rather than transmitting a summary. The parameter syntax is a FILTER. The default value is content-
length LESS THAN 500.

expedited-tx-criteria specifies those messages which should cause immediate transmission of a


summary to the MES, rather than waiting for a summary report to be issued. The parameter syntax is
a FILTER. The default value is importance EQUALS high.

SummaryControls specifies circumstances under which a summary will automatically be transmitted


by the MSAP Server, without the need for the MES to request it. A summary may be implicitly
requested when the MES logs into an ocean region, or at regular time intervals. Such automatically-
generated summaries only contain messages which have not previously been summarised; if there
are no such messages, a summary is not transmitted. The parameter syntax is a Boolean to specify
summary on login (summary-on-login), plus an integer specifying the period (auto-summary-
interval) between regular summaries (in hours). The default values are determined by service
operator policy.

default-forward-destination provides a default destination for use in the Forwarding Request PDU.
The parameter syntax is an ORName. There is no default value.

default-retrieval-type specifies whether the envelope, content or both should be supplied in


Retrieved Message PDUs resulting from automatic transmissions due to no-summary criteria, or
where the retrieval type is not specified in a RetrievalRequest PDU. The default value is that only the
content is transmitted.

auto-ipm-notifications This parameter controls whether the LES generates a Receipt notification (for
messages which request one) when the message has been retrieved by the user.

NOTE: The generation of receipt notifications by the MS is currently under study by CCITT.
Currently, X.420 specifies that the MS should generate non-receipt notifications, but that the
User Agent should generate receipt notifications. Future versions of X.420 may provide for the
generation of receipt notifications by the MS also. This registration parameter should be used
to control the operation, whether implemented in the MS or explicitly by the LES.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 38
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

private-information may be used to register any additional parameters required for additional
proprietary services offered by the LES operator. Within each PrivateRegistration, the type is an
integer value which identifies the type of information being registered, and the value contains that
information, the interpretation of which is determined by the type. When a new type of private
registration is defined by a LES operator or equipment manufacturer, application should be made to
Inmarsat for the assignment of a type value.

terminate-service indicates that the MES is ceasing use of the Mailbox service, and the LES should
no longer attempt to transmit summaries to it. In the absence of this protocol element, an
MESRegister PDU implicitly indicates that the MES wishes to become active in the Mailbox service.
Beware that this amendment is a permanent amendment and will remain in force across subsequent
login sessions until the next amendment is issued; misalignment of this element may result in the
MES being prohibited from the Mailbox service.

NOTE: It is a matter of service operator policy which additional actions are taken in response to
a terminate-service registration; such actions may include deletion of messages in the mailbox
and the prevention of further deliveries.

mES-protocol-version indicates the protocol version that has been implemented at the MES; the
LES may use this information to avoid transmitting protocol enhancements which will not be
understood by the MES.

4.3.3 MessageSubmission PDU


This PDU contains a complete message for an indirect submission; the syntax is that of parameters to
the P3 MessageSubmission operations.

MessageSubmission ::= SEQUENCE {


result-required [0] NULL OPTIONAL,
SEQUENCE {
MessageSubmissionEnvelope,
Content
}
}

result-required specifies that the SubmitResult PDU must be returned to indicate the success or
failure of the submission. If this element is omitted, a SubmitResult PDU is returned only if the
message submission operation has failed

MessageSubmissionEnvelope corresponds to the MessageSubmissionEnvelope abstract syntax


definition of the MTS Submission Port abstract service defined in CCITT X.411.

Content corresponds to the Content abstract syntax definition of the MTS abstract service defined in
CCITT X.411.

4.3.4 ProbeSubmission PDU


This PDU contains a complete message for an indirect submission; the syntax is that of parameters to
the P3 MessageSubmission operations.

ProbeSubmission ::= SEQUENCE {


result-required [0] NULL OPTIONAL,
SEQUENCE {
ProbeSubmissionEnvelope,
}
}

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 39
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

result-required specifies that the SubmitResult PDU must be returned to indicate the success or
failure of the submission. If this element is omitted, a SubmitResult PDU is returned only if the
message submission operation has failed

ProbeSubmissionEnvelope corresponds to the ProbeSubmissionEnvelope abstract syntax


definition of the MTS Submission Port abstract service defined in CCITT X.411.

4.3.5 RetrievalRequest PDU


This PDU specifies a list of messages to be retrieved from the mailbox. The messages are identified
by the reference numbers (small integers) from a previous summary. Provision is also made to
override the registered default for the retrieval type.

RetrievalRequest ::= SEQUENCE {


[0] RetrievalType OPTIONAL, -- If absent, registered default is used
ms-reference-numbers [1] SEQUENCE OF INTEGER
}

RetrievalType ::= ENUMERATED {


envelope-and-content (0),
envelope-only (1),
content-only (2)
}

RetrievalType indicates the information to be extracted from the message store. The choices include
fetching the complete message (envelope-and-content), only the envelope portion (envelope-only)
of the message, and only the content portion (content-only) of the message. The choice applies to all
the given reference numbers. This element applies only to Messages and not delivery reports.

ms-reference-numbers is the list the message store reference numbers for the MSAP Server to
retrieve from the message store.

4.3.6 SummaryRequest
This PDU requests that the LES transmit a summary. The summary will always be constrained by the
registered exclusion criteria; in addition, the summary can be further constrained to exclude
messages that have already been summarised, and to summarise only new, or new and listed
messages.

SummaryRequest ::= SEQUENCE {


message-states ENUMERATED {
all-messages (0),
new-only (1),
new-and-listed (2)
retrieved-only (3) } DEFAULT all-messages
}

message-states indicates the summary operation should consider one of the following condition:

all-messages regardless of whether they have been retrieved or reported,

retrieved-only refers only to messages that have been retrieved at least once,

new-only refers to newly arrived messages that have not been retrieved or reported in
previous summary operations,

new-and-listed refers to newly arrived messages that have not be retrieved.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 40
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The message-state should be used in conjunction with the Message Inclusion Criteria (which is a
registration attribute) when selecting messages for the generation of the summary report.

Implementors Note: Depending on the facilities at the message store, the implementation of this
PDU will require the MSAP Server to monitor each message in the message store for each
MES. The monitored information will need to be updated at the end of each summary operation
and parts of the information have to be removed when messages are deleted from the
message store.

4.3.7 MbxProblemReport
This PDU is used by the MES (or the MSAP Server) to indicate that it is unable to process an
Inmarsat-C message or one or more PDU within the message.

MbxProblemReport ::= SEQUENCE {


message-reference [0] INTEGER,
PDU-sequence-number [1] INTEGER OPTIONAL,
problem [3] ENUMERATED {
bad-message (0)
unrecognised-PDU-type (1),
unsupported-protocol-version (2)
},
protocol-version [2] INTEGER OPTIONAL
supplementary-information [3] PRINTABLESTRING (size 1..132) OPTIONAL
}

message-reference identifies the Inmarsat-C message reference of the message that contained the
problem PDU.

PDU-sequence-number is the implicit sequence number of the PDU within the Inmarsat-C message.
If this is present, then the problem is associated with the particular PDU and not the Inmarsat-C
message as a whole.

problem indicates the problem issue. The issues at present are:

bad-message indicates that the Inmarsat-C message has been rejected; e.g. the Inmarsat-C
message contained a MESRegister (or a MESRegisterResponse) PDU together with other
PDUs. A precise reason can be included using the supplementary-information element.

unrecognised-PDU-type indicates the PDU is not supported or not known. The unrecognition
of one PDU will invalidate subsequent PDUs that follow within the Inmarsat-C message. For
some implementations, to invalidate the whole Inmarsat-C message may not be possible as the
preceding PDUs may have been processed and cannot be recalled. Therefore implementations
must handle this situation for the remaining PDUs that follow this problem PDU to be
resubmitted. For those IWU implementations that wish to reject the whole message, this can
easily be achieved by not specifying the PDU-sequence-number which instead can be
inserted as supplementary-information.

unsupported-protocol-version it may be used by the other station to determine an alternative


encoding which will allow the original message to be re-transmitted successfully.

protocol-version may be used to indicate the version of the protocol that has been implemented at
the station.

supplementary-information is additional information that could be helpful in the diagnosis of the


problem.

4.4 Mailbox Service PDUs - MSAP Server to MES

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 41
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Six PDUs are provided in this direction:

MailboxLEStoMES ::= CHOICE {


[0] DeletionResult,
[1] MesRegisterResponse
[2] RetrievedMessage
[3] SummaryReport,
[4] SubmitResult,
[5] MbxProblemReport
Implementations should expect additional PDU types to be defined in future protocol versions
}

Future extensions to the protocol may result in the introduction of additional PDU types. If a PDU is
received which is not valid within the version of the protocol that has been implemented, an
appropriate MbxProblemReport PDU shall be generated.

4.4.1 DeletionResult PDU


DeletionResult ::= SET {
message-reference [0] INTEGER,
PDU-sequence-number [1] INTEGER OPTIONAL,
result-set [2] SEQUENCE OF SET {
ms-reference-number [0] INTEGER
result-code [1] INTEGER {
deleted (0)
not-deleted (1)
}
}
}

message-reference identifies the Inmarsat-C message reference of the message that contained the
DeletionRequest PDU.

PDU-sequence-number is the implicit sequence number of the DeletionRequest PDU within the
Inmarsat-C message.

result-set is the set of results corresponding to the list of message store reference numbers specified
in the DeletionRequest PDU, Each result contains an ms-reference-number and a result-code that
indicates the message store entry has been deleted or not.

ms-reference-number is one of the message store reference numbers specified in the


DeletionRequest PDU

result-code is an indication whether the specified message store entry specified by ms-reference-
number has or has not been deleted.

deleted indicates the message store entry has been deleted.

not-deleted indicates the message store entry was not deleted.

4.4.2 MesRegisterResponse PDU


This PDU indicates whether the registration details, of the associated MesRegister PDU, have been
accepted or rejected.

MesRegisterResponse ::= SET {


message-reference [0] INTEGER,

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 42
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

registration-result [1] SEQUENCE OF SEQUENCE {


problem [0] RegisterRequest OPTIONAL
result-code [1] INTEGER {
success (0)
unspecified-error (1),
invalid-syntax (2),
prohibited-by-LES-policy (3),
not-supported-by-MS (4),
service-not-subscribed (5),
unable-to-bind-to-MS (6),
change-by-LES-operator-only (7) }
supplementary-info [2] PRINTABLESTRING OPTIONAL }
}

message-reference identifies the Inmarsat-C message reference of the message that contained the
associated MESRegister PDU.

registration-result reports on the success or failure of the registration process. In the case of
individual registration element failure, the unacceptable individual element is copied from the
corresponding RegisterRequest element of the MESRegister PDU. A result-code is then included to
identify the cause of failure. If no RegisterRequest is given, then the result-code applies to the
whole registration details in general.

success indicates that the registration details have all been accepted. This code should not be used
to indicate the successful validation for each of the elements in RegisterRequest.

4.4.3 RetrievedMessage PDU


This PDU contains either an X.400 message or an X.400 Delivery Report. In the case of a message,
the Message Delivery Envelope and/or Content are returned according to the RetrievalType specified
in the RetrievalRequest PDU. In the case of Delivery Reports, the Report Delivery Envelope is
always returned. The Returned Content service is not supported.

If the user requests a message which is not available (e.g. because it has been auto-deleted, or
deleted by a terrestrial user), the no-longer-available element is present in place of the envelope and
content.

RetrievedMessage ::= SEQUENCE {


message-reference [0] INTEGER,
PDU-sequence-number [1] INTEGER,
ms-reference-number [2] INTEGER,
[1] MessageDeliveryEnvelope, OPTIONAL
[2] Content, OPTIONAL
[3] ReportDeliveryEnvelope OPTIONAL,
no-longer-available [4] NULL OPTIONAL
}

message-reference identifies the Inmarsat-C message reference of the message that contained the
RetrievalRequest PDU.

PDU-sequence-number is the implicit sequence number of the RetrievalRequest PDU within the
Inmarsat-C message.

ms-reference-number is the message store reference number associated with this message.

MessageDeliveryEnvelope corresponds to the MessageDeliveryEnvelope abstract syntax


definition of the MTS Delivery Port abstract service defined in CCITT X.411. This element is omitted if

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 43
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

it is prohibited by the RetrievalType element of the RetrievalRequest PDU or prohibited by the


registration details when RetrievalType was not specified in the RetrievalRequest PDU.

Content corresponds to the Content abstract syntax definition of the MTS Delivery Port abstract
service defined in CCITT X.411. This element is omitted if it is prohibited by the RetrievalType
element of the RetrievalRequest PDU or prohibited by the registration details when RetrievalType
was not specified in the RetrievalRequest PDU.

ReportDeliveryEnvelope corresponds to the ReportDeliveryEnvelope abstract syntax definition of


the MTS Delivery Port abstract service defined in CCITT X.411.

4.4.4 SummaryReport
The SummaryReport PDU contains a sequence of message or report summaries. Each message
summary contains: reference number, Originator, arrival time, Content type, Content length, Subject
(limited to 20 characters), Importance, Sensitivity. In the case of content types other than P2 (IPMS),
the Importance/Sensitivity fields are not used, and the Subject field can be used to give a human-
readable indication of the content type. A report summary contains reference number, Content
identifier, number of positive deliveries, number of delivery failures (note that reports will often be
sufficiently small that the whole report is transmitted, rather than the summary). too-large-to-retrieve
is used to indicate messages which have been delivered to the MS but are too large to be transmitted
across the Inmarsat-C system; the user may only forward or delete such messages (or, if terrestrial
access is also provided to the MS, the user may arrange for retrieval via the terrestrial networks).

If the summary is generated as a result of an explicit request (in response to a SummaryRequest),


there may not be any messages meeting the criteria to appear in the summary; in this case, the
Summaries PDU comprises an empty SET. Summaries resulting from automatic action (e.g. in
response to a login) are suppressed if they contain no messages.

SummaryReport ::= SEQUENCE {


message-reference [0] INTEGER OPTIONAL,
PDU-sequence-number [1] INTEGER OPTIONAL,
summaries [2] SEQUENCE OF SEQUENCE {
ms-reference-number [0] INTEGER,
arrival-time [1] UTCTime,
too-large-to-retrieve [2] NULL, -- If present, the message is too large to
retrieve
CHOICE {
[3] MessageSummary,
[4] ReportSummary
}
}
}

MessageSummary ::= SEQUENCE {


originator [0] ORName,
[1] ContentType DEFAULT built-in {2},
content-length [2] INTEGER,
subject [3] TeletexString (SIZE (1..20)) OPTIONAL,
importance [4] ImportanceField OPTIONAL,
sensitivity [5] SensitivityField OPTIONAL
message-text [6] PRINTABLESTRING (SIZE (1..132)) OPTIONAL
}

ReportSummary ::= SEQUENCE{


[0] MesssageSubmissionIdentifier OPTIONAL,
[1] ContentIdentifier OPTIONAL,
successful-deliveries [2] INTEGER DEFAULT 1,

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 44
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

failures [3] INTEGER DEFAULT 0


}

message-reference identifies the Inmarsat-C message reference of the message that contained the
SummaryRequest PDU to which this PDU is associated with. This element is omitted if this summary
is not as a result of an explicit request.

PDU-sequence-number is the implicit sequence number of the SummaryRequest PDU within the
Inmarsat-C message. This element is omitted if this summary is not as a result of an explicit request.

ms-reference-number is the message store reference number associated with this message.

arrival-time is the time the message store entry was created for this message.

MessageSummary is used for reporting on a message. The report details include the originator,
ContentType, Content-Length, Subject (which is truncated if the description is large), Importance,
Sensitivity, and even Message-text for very small messages.

ReportSummary is used for reporting on a delivery report. The report details include the
MessageSubmissionIdentifier, ContentIdentifier, number of successful deliveries, and the
number of failures. If the MessageSubmissionIdentifier and ContentIdentifier are the same, then
only one should be included.

4.4.5 SubmitResult
This PDU conveys the result of a Submit Operation.

SubmitResult ::= SEQUENCE {


message-reference [0] INTEGER,
PDU-sequence-number [1] INTEGER,
CHOICE {
success-result [2] CCITT X.411 MessageSubmission abstract operation
Result Set

error-result [3] INTEGER {


SubmissionControlViolated (0),

ElementOfServiceNotSubscribed (1),
OriginatorInvalid (2),

RecipientImproperlySpecified (3),
InconsistentRequest (4),
SecurityError (5),
UnsupportedCriticalFunction (6),
RemoteBindError (7)
}
supplementary-info [4] PRINTABLESTRING OPTIONAL
}
}
message-reference identifies the Inmarsat-C message reference of the message that contained the
SubmitRequest PDU to which this PDU is associated with. This element is omitted if this summary is
not as a result of a SubmitRequest PDU.

PDU-sequence-number is the implicit sequence number of the SubmitRequest PDU within the
Inmarsat-C message. This element is omitted if this summary is not as a result of a SubmitRequest
PDU.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 45
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

success-result corresponds to the Result Set definition for the CCITT X.411 MessageSubmission
abstract operation.

error-result corresponds to the Errors definition for the CCITT X.411 MessageSubmission abstract
operation.

supplementary-information is additional information that could be helpful in the diagnosis of the


problem.

4.4.6 MbxProblemReport
The MbxProblemReport PDUs is described in section 4.3.7.

5 Reference Definitions for Services

5.1 Reference Definition of ASN.1 for MTA Protocol


INMARSAT-CMTAService {

-- some OID here -- }

DEFINITIONS IMPLICIT TAGS ::=


BEGIN

IMPORTS

Message, Report, Probe FROM MTAAbstractService {joint-iso-ccitt mhs-motis(6) mts(3) modules(0)


mta-abstract-service(2)}

-- Protocol version number of the protocol defined here

ProtocolVersion INTEGER ::= 1

-- PDUs available for transmission

MTAmEStoLES ::= CHOICE {


[0] Message,
[1] Report,
[2] Probe,
[3] MTARegister
[4] MTAProblemReport
-- Implementations should expect additional PDU types to be defined in future protocol
versions
}

MTAlEStoMES ::= CHOICE {


[0] Message,
[1] Report,
[2] Probe,
[3] MTARegisterResponse
[4] MTAProblemReport
-- Implementations should expect additional PDU types to be defined in future protocol
versions
}

-- PDU types

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 46
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

MTARegister ::= SEQUENCE {


reports-at-LES [0] BOOLEAN DEFAULT FALSE,
mES-inactive [1] NULL OPTIONAL,
private-information [2] SET OF PrivateRegistration OPTIONAL
mES-protocol-version [3] INTEGER OPTIONAL,
}

PrivateRegistration ::= SEQUENCE {


type [0] INTEGER,
value [1] OCTET STRING (SIZE (1..1024)) OPTIONAL
}

RegisterResponse ::= SET {


message-reference [0] INTEGER,
PDU-sequence-number [1] INTEGER,
status [2] INTEGER {
registration-accepted (0),
requested-facility-not-supported (1),
registration-not-permitted (2),
invalid argument (3)
},
lES-protocol-version [3] INTEGER OPTIONAL
supplementary-information [4] IA5String (SIZE (1..128)) OPTIONAL,
}

-- PDU types used in both directions

MTAProblemReport ::= SEQUENCE {


message-reference [0] INTEGER,
PDU-sequence-number [1] INTEGER OPTIONAL,
problem [2] ENUMERATED {
bad-message (0)
unrecognised-PDU-type (1),
unsupported-protocol-version (2)
},
protocol-version [3] INTEGER OPTIONAL
supplementary-information [4] PRINTABLESTRING (size 1..132) OPTIONAL
}

END

5.2 Reference Definition of ASN.1 for Mailbox Protocol


INMARSAT-CMailboxService { -- some OID here -- }

DEFINITIONS IMPLICIT TAGS ::=


BEGIN

IMPORTS

MessageSubmissionIdentifier, MessageSubmissionTime, ContentIdentifier, ExtensionField, ORName


FROM MTSAbstractService {joint-iso-ccitt mhs-motis(6) mts(3) modules(0) mts-abstract-service(1)}

ImportanceField, SensitivityField FROM IPMSInformationObjects {joint-iso-ccitt mhs-motis(6) ipms(1)


modules(0) information-objects(2)}

ub-subject-field FROM IPMSUpperBounds {joint-iso-ccitt mhs-motis(6) ipms(1) modules(0) upper-


bounds(10)}

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 47
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

PresentationAddress FROM SelectedAttributeTypes {joint-iso-ccitt ds(5) modules(1)


informationFramework(1) }

MSBindArgument, Filter FROM MSAbstractService {joint-iso-ccitt mhs-motis(6) ms(4) modules(0)


abstract-service(1)};

-- Protocol version number of the protocol defined here

ProtocolVersion INTEGER ::= 1

-- PDUs available for transmission

MailboxMEStoLES ::= CHOICE {


[0] DeletionRequest
[1] MESRegister,
[2] MessageSubmission,
[3] ProbeSubmission,
[4] RetrievalRequest,
[5] SummaryRequest,
[6] MbxProblemReport
-- Implementations should expect additional PDU types to be defined in future protocol
versions
}

MailboxLEStoMES ::= CHOICE {


[0] DeletionResult,
[1] MesRegisterResponse
[2] RetrievedMessage
[3] SummaryReport,
[4] SubmitResult,
[5] MbxProblemReport
Implementations should expect additional PDU types to be defined in future protocol versions
}

-- PDU types for the mailbox service, MES to LES

MESRegister ::= SEQUENCE {


[0] SET OF RegisterRequest
mES-protocol-version [1] INTEGER OPTIONAL,
}

RegisterRequest ::= CHOICE {


[0] MailboxAccessInfo,
inclusion-criteria [1] Filter,
no-summary-criteria [2] Filter,
expedited-tx-criteria [3] Filter,
[4] SummaryControls,
default-forward-destination [5] ORName,
default-retrieval-type [6] RetrievalType,
auto-ipm-notifications [7] BOOLEAN,
private-info [7] PrivateRegistration,
terminate-service [8] NULL
}

MailboxAccessInfo ::= SEQUENCE {


[0] MSBindArgument OPTIONAL, -- If either is absent, LES defaults for
[1] PresentationAddress OPTIONAL, -- this MES are used
x121-address [2] NumericString (SIZE (1..16)) OPTIONAL,

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 48
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

[3] NetworkType OPTIONAL


}

NetworkType ::= INTEGER {


x25 (0),
ISDN (1),
dial-up-APS (2)
-- Other standard values for further study
-- Values 100..199 are reserved for private use by LES operators
}

SummaryControls ::= SEQUENCE {


summary-on-login [0] BOOLEAN DEFAULT FALSE,
auto-summary-interval [1] INTEGER -- In hours
}

PrivateRegistration ::= SEQUENCE {


type [0] INTEGER,
value [1] OCTET STRING (SIZE (1..1024)) OPTIONAL
}

MessageSubmission ::= SEQUENCE {


result-required [0] NULL OPTIONAL,
SEQUENCE {
MessageSubmissionEnvelope,
Content
}
}

ProbeSubmission ::= SEQUENCE {


result-required [0] NULL OPTIONAL,
SEQUENCE {
ProbeSubmissionEnvelope,
}
}

SummaryRequest ::= SEQUENCE {


message-states ENUMERATED {
all-messages (0),
new-only (1),
new-and-listed (2)
retrieved-only (3) } DEFAULT all-messages
}

RetrievalRequest ::= SEQUENCE {


[0] RetrievalType OPTIONAL, -- If absent, registered default is used
ms-reference-numbers [1] SEQUENCE OF INTEGER
}

RetrievalType ::= ENUMERATED {


envelope-and-content (0),
envelope-only (1),
content-only (2)
}

DeletionResult ::= SET {


message-reference [0] INTEGER,
PDU-sequence-number [1] INTEGER OPTIONAL,
result-set [2] SEQUENCE OF SET {

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 49
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ms-reference-number [0] INTEGER


result-code [1] INTEGER {
deleted (0)
not-deleted (1)
}
}
}

-- PDU Types, LES to MES

MesRegisterResponse ::= SET {


message-reference [0] INTEGER,
registration-result [1] SEQUENCE OF SEQUENCE {
problem [0] RegisterRequest OPTIONAL
result-code [1] INTEGER {
success (0)
unspecified-error (1),
invalid-syntax (2),
prohibited-by-LES-policy (3),
not-supported-by-MS (4),
service-not-subscribed (5),
unable-to-bind-to-MS (6),
change-by-LES-operator-only (7) }
supplementary-info [2] PRINTABLESTRING OPTIONAL }
}

SubmitResult ::= SEQUENCE {


message-reference [0] INTEGER,
PDU-sequence-number [1] INTEGER,
CHOICE {
success-result [2] CCITT X.411 MessageSubmission abstract operation
Result Set
error-result [3] INTEGER {
SubmissionControlViolated (0),
ElementOfServiceNotSubscribed (1),
OriginatorInvalid (2),
RecipientImproperlySpecified (3),
InconsistentRequest (4),
SecurityError (5),
UnsupportedCriticalFunction (6),
RemoteBindError (7)
}
supplementary-info [4] PRINTABLESTRING OPTIONAL
}
}

SummaryReport ::= SEQUENCE {


message-reference [0] INTEGER OPTIONAL,
PDU-sequence-number [1] INTEGER OPTIONAL,
summaries [2] SEQUENCE OF SEQUENCE {
ms-reference-number [0] INTEGER,
arrival-time [1] UTCTime,
too-large-to-retrieve [2] NULL, -- If present, the message is too large to retrieve
CHOICE {
[3] MessageSummary,
[4] ReportSummary
}
}
}

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 50
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

MessageSummary ::= SEQUENCE {


originator [0] ORName,
[1] ContentType DEFAULT built-in {2},
content-length [2] INTEGER,
subject [3] TeletexString (SIZE (1..20)) OPTIONAL,
importance [4] ImportanceField OPTIONAL,
sensitivity [5] SensitivityField OPTIONAL
message-text [6] PRINTABLESTRING (SIZE (1..132)) OPTIONAL
}

ReportSummary ::= SEQUENCE{


[0] MesssageSubmissionIdentifier OPTIONAL,
[1] ContentIdentifier OPTIONAL,
successful-deliveries [2] INTEGER DEFAULT 1,
failures [3] INTEGER DEFAULT 0
}

RetrievedMessage ::= SEQUENCE {


message-reference [0] INTEGER,
PDU-sequence-number [1] INTEGER,
ms-reference-number [2] INTEGER,
[1] MessageDeliveryEnvelope, OPTIONAL
[2] Content, OPTIONAL
[3] ReportDeliveryEnvelope OPTIONAL,
no-longer-available [4] NULL OPTIONAL
}

-- PDU types used in both directions

MbxProblemReport ::= SEQUENCE {


message-reference [0] INTEGER,
PDU-sequence-number [1] INTEGER OPTIONAL,
problem [3] ENUMERATED {
bad-message (0)
unrecognised-PDU-type (1),
unsupported-protocol-version (2)
},
protocol-version [2] INTEGER OPTIONAL
supplementary-information [3] PRINTABLESTRING (size 1..132) OPTIONAL
}

END

6 Conformance
Minimal conformance requirements are specified for implementations of Inmarsat-C X.400 Enhanced
Interworking; this ensures that all implementations will interwork to provide a minimal level of service.
The implementation of additional protocol elements and the associated services are at the option of
the service provider or equipment manufacturer; however, support for more than minimal
conformance is encouraged. The term LES Implementations should be interpreted to include all
terrestrial implementations of the Inmarsat-C Enhanced X.400 interworking protocols, whether as an
integral part of a LES or as a remote IWU.

6.1 General Requirements

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 51
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1. All implementations shall support reception of any Inmarsat-C message for which the
presentation code corresponds to the service implemented. If the message contents are not a
valid encoding according to the version of the protocol definition that has been implemented,
this shall be signalled with a MtaProblemReport or a MbxProblemReport PDU. If the
message contents contain PDUs which are in accordance with the protocol specification, the
implementation shall not signal a decoding error, even if the associated semantics have not
been implemented.

2. All MES implementations shall support configuration of the IWU number to which the Inmarsat-
C messages are addressed.

3. LES implementations offering registered service shall support configuration of the registered
parameters by manual procedures in addition to any support that may be provided for the
MTARegister or MESRegister PDUs. This allows for MES implementations which do not
support registration.

6.2 MTA Service


1. All implementations shall support reception of the Message, Report, Probe,
MbxProblemReport and MTAProblemReport PDUs, and shall implement the associated
procedures for processing these PDUs.

2. LES implementations shall support reception of MTAProblemReport and MTARegister PDUs;


however, support of Registration may be limited to the generation of RegisterResponse PDUs
with status registration-not-permitted if the implementation does not wish to support dynamic
registration. Support for report generation at the LES is optional.

3. MES implementations may support transmission of MTARegister PDUs; if support is provided,


reception of RegisterResponse PDUs shall also be supported.

4. MES implementations should support generation of delivery reports and the associated Report
PDUs; however, such support may be omitted if support is the MTARegister PDU is supported,
requesting reports-at-LES. Such implementations will only provide satisfactory performance
when used with LES services which support report generation. Transmission of Message and
Probe PDUs is optional (to allow for receive-only applications); however, most practical
configurations will at least require transmission of Message.

6.3 Mailbox Service


1. LES implementations shall support reception of all defined PDU types; however, support may
be limited as follows. The parameters of the SummaryRequest may be ignored, such that a full
summary is always provided. The implementation may implement only some of the requests in
MESRegister (or none at all), provided that a RegisterReject is generated for unsupported
requests.

2. LES implementations shall support transmission of all of the currently defined PDU types under
the circumstances where they are required in response to a received PDU. Implementation of
automatic actions (such as summaries at login) is optional.

3. MES implementations shall support reception of SummaryReport. Other PDU types shall be
supported for reception if support is provided for transmission of PDUs that request them:
RetrievedMessage if RetrievalRequest supported, SubmitReport if MessageSubmission if
any submissions are supported; RegisterReject if any MESRegister is supported.
Transmission of DeletionResult shall be supported if DeletionRequest is supported.

6.4 X.400 Conformance

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 52
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The requirements stated above consider only the Inmarsat-specific protocols used to transfer
messages across the Inmarsat-C system. In addition, the UAs and MTAs used at the MES are
required to observe the requirements of X.400-series recommendations and the appropriate
functional standards.

In the case of the MTA service, the software provided at the mobile shall operate according to the
protocol and procedures specified in X.411, and shall conform to the requirements of International
Standardised Profile AMH11 (ISP 10611-3) with the exception that the use of MTAbind is not
applicable. The transfer procedures and protocols specified in this document replace the mapping
onto OSI services specified by X.419. Deviation from the procedures of X.411 is permitted in that
generation of delivery reports may be omitted; such implementations shall only be provided for use in
the registered MTA service and in conjunction with a LES implementation that supports registration of
reports-at-LES. Service operators may wish to impose additional conformance requirements in
respect of profiles for the content protocols.

In the case of the Mailbox service, message submission shall observe the requirements for
MessageSubmissionEnvelope specified in X.411, and the additional constraints specified in
International Standardised Profile AMH12 (ISP 10611-4). Facilities provided for message retrieval will
depend upon the application, and no mandatory requirements are specified. Service operators may
wish to impose additional conformance requirements in respect of profiles for the content protocols

NOTE: At the time of writing, the ISP documents referenced above are at draft stage, and have not
yet been published by ISO/IEC. Until such time as the final ISPs are published, conformance to
corresponding regional profiles may be acceptable.

7 Encoding and Mapping onto Inmarsat-C Channels and Signals

7.1 Outline
Both the mailbox service and the MTA service are described in terms of the exchange of PDUs, for
which ASN.1 definitions are given. To realise the services, a concrete encoding of these PDUs and
the mapping onto Inmarsat-C channels and signals is defined. The encoding methods are identical
for the two services, but transactions for each service are segregated; it is possible for a single MES
to participate in both services simultaneously, but if so the two services operate entirely
independently.

No specific limit is specified for the size of PDUs to be encoded ; however, under typical conditions
they will often be small - perhaps less than 2K byte. Furthermore, there will often be several PDUs
available for transmission at the same time - multiple items that have been queued for transmission,
outstanding acknowledgements etc.. The encoding therefore permits more than one PDU to be
encoded in a single Inmarsat-C message. The Inmarsat-C system limits the size of its messages to
approximately 32K byte, which represents a fundamental limit on the size of a group of PDUs;
however, the maximum size of an individual uncompressed PDU will vary according to the degree of
compression that is achieved. The following rules are imposed to ensure compatibility:

• Implementations shall support reception of Inmarsat-C messages up to the maximum size


allowed by the Inmarsat-C protocols. Implementations may impose a lower limit on the size of
messages transmitted13.

• The maximum size of a collection of PDUs to be transmitted in one Inmarsat-C message shall
not exceed 65536 bytes.

13 The exact limit is different in the MES-to-terrestrial and terrestrial-to-MES directions.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 53
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The encoding procedures to be followed are the same whether it is the LES or the MES that is
transmitting, although the detail of the mapping onto Inmarsat-C protocols is asymmetric, due to the
asymmetry of those protocols.

The encodings currently specified all use the store-and-forward message service of the Inmarsat-C
system. Use of the Data Reporting service for some purposes (particularly for requests in the Mailbox
service) is for further study.

7.2 Detailed Procedures

Figure 14: Inmarsat-C Message Format

bit 7 bit 0

0 0 0 protocol version (6 bits)


1
PDU size field
2

3
Compressed Size

PDU: Compressed envelope and parts


of the content

Uncompressed PDU body parts

PDU size field

Compressed Size

Second PDU

More PDUs so long as they fit into the data


area of the message packet

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 54
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 14 illustrates the packing of PDUs within an Inmarsat-C message which can contain more than
one PDU. Each PDU is preceded by two size fields. The first size field indicates the total size of the
PDU, after compression. The second size field indicates the amount of bytes from the start of the
PDU that have been arithmetically encoded. If the second size field is zero, this implies no arithmetic
encoding has been applied to the PDU.

7.2.1 Transmitting Station Procedure


1) All local processing that may result in the generation of further PDUs is completed, resulting in
a queue of PDUs for transmission. Each PDU is encoded according to the Basic Encoding Rules
of ASN.114. The PDU is then optionally compressed to reduce its size.

The compression method used is a form of arithmetic encoding which applies only to a finite
number of bytes from the start of the PDU. This number of bytes shall include the envelope and
the heading portion of the content up to and excluding body parts. Compression on the body
parts is not allowed.

The common arithmetic encoding algorithm used by the implementors is provided by Inmarsat.

2) If there are many PDUs awaiting transmission, a suitable number are selected to be transmitted
in a single Inmarsat-C message. Each (compressed) PDU is preceded by a two byte length
field identifying the size of PDU. The total size of the compressed PDUs selected and including the
size fields, shall not exceed the data area of the message packet. The selection of multiple
PDUs for transmission in a single Inmarsat-C message is entirely at the option of the
implementor.

3) The PDUs are assembled into a continuous stream of data.

4) An Inmarsat-C message is constructed and presented for transmission.

Figure 15: Encoding Procedure

1. RAW PDUS PDU PDU PDU

2. ARITHMETIC
ENCODING

3. CONCATENATION

4. ENCAPSULATION

INMARSAT-C MESSAGE

7.2.2 Receiving Station Procedure


1) On receipt of an Inmarsat-C message, the text area is examined to determine that the total size
indicated by the PDU size fields does equal to the size of the total text received. If the totals
differ, then the PDUs have not been packed correctly and the Inmarsat-C message should then
be rejected by the MTAProblemReport or the MbxProblemReport PDUs specifying the
unrecognised-PDU-type.

14Any valid ASN.1 encoding (as specified in X.209) may be used. However, the use of definite-form
length encoding is preferred, as this minimises the number of bytes to be transmitted.
Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 55
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2) Each PDU is then extracted. If the compression size is greater than zero, the amount of bytes
(as indicated by this compression size) from the start of the PDU is then arithmetically decoded.
The decompressed PDU is then formed from the decoded information together with the rest of
the uncompressed PDU portion.

3) Each PDU having been decoded is then processed accordingly.

7.3 Mapping onto Inmarsat-C Signals

7.3.1 LES to MES Transfer


Each Inmarsat-C message is transferred by means of the standard To-Mobile call procedure for a
store-and-forward message.

The use of fields in the Announcement packet is as follows:

Service: 0 - Store and forward Messaging

Direction: 0 - To-Mobile

Priority: 0 - Routine

Presentation: 81H for Unregistered MTA Service,

82H for Registered MTA Service,

83H for Mailbox Service,

Last Count: Number of bytes used in the last TDM packet.

7.3.2 MES to LES Transfer


Each Inmarsat-C message is transferred by means of the standard From-Mobile call procedure for a
store-and-forward message. Addressing in the Inmarsat-C signalling identifies the Interworking Unit
(IWU) or Message Service Access Point (MSAP Server) which is to handle the message, rather than
the X.400 address of the ultimate recipient (which is carried within the message itself). The IWU or
MSAP Server number is specified by a 24-bit number; for the cases where the user is registered with
a particular IWU or MSAP Server, a non-zero IWU or MSAP Server number is specified and the
Inmarsat-C message will be conveyed (if possible) to the IWU in question. The special case of the
IWU or MSAP Server zero number is reserved to mean any IWU or MSAP Server offering service to
any user (e.g. the non-registered Mailbox service) - this will typically be an IWU or a MSAP Server
located at whichever LES receives the message.

The use of fields in the Assignment Request packet is as follows:

Protocol: 0 - Store and forward

Service Dependent Description: Message length (packets)

Destination Network: 4 - X.400 netwok

Extension Length: 1

Address Location: 0 - address information is in this packet

Destination Extension: 81H for Unregistered MTA Service

82H Registered MTA Service

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 56
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

83H for Mailbox Service

24 bits identify IWU or MSAP server

The addressing information here identifies the IWU or MSAP Server to which this Inmarsat-C
message is sent, not the addresses to which any contained X.400 messages might be sent. The
Destination Extension differentiates between X.400 Basic Interworking and Enhanced Interworking,
being a copy of the Presentation code carried in the message packets.

The use of fields in the first Message packet is as follows:

Class: Normally set to 0 (Immediate Delivery); optionally 1

Confirmation Request: 1 for first/last message, optional for others

Length: 4 - additional information field not used

Presentation: 81H for Unregistered MTA Service

82H for Registered MTA Service

83H for MAilbox Service

Last Count: Count of bytes in the last message packet

The Address Information field in confirmation packets is not used (i.e. zero length). The Attempts field
is normally set to 1; the value is not significant.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 57
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Annex A : Support of X.400/F.400 Elements of Service

1 Introduction
This annex considers the extent to which X.400 Elements of Service may be supported in Inmarsat-C
enhanced interworking. The initial Inmarsat-C X.400 Basic Interworking service used a very simple
protocol, which prevented implementation of a number of the Elements of Service. One of the goals
of the Enhanced Interworking specification was to define more sophisticated protocols which would
allow as many as possible of the Elements of Service (EoS) to be supported.

In the case of the MTA service, there is no deviation from the standard protocols at the X.400 level
and hence all Elements of Service may be supported. In the case of the Mailbox service, a special
protocol is used in place of the standard P7 protocol, and in some cases this limits the Elements of
Service which may be provided. The limitations of the mailbox service are shown in the table below.
When considering a particular implementation, it should be noted that most elements of service
require that the corresponding protocol elements have been implemented - in which case the table
below indicates the maximum possible level of support assuming that both the service operator and
the mobile equipment manufacturer have implemented all of the necessary protocol elements. In
some cases the EoS is required to be implemented in some other part of the MTS (perhaps in a
Physical Delivery Access Unit) and hence is independent of the local implementation. Specification of
which elements should be supported in a particular product is beyond the scope of this document.

2 Notation
Ref Clause reference in CCITT rec. X.400/F.400(1992).

M->T Classification of support in respect of messages sent from Mobile subscriber to


Terrestrial subscriber.

T->M Classification of support in respect of messages sent from Terrestrial subscriber to


Mobile subscriber.

Support levels are classified as follows:

S Supported transparently across Inmarsat-C system; support in any particular


implementation will depend upon the level of support in the UAs used.

S* Supported by the specific protocols for Inmarsat-C enhanced interworking. The exact
service provided may not be identical to that which is provided by the X.400 protocols.

InmC Support provided by existing Inmarsat-C facilities.

T Supported (if required) by the terrestrial networks - no impact on Inmarsat-C


implementations.

N Not supported by current protocols.

n/a Not applicable.

3 Mailbox Service
Ref Service Name M->T T->M
B.1 Access management InmC InmC
B.2 Additional physical rendition S n/a
B.3 Alternate Recipient Allowed S T

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 58
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

B.4 Alternate Recipient Assignment T T

Ref Service Name M->T T->M

B.5 Authorizing users indication S S


B.6 Auto-forwarded indication n/a S
B.7 Basic physical rendition T n/a
B.8 Blind copy recipient indication S S
B.9 Body part encryption indication S S
B.10 Content confidentiality S S
B.11 Content integrity S S
B.12 Content type indication S S
B.13 Conversion prohibition S T
B.14 Conversion prohibition in case of loss of information S T
B.15 Converted indication T S
B.16 Counter collection S n/a
B.17 Counter collection with advice S n/a
B.18 Cross-reference indication S S15
B.19 Deferred delivery S T
B.20 Deferred delivery cancellation N16 T
B.21 Delivery notification S T
B.22 Delivery time stamp indication T S
B.23 Delivery via bureaufax service S n/a
B.24 Designation of recipient by directory name S T
B.25 Disclosure of other recipients S S
B.26 DL expansion history indication T S
B.27 DL expansion prohibited S T
B.28 Express mail service S n/a
B.29 Expiry date indication S S
B.30 Explicit conversion S T
B.31 Forwarded IP message indication S S
B.32 Grade of delivery selection S T
B.33 Hold for delivery T n/a
B.34 Implicit conversion T T
B.35 Importance indication S S
B.36 Incomplete copy indication S S
B.37 IP-message identification S S
B.38 Language indication S S
B.39 Latest delivery designation S T
B.40 Message flow confidentiality S S
B.41 Message identification S* S
B.42 Message origin authentication S S
B.43 Message security labelling S S
B.44 Message sequence integrity S S
B.45 Multi-destination delivery S T
B.46 Multi-part body S S17
B.47 Non-delivery notification S n/a
B.48 Non-receipt notification request S S

15The cross reference is made available to the mobile user, but may not be useful unless the user
has large amounts of local storage, as the current protocol does not allow the user to search the
Message Store by reference.

16 It would be possible to extend the protocol to provide this service, if desired.

17 When retrieving a message, the entire content is transferred from the mailbox to the mobile
terminal, where the part(s) of the body are decoded locally. It would be possible (with considerable
increase in complexity) to extend the protocols to allow individual body parts to be retrieved.
Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 59
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

B.49 Non-repudiation of delivery S T


B.50 Non-repudiation of origin S S

Ref Service Name M->T T->M

B.51 Non-repudiation of submission S T


B.52 Obsoleting indication S S
B.53 Ordinary mail T n/a
B.54 Original encoded information types indication S S
B.55 Originator indication S S
B.56 Originator requested alternate recipient S T
B.57 Physical delivery notification by MHS S n/a
B.58 Physical delivery notification by PDS S n/a
B.59 Physical forwarding allowed S n/a
B.60 Physical forwarding prohibited S n/a
B.61 Prevention of non-delivery notification S T
B.62 Primary and copy recipients indication S S
B.63 Probe S T
B.64 Probe origin authentication S T
B.65 Proof of delivery S T
B.66 Proof of submission S T
B.67 Receipt notification request S S
B.68 Redirection disallowed by originator S T
B.69 Redirection of incoming messages T N18
B.70 Registered mail S n/a
B.71 Registered mail to addressee in person S n/a
B.72 Reply request indication S S
B.73 Replying IP-message indication S S
B.74 Report origin authentication S T
B.75 Request for forwarding address S n/a
B.76 Requested delivery method S n/a
B.77 Restricted delivery T N19
B.78 Return of content S T
B.79 Secure access management N N
B.80 Sensitivity indication S S
B.81 Special Delivery S n/a
B.82 Stored message alert T S*
B.83 Stored message auto-forward T N20
B.84 Stored message deletion T S*
B.85 Stored message fetching T S*
B.86 Stored message listing T S*
B.87 Stored message summary T S*
B.88 Subject indication S S
B.89 Submission time stamp indication S S
B.90 Typed body S S
B.91 Undeliverable mail with return of physical message T n/a
B.92 Use of distribution list S S
B.93 User/UA capabilities registration T N21

18This service, if implemented, would be supported by the MTA associated with the Message Store.
The current specification does not prevent the use of redirection, but the protocol currently provides
no means to control it.

19 Note that no protocol is currently defined to support this EoS in the terrestrial service either.

20This service, if implemented, would be supported by the Message Store. The current specification
does not prevent the use of auto forwarding, but the protocol currently provides no means to control it.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 60
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

B.94 Auto-submitted indication S S


B.95 MS register S* S*

21 No protocol is provided to control this EoS. However, the service may be provided by subscription.
Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 61
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Annex B: Registration of Identifiers

A number of elements of the X.400 Enhanced Interworking protocols require registration in order to
ensure uniqueness, and hence unambiguous operation throughout the system.

1 Interworking Unit and Message Service Access Point Numbers


Interworking units and MSAP Server are identified by 24-bit numbers. The special value 0x000000 is
reserved to designate any interworking unit that provides ‘open’ access without prior registration of
the user - typically, this will be an IWU located at the current LES. Non-zero values designate specific
interworking units.

The numbers are allocated by Inmarsat.

2 X.400 Domains with Inmarsat Country


Domain names to be used in an X.400 address have to be registered in accordance with procedures
established by the country specified by the country code; as a national matter, these may require
national uniqueness of ADMD names, PRMD names and/or Organization names.

In the Inmarsat-C X.400 Enhanced Interworking services, both Terrestrial addresses (i.e. addresses
incorporating a country code which identifies a recognised country), and Inmarsat addresses
(incorporating the Inmarsat country code) may be used. Terrestrial addresses have to be registered
in accordance with the standard procedures for the country concerned, and are not under the control
of Inmarsat. Inmarsat addresses are registered according to the procedures specified below.

Addresses incorporating the ADMD name “ “ (a single space), the PRMD name “INMARSATC”, and a
numeric organization name identify a particular MES, the organization name carrying the MES ID in
IA5-coded decimal. In this case, the registration authority is the existing register of MES IDs;
responsibility for the registration of components below the organization name is delegated to the MES
operator. Other addresses incorporating the Inmarsat country code and the ADMD name “ “ are
reserved for future assignment by Inmarsat.

Registration of addresses incorporating the Inmarsat country code and an ADMD name other than “ “
is delegated to service operators (typically LES operators). Inmarsat acts as the registration authority
for ADMD names beneath the Inmarsat country code, and delegates responsibility for registration of
subordinate components to the ADMD operators. In this case, PRMD and organization names are
relative to the ADMD name and are not required to be globally unique.

3 Private Registration Numbers


The register operations in the Mailbox and MTA services allow for privately-defined extensions to the
protocol. These extensions may be defined by service operators or equipment manufacturers; each
type of private extension is uniquely identified by an integer value. Inmarsat maintains a register of
these assigned values to ensure uniqueness. Service operators or equipment manufacturers should
apply to Inmarsat for the assignment of a type number whenever a private registration is defined.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 62
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Annex C: Compression Parameters

Adaptive arithmetic encoding is used, whereby the entire message is represented as a binary fraction,
based on the combined probabilities of successive characters. The general method is described by I.
H. Witten, R. M. Radford and J. G. Cleary, in Communications of the ACM vol 30 #6 (1987) pp 520-
540. This annex describes the specific version of this method used in Inmarsat-C X.400 Enhanced
Interworking.

A third order model is used (i.e. frequency tables are maintained for individual symbols, and for each
symbol given up to three previous symbols. The frequency tables are limited to a maximum of 32,000
entries - the limit applying to the sum of symbol, digraph, and trigraph table entries. Once the limit is
reached the tables are not updated further, and encoding continues as for a non-adaptive method
until a special symbol is received (see below). Frequency counts are maintained to a precision of 10
bits. If the processing of a symbol causes the frequency count to reach the maximum value that may
be represented in 10 bits, all frequency counts are divided by two after processing the symbol (with
odd values being rounded up).

Symbols used are 10 bits long: the values 0x000 to 0x0FF are used for simple data values; values
0x100 to 0x2FF are used to designate dictionary entries, and values 0x300 to 0x3FF are special
symbols used to control the encoding process.

Special symbols have the following effects:

0x3FF Indicates end of data stream.

0x3FE Causes the frequency tables to be reset, such that all symbols have frequency 1

0x3FD Causes the frequency tables to be reset such that symbols 0x000 to 0x0FF and
0x3F0 to 0x3FF have frequency 1, with all other symbols having frequency zero.
Note that this prevents dictionary symbols from being used.

0x3FC Causes the frequency tables to be reset to values typical of ASN.1 encoded data.

0x3FB Causes the frequency tables to be reset to values typical of English-language text.

0x300-0x3FA Reserved for future use.

Volume 3: Earth Station Requirements, Part 1: Land Earth Station Requirements, Page: 63
Chapter 5: Inmarsat-C / Enhanced X.400 Interworking
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 1: Introduction

Contents

1 The Inmarsat-C Mobile Earth Station ....................................... 2

2 The MES Definition Documentation .......................................... 2


2.1 Purpose and Scope ..........................................................................................2
2.2 Structure of the Document ................................................................................2
2.3 Related Documents ..........................................................................................3

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 1
Chapter 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 The Inmarsat-C Mobile Earth Station


The Mobile Earth Station (MES) is the terminal equipment through which users gain access to the
services provided by the Inmarsat-C system. It consists of a Data Circuit Terminating Equipment
(DCE) which acts as an interface to the satellite network and a Data Terminal Equipment (DTE) which
provides the user interface.

MESs are produced by a number of different manufacturers and, within the confines of this
specification, the design can be varied to suit a variety of applications. It should be noted in particular
that MESs can be used for land based or for maritime applications and this specification addresses
any variations in requirements.

Certain of the requirements defined in this specification are mandatory for all MES manufacturers and
relate to the store and forward message transfer service. The provision of other Inmarsat-C services
is optional but if they are provided then the design of the MES must comply with this specification.

2 The MES Definition Documentation

2.1 Purpose and Scope


This part of the System Definition manual presents the technical requirements and recommendations
for an Inmarsat-C MES. These requirements must be satisfied before the equipment may be utilized
in the Inmarsat system. Procedures for type approval of a manufacturer's design are available from
Inmarsat. An Inmarsat-C MES is defined as an MES which satisfies the mandatory requirements of
this specification.

This specification defines the mandatory requirements for operation with the NCS, LES and space
segment facilities of the Inmarsat system. The purpose of these requirements is to ensure that all
MESs having access to the system will provide adequate performance and not endanger the integrity
of system operations. Requests for changes to, or waiver of, the requirements set forth herein, will be
considered provided they can be justified as consistent with the purpose of the specification. Such
requests should be forwarded to Inmarsat together with all substantiating details necessary to justify
the request.

2.2 Structure of the Document


The main body of this specification is given in Chapter 2 which defines the baseline requirements for a
'Generic' Mobile Earth Station (MES). It is not intended to be used as a stand alone specification.
Chapter 3 defines optional features and functional capabilities and Chapter 4 provides a description of
the Inmarsat recommended DCE-DTE interface control specifications. Subsequent chapters present
the additional or variant technical requirements, where applicable, for the various Mobile Earth Station
types, such as for maritime or land mobile use.

- Chapter 3 provides details of Optional capabilities.

- Chapter 4 defines Inmarsats recommended MES DTE to DCE interface specification.

- Chapter 5 presents the additional technical requirements for Ship Earth Stations.

- Chapter 6 presents the additional technical requirements for Land Mobile Earth Stations.

- Chapter 7 presents the additional technical requirements for Land Portable Earth Stations.

- Chapter 8 gives the technical requirements for an Enhanced Group Call (EGC) receiver.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 2
Chapter 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.3 Related Documents


This volume forms part of a set of documents which define the Inmarsat-C Communications System:

- Volume 1: System Description

- Volume 2: User Services

- Volume 3: Earth Station Requirements:

- Part 1: Land Earth Station Requirements

- Part 2: Mobile Earth Station Requirements

- Part 3: Network Coordination Station

- Part 4: Interstation Signalling Links

- Volume 4: Packet Formats and Usage

- Volume 5: Inmarsat-C SDL

The performance requirements, recommendations and design information contained in this part of this
volume are for designers of MES equipment intended for use in the Inmarsat-C system.

The protocols of the access control and signalling system are defined in Volume 1, which should be
used in conjunction with this document. Packet formats and SDLs are given in Volumes 4 and 5
respectively. Compliance with the MES signalling protocols is a technical requirement of all MESs.

A glossary of terms and a list of abbreviations used throughout the System Definition Documentation
is given in Volume 1. Reference should be made to this for clarification of terms and notation. The
description of the Inmarsat-C communications system which appears in the same volume gives useful
background information and clarifies the role of the MES in the system.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 3
Chapter 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Chapter 2: Technical Requirements for a Mobile


Earth Station

Contents

1 Introduction ............................................................................ 5

2 General Requirements ............................................................. 5


2.1 Classes of Inmarsat-C Mobile Earth Stations....................................................5
2.1.1 Single or Multi-threading ................................................................................5
Table 1: Action of Single-Threading MES when Receiving a Given Packet ............6
2.2 Inmarsat-C Mobile Earth Station Definition .......................................................7
Figure 1: MES Example Block Diagram ..................................................................7
2.3 Mobile Earth Station Functions .........................................................................7
2.4 Mandatory Capabilities......................................................................................7

3 RF Subsystem Requirements ................................................... 8


3.1 General Requirements ......................................................................................8
3.2 Antenna Requirements .....................................................................................8
3.2.1 Gain ...............................................................................................................8
3.2.2 Polarization ....................................................................................................8
3.2.3 Axial Ratio ......................................................................................................8
3.3 Receiver RF Requirements ...............................................................................8
3.3.1 Gain-to-Noise Temperature Ratio ..................................................................8
3.3.2 Received Signal Levels ..................................................................................9
Figure 2: Minimum G/T : Elevation Angle Profile ..................................................... 10
3.3.3 Immunity to Out of Band Signals .................................................................. 11
3.3.4 Receiver Tuning ........................................................................................... 11
3.4 Transmitter RF Requirements ......................................................................... 11
3.4.1 EIRP............................................................................................................. 11
Figure 3: Minimum EIRP : Elevation Angle Profile ................................................ 12
3.4.3 Transmitter "Off" Power Level ...................................................................... 13

Volume 3: User Services, Part 2: Services and Facilities, Page: 1


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.4.4 Spurious Outputs ......................................................................................... 13


3.4.5 Harmonic Output EIRP................................................................................. 13
Figure 4: Spurious and Noise EIRP Limits ............................................................ 14
3.4.6 Phase Noise................................................................................................. 15
3.4.7 Transmitter Tuning ....................................................................................... 15
3.4.8 Frequency Accuracy and Stability ................................................................ 15
3.4.9 Duty Cycles .................................................................................................. 15
Figure 5: MES Induced Phase Noise .................................................................... 16

4 Receiver Performance ........................................................... 17


4.1 To-Mobile Signal Characteristics .................................................................... 17
Figure 6: Receive Phase Noise ............................................................................. 18
4.2 To-Mobile Channel Modulation Characteristics ............................................... 18
Figure 7: Demodulator Predetection Filter ............................................................ 20
4.3 Receiver Selectivity ......................................................................................... 21
4.4 Demodulator Performance .............................................................................. 21
Figure 8: Inmarsat-C Rician Fading Model............................................................ 21
4.5 Continuous Reception Output Performance.................................................... 22
4.6 Acquisition Performance ................................................................................. 22
4.6.1 NCS/LES Tuning .......................................................................................... 22
4.6.2 Re-acquisition after Burst Mode Transfers ................................................... 22
4.6.2.1 2-Frame Slot Mode. ............................................................................................................. 23

4.6.2.2 3-Frame Slot Mode. ............................................................................................................. 23

4.6.3 Re-acquisition after Message transfers ........................................................ 23

5 Transmitter Performance ....................................................... 23


5.1 From-Mobile Message and Signalling Channel Modulation Characteristics .... 23
5.2 Operation with First Generation Satellites ....................................................... 23
5.3 Signalling Channel Characteristics.................................................................. 24
5.4 Message Channel ........................................................................................... 24

6 Access Control Requirements ............................................... 25

Volume 3: User Services, Part 2: Services and Facilities, Page: 2


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

6.1 General ........................................................................................................... 25


6.2 TDMA performance ......................................................................................... 25
6.2.1 TDMA Synchronization ................................................................................ 25
6.2.2 Random Access and Retransmission Slot Selection.................................... 26
6.2.3 Signalling Channel Access Restrictions ....................................................... 26
6.2.4 Message Channel Access Restrictions ........................................................ 27
6.2.5 Operation with Multiple LES TDMs .............................................................. 27
6.3 NCS Common Channel Selection ................................................................... 27
6.3.1 General ........................................................................................................ 27
6.3.2 Expansion of NCS Common Channel .......................................................... 28
6.3.3 Stand Alone Operation ................................................................................. 28
6.3.4 Spot Beam Operation................................................................................... 28
6.4 Mobile Station Identities .................................................................................. 29
6.5 Ocean Region Registration Procedures .......................................................... 29
6.5.1 Logging In .................................................................................................... 29
6.5.2 Logging Out ................................................................................................. 30
6.6 Idle and Busy Conditions ................................................................................ 30
6.6.1 Priorities ....................................................................................................... 30
6.6.2 Off-Line Operation ....................................................................................... 30
6.6.3 Forced Clearing ........................................................................................... 30

7 Message Processing Requirements ....................................... 30


7.1 General ........................................................................................................... 30
7.2 Character Codes ............................................................................................. 30
7.3 Display Devices .............................................................................................. 31
7.3.1 Message Display (DTE) ............................................................................... 31
7.3.2 Status Display .............................................................................................. 31
7.4 Keyboard (DTE) .............................................................................................. 31
7.5 Mobile Earth Station Memory Capacity Requirements .................................... 31
7.5.1 Message Storage (DCE) .............................................................................. 31
7.5.2 Non-Volatile Memory (DCE) ......................................................................... 32

Volume 3: User Services, Part 2: Services and Facilities, Page: 3


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

7.6 The DTE-DCE Interface .................................................................................. 32


7.6.1 Technical Requirements .............................................................................. 32
7.6.2 Message Transfer ........................................................................................ 33
7.6.3 Control Codes .............................................................................................. 33

8 Alerting Functions ................................................................ 33

9 Testing Functions ................................................................. 33


9.1 Fail-Safe Features .......................................................................................... 33
9.2 Self Monitoring Functions................................................................................ 34
9.3 Performance Verification and Commissioning Testing .................................... 34
9.3.1 General ........................................................................................................ 34
9.3.2 Performance Verification Testing ................................................................. 34
9.3.3 Commissioning Testing ................................................................................ 34

10 Electromagnetic Compatibility ............................................. 34


10.1 General ......................................................................................................... 34
10.2 Limits for Mains Conducted Spurious Emissions .......................................... 34
Figure 9: Maximum Level of Conducted Spurious Voltage into Mains (dBuV
referred to 50 OHMS) ............................................................................................ 36

11 Environmental Conditions ................................................... 36


11.1 Purpose......................................................................................................... 37
Figure 10: Vibration Test Curves .......................................................................... 39
Annex 1: Year 2000 Compliance .......................................................................... 40

Volume 3: User Services, Part 2: Services and Facilities, Page: 4


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

1 Introduction
This chapter describes the baseline requirements for a 'Generic' Inmarsat-C Mobile Earth Station
(MES). This chapter is intended to be used with subsequent chapters of Part 2 of Volume 3 to define
the requirements for specific types of MES.

2 General Requirements

2.1 Classes of Inmarsat-C Mobile Earth Stations


MESs can be classified by the capabilities they provide within the Inmarsat-C system. The basic
classes of MES are defined as follows.

CLASS 0: EGC receive only receiver.

CLASS 1: Mobile earth station providing the following functions;

(i) To-Mobile message transfer

(ii) From-Mobile message transfer

CLASS 2: Two modes of operation (switchable);

(i) As Class 1 but capable of reception of EGC messages (common EGC/Inmarsat-C


receiver) when not engaged in traffic.

(ii) EGC receive only operation.

CLASS 3: As Class 1 but equipped with a second receiver to enable continuous uninterrupted
reception of EGC messages with simultaneous and independent operation.

The technical requirements presented in this chapter are applicable to Classes 1, 2 and 3 MESs.
Class 0 MESs shall meet the technical requirements for an Inmarsat EGC receiver as presented in
Chapter 8. Additionally, Class 2 and Class 3 MESs will simultaneously satisfy the technical
requirements for an EGC receiver.

2.1.1 Single or Multi-threading


An MES that supports more than one activity may be confronted with a demand to start an activity
while it is already engaged in another. If the MES has the capability to handle more than one activity
simultaneously, it may do so. However, an MES that cannot support multiple activities, should follow
the following rules. With the exception of alerts, high priority packets and operator aborts, the MES
shall continue with whatever protocol it is currently engaged in until completion. For example, in the
case of a Class 2 MES not in the EGC receive only mode, if, while receiving an EGC message
addressed to that MES, an announcement is received, the MES should continue with the EGC
processing and ignore the announcement (except in the case where the EGC message being
received is priority 0). The table below shows in more detail the action that the MES should take in
each case. Note especially that a From-Mobile Alert (if supported) will always take precedence,
aborting any current activity.

Volume 3: User Services, Part 2: Services and Facilities, Page: 5


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Table 1: Action of Single-Threading MES when Receiving a Given Packet

Current MES Activity

New packet
addressed to Receiving Receiving Receiving Receiving
terminal and Idle EGC Priority EGC Priority EGC Priority EGC Priority
received in 0 1 2 3
current frame

Handle
EGC Priority=0* Ignore Ignore Ignore Ignore
packet

Handle
EGC Priority=1* packet
Ignore Ignore Ignore Ignore

Handle
EGC Priority=2* packet
Ignore Ignore Ignore Ignore

Abort current Abort current Abort current


Handle activity and activity and activity and
EGC Priority=3* packet handle handle handle
Ignore
packet packet packet
Abort current
Announcement Handle activity and
Ignore Ignore Ignore
Priority=0 packet Handle
packet
Abort current Abort current Abort current Abort current
Announcement Handle activity and activity and activity and activity and
Priority=3 packet Handle Handle Handle Handle
packet packet packet packet

Other Signalling Handle


Ignore Ignore Ignore Ignore
packets packet

Handle
Confirmation Save Save Save Save
packet

Handle
Message Status Save Save Save Save
packet

Poll Handle Poll Ignore Ignore Ignore Ignore

* Only applies to the first packet of an EGC message.


Volume 3: User Services, Part 2: Services and Facilities, Page: 6
Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

2.2 Inmarsat-C Mobile Earth Station Definition


For the purpose of this document, a MES is defined as consisting of a DCE and a DTE as shown in
Figure 1.

Figure 1: MES Example Block Diagram

DCE DTE

SCRAMBLER,
1200 SPS CONVOLUTIONAL
HPA BPSK ENCODER DTE
MODUL'R AND
INTERLEAVER MESSAGE USER
ACCESS AND I/O
CONTROL DATA I/O
AND USER
LO SYNTH'R
MESSAGE INTERFACE
HANDLING MESSAGE
PROCESSOR STORAGE
AND
DEINTERLEAVER, PREPARATION
1200 SPS DECODER FUNCTIONS
LNA BPSK AND OTHER
DEMOD'R DESCRAMBLER I/O
PORTS

The DCE is the link between the DTE and the mobile satellite channel and performs all functions
relating to signalling and access control.

The DTE provides a means of controlling the DCE, displaying received messages, status information,
and formatting messages for transmission.

2.3 Mobile Earth Station Functions


The MES shall be designed to operate with first and subsequent future generations of INMARSAT
satellites in the following frequency bands:

- receive from satellite 1530.0 to 1545.0 MHz

- transmit to satellite 1626.5 to 1646.5 MHz

The mandatory capabilities for each class of MES are described below.

2.4 Mandatory Capabilities


The mandatory capabilities of each class of MESs are:

CLASS 1:

(a) transmitting Store and Forward messages to full telex addresses (CCITT Rec. U.80);

(b) receiving Store and Forward messages;

(c) requesting automatic testing (performance verification) and responding to testing commands.

(d) requesting commencement or termination of service within an ocean region (logging in/out).

Volume 3: User Services, Part 2: Services and Facilities, Page: 7


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

CLASS 2:

As for Class 1 plus:

(a) continuous reception of EGC messages transmitted on the NCS common channel when in the
EGC mode.

CLASS 3:

As for Class 1 plus:

(a) continuous reception of EGC messages transmitted on the NCS common channel.

3 RF Subsystem Requirements

3.1 General Requirements


This section describes the transmitting and receiving L-band RF characteristics of an MES.

3.2 Antenna Requirements


The antenna requirements have been developed to allow the maximum flexibility in the selection of
the antenna and RF equipment configuration so as to provide the performance required for reliable
link operation.

The G/T and EIRP requirements are such that, as a minimum, they may be met by the use of a
suitable unstabilized omnidirectional antenna.

Technical requirements for alternative antenna configuration are presented in Chapter 3.

3.2.1 Gain
The antenna gain, relative to a right hand circularly polarized isotropic antenna over the frequency
ranges 1530.0 to 1545.0 MHz and 1626.5 to 1646.5 MHz, shall be such that the specified receive G/T
and transmit EIRP requirements are satisfied.

3.2.2 Polarization
Right hand circular polarization shall be employed for both receive and transmit, in accordance with
the definition in CCIR Recommendation 573 (1.6.1).

3.2.3 Axial Ratio


The axial ratio over the coverage region (+5° to +90° in elevation and 0-360° in azimuth) shall not
exceed 6dB (2:1).

3.3 Receiver RF Requirements

3.3.1 Gain-to-Noise Temperature Ratio


Using an unstabilized, unsteered antenna, the minimum gain profile and the receiver system noise
temperature, including the antenna, shall be such that the G/T ratio is not less than that described by
the minimum G/T profile (elevation) of Figure 2 in the frequency band 1530.0 to 1545.0 MHz and
represented as:

G/T ≥ -23-1.5sin(θ-5) dB/K + 5° ≤ θ ≤ + 90°

Volume 3: User Services, Part 2: Services and Facilities, Page: 8


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

G/T ≥ -27+4cos[4.5(θ-5)] dB/K -15° ≤ θ ≤ + 5°

where θ is the elevation angle in degrees with zenith at +90°.

The G/T requirement shall be met under the following conditions:

(a) clear sky climatic conditions;

(b) sky at elevations greater than 0°, sea at elevations less than 0°;

(c) including the noise contribution of the receiver low noise amplifier and following stages at an
ambient temperature of 25°C;

(d) including the loss introduced by a dry radome, where a radome is fitted; and

(e) with the transmitter at the specified output level where a diplexer is used (see Section 3.4.1), or
at the specified "off" level (see Section 3.4.3).

The antenna gain is as defined in Section 3.2.1 and the receiving system noise temperature is
expressed in dB relative to 1K. Gain and Temperature must be referred to a suitable common point
within the receiving system.

3.3.2 Received Signal Levels


The design of the MES receiving system and demodulator shall be such as to ensure full compliance
with the performance requirements for the following received signal levels at the earth's surface1:

(a) minimum unfaded single carrier power flux density: –148 dBW/m2 at 5° elevation angle;

(b) maximum unfaded single carrier power flux density: –136 dBW/m2 at centre of geographical
coverage;
(c) maximum composite power flux density in the 1520 to 1560 MHz range: -92 dBW/m2 from
satellite based systems; maximum single carrier power flux density in the 1513 to 1525 MHz
range: -69 dBW/m2 from terrestrial systems at 10 km distance (note that multiple carriers may
considerably increase the composite power flux density in this range).

The effect of multipath fading using a C/M of 7 dB for a worst case sea state (smooth sea surface), is
such that received carrier levels may typically be expected to rise by more than 4 dB and fall by more
than 10 dB for 1% of the time.

1 These are postulated worst case values and may be subject to change.
Volume 3: User Services, Part 2: Services and Facilities, Page: 9
Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 2: Minimum G/T : Elevation Angle Profile

Note:

1. Gain referred to a right-hand circularly polarised isotropic antenna.

2. Temperature in dB relative to 1K.

3. Minimum G/T profile is circularly symmetrical about the 90° (zenith) axis.

4. G/T not defined for elevation angles from -15° to -90°.

Refer to Volume 1, Chapter 2, Table 1 for details of transponder power levels and bandwidths of first
and future generation INMARSAT satellites.

Volume 3: User Services, Part 2: Services and Facilities, Page: 10


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.3.3 Immunity to Out of Band Signals


The receiving system should have sufficient front end filtering to provide rejection of out of band
emissions from adjacent systems. In particular, sufficient rejection of From-Mobile carriers in the
1626.5 to 1646.5 MHz frequency range must be provided in order to minimize the risk of interference
from other INMARSAT MESs operating in close proximity.

A continuous wave carrier at any frequency within the range 1626.5 MHz to 1646.5 MHz, and at a flux
density level of –15 dBW/m2 at the receiver antenna, with the antenna oriented for maximum signal,
shall not impair the operation or performance of the receiver in any way.

3.3.4 Receiver Tuning


The receiving system shall be able to tune to any channel in the band 1530.0 to 1545.0 MHz in
increments of 5 kHz, starting at 1530.000 MHz and extending up to 1545.000 MHz.

To-Mobile channel numbers are assigned as follows:

Frequency (MHz) Channel Number


Decimal Hexadecimal

1530.000 800010 1F4016


1530.005 800210 1F4216
- - -
1544.995 1399810 36AE16
1545.000 1400010 36B016

3.4 Transmitter RF Requirements

3.4.1 EIRP
The EIRP radiated by the MES shall not be less than that corresponding to the minimum profile
(elevation) of Figure 3 in the frequency band 1626.5 to 1646.5 MHz and represented as:

EIRP ≥ 12–1.5sin(θ-5) dBW + 5° ≤ θ ≤ +90°

EIRP ≥ 8+4cos[4.5(θ-5] dBW –15° ≤ θ ≤ + 5°

where θ is the elevation angle in degrees with zenith at +90°.

The maximum EIRP radiated by the MES in any direction shall not exceed +16 dBW. The variation in
EIRP due to all causes shall be such as to maintain the EIRP towards the satellite within these
specified limits under all operational conditions.

Volume 3: User Services, Part 2: Services and Facilities, Page: 11


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3: Minimum EIRP : Elevation Angle Profile

Note:

1. Gain referred to a right-hand circularly polarised isotropic antenna.

2. Minimum EIRP profile is circularly symmetrical about the 90° (zenith) axis.

3. Maximum EIRP: +16 dBW for all elevation angles from -90° to +90° and all azimuth directions.

Volume 3: User Services, Part 2: Services and Facilities, Page: 12


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.4.2 Transmitted Spectrum


The transmitted spectrum shall not exceed the following limits (in a 1 kHz bandwidth) referred to the
unmodulated carrier:

Offset from Carrier


±4.2 kHz ±48.6 kHz
1st generation (600 s/s) –26.5 dBc –48 dBc
2nd generation (1200 s/s) –23.5 dBc –45 dBc

3.4.3 Transmitter "Off" Power Level


The transmitter shall not radiate more than –45 dBW EIRP and -63 dBW in any 3 kHz bandwidth
between 1626.5 and 1646.5 MHz when not activated, including periods between bursts.

3.4.4 Spurious Outputs


The spurious and noise output EIRP excluding any harmonics in any 3 kHz band shall fall below the
spectrum envelope defined by the following data points:

Frequency (MHz) EIRP/3 kHz (dBW)

1530.0—1545.0 –130
1611.5 –77
1626.5—1646.5(1) –48
1661.5 –77
1751.5 –85
Below 1530.0 and above 1751.5 –85

The EIRP is measured in the direction of maximum antenna gain. A spectrum envelope mask
representing these requirements is shown in Figure 4.

Note (1):

The maximum level of spurious signals in the vicinity of the unmodulated carrier shall fall below the
spectrum envelope defined by the following data points:

Carrier Offset Frequency Maximum Level of Spurious Signals

0 — 5 kHz –25 dBc


5— 100 kHz –45 dBc
100 kHz — 1 MHz –50 dBc

3.4.5 Harmonic Output EIRP


The EIRP of any harmonic product shall be less than –25 dBW for any frequency up to 18 GHz.

Volume 3: User Services, Part 2: Services and Facilities, Page: 13


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 4: Spurious and Noise EIRP Limits

1800
1751.5
Figure 2-4 Spurious and Noise EIRP Limits

1700
1661.5

1646.5

Frequency (MHz)
1626.5

1611.5
1600

1575.0

1545.0

1530.0
1500
–80

–140
–40

–60

–90
–50

–70

–130
–100

–120
–110

Maximum EIRP/3 kHz (dBW)

Volume 3: User Services, Part 2: Services and Facilities, Page: 14


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.4.6 Phase Noise


The phase noise induced on a carrier shall have a power density spectrum not exceeding the limit
mask defined below. If discrete phase noise spectral components are included which exceed the limit
mask, the sum of all discrete and continuous spectral components between 10 Hz and 100 kHz from
the carrier shall not exceed 0.10 radians rms or –20 dBc in SSB. Limit mask for transmitted Phase
Noise at L-band (plotted in Figure 5):

SSB Phase Noise limit, dBc


Offset from Carrier
(in 1 Hz bandwidth):

10 Hz to 100 Hz –11–28Log10(f)
100 Hz to 1 kHz –73+3Log10(f)
1 kHz to 5 kHz –64
5 kHz to 100 kHz +10–20Log10(f)

3.4.7 Transmitter Tuning


The transmitting system shall be capable of transmitting any channel in the band 1626.5 to 1646.5
MHz. Channel assignment are in 5 kHz steps starting at 1626.500 MHz and extending up to
1646.500 MHz. From-Mobile channel numbers are assigned as follows:

Frequency (MHz) Channel Number

Decimal Hexadecimal

1626.500 6000 1770H


1626.505 6002 1772H
— — —
1631.500 8000 1F40H
— — —
1646.495 13998 36AEH
1646.500 14000 36B0H

3.4.8 Frequency Accuracy and Stability


NCS and LES TDM frequencies shall be used as a source for calibrating the MES transmit frequency.

For the duration of all transmissions, the MES shall maintain its transmitted signal frequency at L-
band to within ±150 Hz of the transmit frequency, when referred to the received TDM carrier
frequency.

All MES transmissions, except alerts (if supported), shall be inhibited if the transmit frequency cannot
be maintained to within ±150 Hz of nominal (referred to the received TDM frequency).

3.4.9 Duty Cycles


The maximum possible message length that may be transmitted by an MES in a single From-Mobile
message transfer is 255 packets (up to 31616 bytes of user data).

Volume 3: User Services, Part 2: Services and Facilities, Page: 15


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5: MES Induced Phase Noise

Volume 3: User Services, Part 2: Services and Facilities, Page: 16


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

In order to reduce the power demands of the MES transmitter output stages and power supplies, the
maximum From-Mobile message length for a MES model may be limited to 64 packets (up to 7932
bytes of user data).

The transmitter output stages and power supplies must be adequately rated for quasi-continuous
operation for up to the maximum time required to transmit the longest allowable message. An
additional margin of at least 100% shall also be added to accommodate re-transmission of corrupted
packets. Message transmission may be inhibited, except for alerting (if supported), for a period after
completion of a From-Mobile message transfer in order to prevent overheating of critical components.

For burst mode transmissions on the MES signalling channel the maximum duty cycles (Ton/Toff) are
as follows:

(a) First generation:


2-Frame slot 3.07%
3-Frame slot 2.05%

(b) Future generations:


2-Frame slot 1.54%
3-Frame slot 1.03%

The transmitter HPA and power supplies shall be adequately rated so as to be capable of providing
continuous burst mode operation with these duty cycles.

4 Receiver Performance

4.1 To-Mobile Signal Characteristics


The characteristics listed below are for a single To-Mobile L-band TDM carrier at the surface of the
earth:

(a) expected (single carrier) flux density: Minimum: unfaded flux density at 5o elevation
angle, is –148 dBW/m2,
Maximum: at the centre of geographical
coverage is –136 dBW/m2;

(b) phase noise: the multiplicative phase noise induced on the


carrier is expected to have a power density
spectrum not exceeding the envelope shown in
Figure 6;

(c) additive noise: the unfaded carrier to additive noise density ratio
(up link noise and intermodulation) is expected to
be at least 55.7 dBHz;

(d) absolute average frequency: within ±970 Hz including the effects of vessel
motion;

(e) maximum short term frequency variation: from +50 Hz to –50 Hz in 3 seconds.

Volume 3: User Services, Part 2: Services and Facilities, Page: 17


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 6: Receive Phase Noise

4.2 To-Mobile Channel Modulation Characteristics


The modulation characteristics of all To-mobile transmissions on the NCS common channel and the
LES TDMs are identical:

(a) modulation: unfiltered binary phase shift keying;

(b) interleaving: interleaver implementation is described in Volume


1, Chapter 4, Section 3;

Volume 3: User Services, Part 2: Services and Facilities, Page: 18


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

(c) error control coding: Encoder implementation is shown in Volume 1,


Chapter 4, Section 3;

(d) coded symbol rate: 1200 symbols per second;

(e) symbol rate stability: long term stability ±0.8 parts in 106;

(f) frame length: 10,368 symbols at 1200 symbols/s; 8640.0 ms


nominal duration;

(g) frame synchronization: 128 bit (2 x 64 bit) frame unique word distributed
through the frame to overcome unique word loss
due to multipath fading and to identify carrier
synchronizer cycle slips;

(h) frame unique word: The 128 bit unique word consist of the
following 64 bit sequence transmitted twice:

(j=0) 0000 0111 1110 1010


1100 1101 1101 1010
0100 1110 0010 1111
0010 1000 1100 0010 (j=63)

expressed in hexadecimal:

07EA CDDA 4E2F 28C2

Prior to permuting (and after de-permuting) the


above sequence appears as follows:

(i=0) 0111 1011 1010 1001


0110 1001 0001 0111
0011 0010 1110 1001
1011 1000 1000 1000 (i=63)

expressed in hexadecimal;

7BA9 6917 32E9 B888

The unique word is transmitted uncoded.

(j) ambiguity resolution: unique word polarity;

(k) scrambling: scrambling is described in Volume 1, Chapter 4,


Section 3.

Volume 3: User Services, Part 2: Services and Facilities, Page: 19


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 7: Demodulator Predetection Filter

40
35 kHz
40 dB

30
18 dB
Figure 2-7 Demodulator Predetection Filter

20
16 kHz

3 dB

10
Offset Frequency (kHz)
8 kHz

0
–8 kHz
3 kHz

–10
–20 –30
–40
40

20

10

0
30

Relative Attenuation (dB)

Volume 3: User Services, Part 2: Services and Facilities, Page: 20


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

4.3 Receiver Selectivity


The attenuation vs frequency response of the receiver (from the antenna port to the demodulator
input) shall comply with the limits shown in Figure 7.

4.4 Demodulator Performance


The acquisition and output performance requirements specified in Sections 4.5 and 4.6 shall be met
under the following RF (L-band) signal parameters assumed to exist in the vicinity of the antenna:

(a) a received frequency range of 1530.0 to 1545.0 MHz;

(b) an unfaded power flux density range of –146.5 to –144.5 dBW/m2 (corresponding to a worst
case C/No range at the demodulator of 34.0 to 36.0 dBHz);

(c) a C/No of 55.7 dBHz (excludes antenna and receiver noise);

(d) an initial frequency offset of ±850 Hz and a short term variation of from +50 Hz to –50 Hz in
3 seconds (excludes receiver downconverter errors);

(e) an initial clock frequency offset of ±0.06 Hz (±50 parts in 106);

(f) with phase noise superimposed on the received carrier with spectral characteristics as shown
in Figure 6;

(g) in the presence of Rician distributed multipath fading. Figure 8 illustrates the Rician fading
model. The parameters to be used are: C/M = 7 dB and fading spectral characteristics
corresponding to a second order Butterworth filter with f(3 dB) = 0.7 Hz;

Figure 8: Inmarsat-C Rician Fading Model

unfaded
signal
at fo

(1) (2) (3) faded


output
š/2 Gaussian signal
phase noise K
shift source
1

Notes: (2) (3)


(1)
(1) Uncorrelated noise Gaussian
(2) Second order butterworth noise K
low pass filter with 0.7 Hz, source
3 dB bandwidth. 2
(3) K adjusted to set C/M..

(h) in the presence of one adjacent channel interferer (BPSK modulated at 1200 symbols/s) at
±5 kHz from the carrier with a relative level of +5 dBc.

(i) in the presence of out-of-band signals as specified in Section 3.3.3.

Volume 3: User Services, Part 2: Services and Facilities, Page: 21


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

4.5 Continuous Reception Output Performance


The continuous reception output performance shall be measured in terms of the packet error
probability (PEP). This is defined as:

PEP = (Total packets transmitted - Total packets received correctly)


Total packets transmitted

The limits for the maximum acceptable PEP for a range of equivalent unfaded power flux densities
(PFD) at the antenna are as follows:

PFD PEP PEP PEP


(dBW/m2) (128 byte packet) (48 byte packet) (10 byte packet)

–146.5 0.080 0.027 0.0090


–146.0 0.040 0.014 0.0050
–145.5 0.020 0.007 0.0020
–145.0 0.012 0.004 0.0014
–144.5 0.004 0.002 0.0005

Note: The power flux densities are assumed to be pure RHCP (0 dB axial ratio) at the antenna and
correspond to the demodulator input C/No's of Volume 1, Chapter 3, Table 6 assuming a receiver
system G/T of –23 dB/K and 5° satellite elevation.

4.6 Acquisition Performance


There are a number of situations in which acquisition of a TDM, defined as the reception of a valid
bulletin board, may occur. These are:

(a) acquisition of an NCS common channel after initial switch on;

(b) acquisition of a LES TDM channel at the commencement of a call;

(c) re-acquisition of a LES TDM channel after burst or message transmission;

(d) re-acquisition of an NCS common channel at the completion of a call; and

(e) selection of another NCS common channel.

4.6.1 NCS/LES Tuning


For the following tuning operations:

(a) NCS common channel to LES TDM

(b) LES TDM to NCS common channel

(c) NCS common channel to NCS common channel

Acquisition shall be achieved within 25 seconds with a probability of failure of 0.01. For each
additional 10 seconds taken to acquire, the probability of failure shall be a factor of 10 less.

4.6.2 Re-acquisition after Burst Mode Transfers


The MES may be directed by a LES to transmit in any of the timeslots up to slot 14 for first generation
satellites, or up to slot 28 for future generation satellites. The 2-frame count field in the bulletin board

Volume 3: User Services, Part 2: Services and Facilities, Page: 22


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

indicates the boundary between 2 and 3-frame slots. Any available slot selected up to and including
this boundary will be a 2-frame slot. All slots after this are 3-frame slots.

The minimum time available for re-synchronization after the end of a burst and the start of a new
frame will not be less than 478 ms.

4.6.2.1 2-Frame Slot Mode.

Following a burst transmission in a time slot designated by the LES as being a 2-Frame slot, the
receiver shall correctly receive the next bulletin board with a probability of failure no greater than that
under continuous reception conditions;

4.6.2.2 3-Frame Slot Mode.

Following a burst transmission in a time slot designated by the LES as being a 3-Frame slot, the
receiver shall receive the next but one bulletin board with a probability of failure no greater than that
under continuous reception conditions.

4.6.3 Re-acquisition after Message transfers


Following a message transmission on the message channel, the receiver shall acquire frame
synchronization with the same performance as for the tuning operations as described in Section 4.6.1.

5 Transmitter Performance

5.1 From-Mobile Message and Signalling Channel Modulation Characteristics


The following modulation characteristics are common to both the signalling channel and message
channel carriers:

(a) modulation: unfiltered binary phase shift keying;

(b) error control coding: Encoder implementation is described in Volume 1,


Chapter 4, Section 3;

(c) coded symbol rate: 1200 symbols per second ±1 part in 105 (for future
generation satellites)

600 symbols per second ±1 part in 105 (for first


generation satellites); see Section 5.2.

(d) Symbol rate stability: short term stability;

±1 part in 106 over any 10 seconds;

(e) ambiguity resolution: unique word polarity.

5.2 Operation with First Generation Satellites


Due to the lower gain of the first generation satellite transponders in the L-to-C band link, the MES
transmit data rate for both signalling and message channels shall be reduced to 300 bits/s
(600 symbols/second) according to the generation of the satellite as indicated in the TDM (NCS or
LES) bulletin board. The frame length, coding and modulation characteristics remain unchanged in all
other respects.

Volume 3: User Services, Part 2: Services and Facilities, Page: 23


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

5.3 Signalling Channel Characteristics


The signalling channel operates in burst mode with up to 28 time slots or up to 14 time slots with first
generation satellites. The access method is described in Volume 1, Chapter 4, Section 4.

The characteristics of the transmitted signal shall be as follows:

(a) frame duration: 8640.0 ms nominally;

(b) burst duration: 632 –0.25/+1 TDM symbol periods (first


generation link)

316 –0.25/+1 TDM symbol periods (second


generation link);

(c) frame unique word: 64 bits as follows:

transmitted first
0000 0111 1110 1010
1100 1101 1101 1010
0100 1110 0010 1111
0010 1000 1100 0010
transmitted last

or expressed in hexadecimal:

07EA CDDA 4E2F 28C2

The unique word is transmitted uncoded.

(d) scrambling: scrambling is described in Volume 1, Chapter 4,


Section 3.

5.4 Message Channel


The message channel is transmitted in a quasi-continuous mode with a transmission duration which
depends on the length of the message to be transmitted. For details about the channel assignment
and frame formatting refer to Volume 1, Chapter 4, Section 3 and to Volume 4, Chapter 5.
The characteristics of the transmitted signal shall be:

(a) duration: variable, depending on the length of the message


as described in Volume 1, Chapter 4, Section 3.
Following the end of the scheduled transmission
(last symbol), the carrier level shall fall to less than
the required off power level within 1 symbol
period.

(b) preamble (carrier and symbol timing 192 symbols as described in Volume 1, Chapter 4,
recovery): Section 3

(c) frame unique word: the 128 bit unique word consists of the
following 64 bit sequence transmitted twice:

(j=0) 0000 0111 1110 1010


1100 1101 1101 1010
0100 1110 0010 1111
0010 1000 1100 0010 (j=63)

Volume 3: User Services, Part 2: Services and Facilities, Page: 24


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

expressed in hexadecimal:

07EA CDDA 4E2F 28C2

Prior to permuting the above sequence appears


as follows:

(i=0) 0111 1011 1010 1001


0110 1001 0001 0111
0011 0010 1110 1001
1011 1000 1000 1000 (i=63)

or expressed in hexadecimal:

7BA9 6917 32E9 B888

The unique word is transmitted uncoded.

(d) scrambling: scrambling is described in Volume 1, Chapter 4,


Section 3;

(e) interleaving: variable interleaver as described in Volume 1,


Chapter 4, Section 3;

(f) frame length: 2176, 4224, 6272, 8320 or 10,368 symbols as


described in Volume 1, Chapter 4, Section 3.

6 Access Control Requirements

6.1 General
Detailed descriptions of the access control and signalling protocols for an MES are given in Volume 1,
Chapter 4; packet format definitions and SDL diagrams are given in Volumes 4 and 5 respectively.

This section is concerned with additional requirements relating to access control which are not
explicitly described in these volumes.

6.2 TDMA performance

6.2.1 TDMA Synchronization


The MES transmission delay (Tk) is defined as the nominal delay from the MES antenna port to the
leading edge of the first symbol of the transmission starting in slot k, following reception of an entire
TDM frame, and is represented as:

Tk(M,G) = 300+208M+370G(k-1) ±1 TDM symbol periods

where M is the total number of signalling channels associated with that TDM, G=2 or 1 for first
generation or future generation satellites respectively and k is the required slot number. TDM symbol
periods are forward TDM symbol periods (1/1200 s) referred to the TDM the receiver is tuned to.
The duration of each burst shall be:

Tb = 316G -0.25/+1 TDM symbol periods

where G=2 or 1 for first generation or future generation satellites respectively. Symbol periods as
defined above.

Volume 3: User Services, Part 2: Services and Facilities, Page: 25


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

6.2.2 Random Access and Retransmission Slot Selection


The MES shall be equipped with a random number generator. This will be used for:

(a) the selection of available TDMA random access channel frequencies and selection of slots on
the MES signalling channel;

(b) the selection of a retransmission delay in the event of a collision or, for the submission of a
polling response where this capability is to be provided.

Selection of a particular random access slot in a MES signalling channel, associated with a particular
TDM (LES or NCS), shall be made from the list of available random access slots listed in the TDMs
signalling channel descriptor packets. The 2-frame count field in the bulletin board will indicate how
many of the earliest slots are 2-frame slots (the remainder will be 3-frame slots) and will apply to all
signalling channels associated with that TDM. This information shall be utilized by the MES to
determine the number of frames to wait for the selected slot before a response from the LES,
indicating whether or not the transmitted packet was successfully received, is available. The slot state
marker will indicate whether a burst in the previous multislot had been detected and successfully
decoded or not, and whether the current slot is reserved or unreserved (refer to Volume 1, Chapter 4,
Section 4.3).

The number of available slots on each signalling channel will be in the range 1 to 28 for future
generation satellites, or 1 to 14 for first generation satellites. The maximum number of available slots
depends on the number of signalling channels (M) associated with that TDM. This number is available
in the bulletin board.

Slot selection shall be made at random from among all the available slots on all the signalling
channels associated with a particular TDM frame, available for the type of protocol or service the MES
is engaged in, regardless of the signalling channel frequency or slot number. Only those signalling
channel descriptor packets that have been received error free and are flagged as being available for
the type of protocol or service required, may be used for the selection (see Section 6.2.3). In the case
of an alert or high priority signalling on a dedicated alert channel, the MES shall select a slot at
random from the available slots on the dedicated alert channel(s).

The same random number generator shall be used to select the frame (as well as the slot within the
frame) for the retransmission of a collided packet, or for the response to a group or area directed
polling command where this capability is to be provided. The maximum retransmission interval is the
randomizing interval (X frames where 1 ≤ X ≤ 255) defined by the LES in the bulletin board.

Mobile earth stations shall select a frame at random within this interval (between 1 and X) and then
select one of the available time slots within the selected frame, as described above.

Only in the case of an alert or high priority signalling, for which a collision has been detected, shall the
MES re-use the same multislot (see Volume 1, Chapter 4, Section 4.3.1)).

The random number generator technique used in the selection process shall have a random and
demonstrably uniform distribution of number generation. Additionally, the selection of a slot or frame
shall be shown to be at random, independent of the number of slots or frames the selection is to be
made from.

If a pseudo random number generator implementation is used, the sequence length shall not be less
than 224–1.

6.2.3 Signalling Channel Access Restrictions


If more than two bulletin boards out of the last three have been received in error, the MES shall be
inhibited from transmitting in any slot indicated in a correctly received signalling channel descriptor
packet in the current frame.

Volume 3: User Services, Part 2: Services and Facilities, Page: 26


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

MESs shall be inhibited from using the following signalling channels for general signalling (refer to
Volume 4, Chapter 2, Section 3.2):

i) Alert only channels (see Section 8.1);

ii) Channels flagged as being unavailable;

iii) Closed user group channels (unless access has previously been authorized).

6.2.4 Message Channel Access Restrictions


If the bulletin board for the assigned frame is not received or is in error, the MES may estimate the
transmission start time from the last received frame in which a valid bulletin board was received.

The transmission start time shall be within ± 1 TDM symbol period of the scheduled start time as
defined in Section 6.2.1 for that slot.

MESs shall be inhibited from transmitting on a message channel if a forced clear is detected on the
TDM following reception of a valid logical channel assignment.

6.2.5 Operation with Multiple LES TDMs


On reception of an LES TDM descriptor packet on an LES TDM, the MES shall compare the
information already stored (from previous reception of an LES descriptor packet, network update or
login acknowledgement) with information on the available TDMs for that LES. If the LES TDM
descriptor presents different data for that LES, then the MES shall save this information, overwriting
any previously stored TDM information for that LES.

The MES shall randomly select one of the available TDMs associated with that LES to use for non-
priority mobile originated traffic (with the exception of pre-assigned data reporting) at the start of each
transaction.

6.3 NCS Common Channel Selection

6.3.1 General
The MES shall be equipped with facilities for storing up to 80 NCS IDs and channel numbers (20 in
each of four ocean regions). Four of these will be permanently assigned global beam frequencies as
follows;

NCS ID No. Channel No.

AOR(West) 044 11080

AOR(East) 144 12580

POR 244 12580

IOR 344 10840

These four IDs and channel numbers shall not be alterable by the operator. A spare channel number
[11088] will be used in the event of interference on any NCS common channel TDM.

The remaining list of (up to) 76 valid NCS common channel frequencies will be published by
INMARSAT and will be assigned as expansion common channels or spot beam allocations. These
shall be held in non-volatile, but alterable, storage and be capable of operator alteration in the event
that INMARSAT decides to update the frequency plan by adding, deleting or changing allocations.

Volume 3: User Services, Part 2: Services and Facilities, Page: 27


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

It shall not be necessary for the operator to enter frequency information when setting up a call.

6.3.2 Expansion of NCS Common Channel


Expansion of the NCS common channel capacity will be implemented when INMARSAT considers
this is required. The method to be adopted will be the transmission by the NCS of a second carrier
having a separate ocean region ID. This second channel may not carry EGC messages.

6.3.3 Stand Alone Operation


Stand Alone Operation (of an LES) refers to the situation where there is no NCS in the region to
provide the network coordination. Two cases may occur:

1) there is only one LES operating in a region; and

2) a restoration mode is invoked.

The term 'Stand Alone' is used because an LES will be stand alone i.e. operating independently
without an NCS.

a) One LES in an ocean region

The LES transmits a TDM channel on the allocated NCS Common Channel frequency for the region it
is operating in. The bulletin board will indicate that this TDM is an NCS Common Channel and the
origin ID on the channel will be the NCS ID. Therefore the LES ID will change to the NCS ID.(see
Volume 4, Chapter 2, Section 3.1.4.1).

The LES may use this TDM for its to mobile traffic, and will process assignment requests received on
the associated signalling channel. In the case where the LES has a second TDM it will have channel
type = LES TDM and origin ID = LES ID.

The LES Descriptor of the Stand-Alone LES/NCS is determined from either the Login
Acknowledgement or a later Network Update packet.

b) Restoration Mode Network Operation

Should the NCS fail, a nominated LES will transmit the NCS Common Channel. In restoration mode,
the Common Channel will only be handling call announcements for the nominated LES transmitting
the NCS Common Channel. This carrier will, however, still carry EGC SafetyNETSM traffic for the
region. FleetNETSM traffic will also be carried for the Nominated LES and for LESs with re-routing of
EGC traffic, see Section 2.6.

6.3.4 Spot Beam Operation


In order to ensure that the MES may take advantage of a future spot beam environment within the
INMARSAT system, the MES shall be required to scan the current NCS frequencies for an ocean
region in order to identify the strongest NCS common channel carrier (see Volume 1, Chapter 4,
Section 9.4).

Signal strength measurements shall be averaged over a period of not less than one frame duration
(8.64 seconds).

Where automatically initiated scanning is permitted, the MES shall start by scanning the NCS
Common Channels in the current ocean region and then proceed to scan the global beam Common
Channel frequencies. For each ocean region in which a global beam Common Channel is found, the
MES shall scan the spot beam Common Channels for that ocean region. If a global beam Common

Volume 3: User Services, Part 2: Services and Facilities, Page: 28


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Channel is not detected for a particular ocean region then the spot beam frequencies for that ocean
region need not be scanned.

If a preferred ocean region is set (see Section 7.5.2) then scanning may be restricted to the NCSs
within that ocean region. If none are detected however, a prompt shall be sent to the operator via the
DTE and scanning of the other ocean regions may commence.

Where automatically initiated scanning is permitted, the NCS common channel scanning procedure
shall be performed at 24 hourly intervals from the last log in (or switch on).

Scanning shall only take place when the MES is idle, and may be manually initiated if required.
6.4 Mobile Station Identities
Each MES shall have a unique pair of forward and return link 24 bit MES identities (IDs).
Manufacturers obtaining INMARSAT type approval will be allocated batches of paired 24 bit identities,
each in the range 00000016 to FFFFFF16 by INMARSAT (on a confidential basis). Manufacturers
shall assign an ID pair from the batch of IDs to each MES produced and inform INMARSAT of the
serial numbers of the terminals to which each pair of IDs has been assigned. For further information
refer to "Commissioning Procedures for Inmarsat-C Mobile Earth Stations" which can be obtained
from Inmarsat.

Manufacturer will be required to assure Inmarsat that they have taken adequate security precautions
to ensure that MES forward and return IDs remain strictly confidential and shall not be revealed to
agents or customers. The MES unique ID pair shall be permanently built into the MES during
manufacture (for instance, in ROM) and shall be protected against subsequent alteration. It shall not
be possible, under any circumstances, for the MES operator to create, modify or erase forward or
return IDs. Authorised maintenance personnel may be granted access to forward and return IDs. This
method of access must be secure and shall be made known to Inmarsat for review prior to the
granting of type approval. If the return and forward ID pair or any of the IDs is replaced, the MES will
be considered to have been replaced by a new MES, with a new unique ID pair.

Full details of the Numbering Plan for MESs, LESs and NCSs are presented in Part 1, Chapter 3 in
this volume.

6.5 Ocean Region Registration Procedures

6.5.1 Logging In
Each time the MES is powered on, the receiver shall attempt to establish synchronisation with the
current NCS (see Section 7.5.2 (b)). The current NCS ID may be any of the NCS IDs stored in the
MES memory (either one of the four permanent global beam NCSs or a spot beam NCS ID). If
synchronization cannot be established within a period not exceeding 30 minutes, the MES shall
perform a scan of NCS common channels as described in Section 6.3.4.

If the NCS common channel eventually acquired is different from the NCS common channel
corresponding to the ocean region the MES was last logged into, the MES shall log in with the
procedure as described in Volume 1, Chapter 4, Section 9. After successful logging in, the information
stored in the non-volatile memory relating to the current ocean region (see Section 7.5.2) shall be
updated.

The Network Configuration received by the MES during logging in, or subsequently in a Network
Update packet, if the version changes, shall be stored and used for initiating calls in the current ocean
region. Calls shall only be initiated to LESs indicated in the Network Configuration, regardless of the
TDM type field indicated in the Bulletin Board.

If the network configuration version number in the NCS common channel bulletin board is found to be
different from the version number stored in the MES, the MES shall log in either;

Volume 3: User Services, Part 2: Services and Facilities, Page: 29


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

(i) if a network update packet is not received within 24 hours; or

(ii) if the MES is unable to synchronize to a LES TDM.

When attempting to log in to a new ocean region the network version number of the log-in packet shall
be set to zero.

6.5.2 Logging Out


Facilities shall be provided to manually send a request for logging out of the current operational ocean
region with the procedure described in Volume 1, Chapter 4, Section 9.

6.6 Idle and Busy Conditions

6.6.1 Priorities
In the case of more than one valid packet being received in the same frame and generating a conflict
for the action required due to the limited resources of the MES, the response shall be dictated by the
packet priorities (see Volume 1, Chapter 4, Sections 4.1 and 4.2). Also refer to Section 2.1.1.

6.6.2 Off-Line Operation


Off-line functions and uses of the MES input and output devices (DTE) shall not prevent incoming
calls from being received and stored.

6.6.3 Forced Clearing


At any time it shall be possible to manually terminate a call in progress by sending an MES forced
clear packet on the signalling channel as described in Volume 1, Chapter 4, Section 7.2.2.

7 Message Processing Requirements

7.1 General
This section presents requirements and recommendations for the message processing subsystem of
the MES. Where necessary, indication will be given as to whether the requirement is applicable to the
DCE or the DTE as defined in Section 2.2.

7.2 Character Codes


The character codes transmitted over the satellite link shall be as defined in Volume 1, Chapter 4,
Section 3.2.6.

For the mandatory store and forward Telex service and the EGC service, the International Reference
Version of International Alphabet 5 (IA5) as defined in CCITT Red Book Rec. T.50, shall be used.
Characters shall be coded as 8 bits using odd parity. The DTE shall perform a parity check on all
incoming characters and in the event of a parity error in a received character, the "low line" character
(5/15 in T.50) shall be printed or displayed.

MES equipment may optionally provide International Telegraph Alphabet No. 2 (ITA2) message
processing capabilities. In this event it is recommended that national options are not used for
character Nos. 6, 7 and 8 in figure case to avoid varying interpretations in the international Inmarsat C
system (see CCITT Rec. S.1, §4.2).

Backspace may be used when sending accents with IA5 (see CCITT Recommendation T.50, red
book). This is because every (graphic) character in IA5 is a spacing character. The IA5 (IRV) accents

Volume 3: User Services, Part 2: Services and Facilities, Page: 30


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

are: Grave, Circumflex and Tilde/Overline. However, T.50 does not completely define a repertoire for
IA5 (IRV); that is, it does not specify which characters may be combined with which accents. For
Inmarsat-C, (when using IA5) the repertoire defined in CCITT Recommendation T.61 (red book) for
accents Grave, Circumflex and Tilde/Overline should be supported as a minimum. T.50 additionally
states that Quotation mark, Apostrophe and Comma may be used to represent Diaresis/Umlaut,
Acute and Cedilla respectively, and these are not ruled out. However, correct interpretation of these
last three combinations cannot be guaranteed. Note that if IA5 to ITA2 conversion is performed, any
accents are likely to be lost.

7.3 Display Devices

7.3.1 Message Display (DTE)


The MES shall have a display device for the purpose of displaying received text. The display device is
defined as part of the DTE.

7.3.2 Status Display


MES status shall be displayed via a combination of MES DCE mounted indicators and/or character
displays on the output device (DTE) as considered appropriate by the manufacturer. As a minimum,
an indication of:

(a) frame synchronization (or loss of synchronization)

(b) MES transmitting

shall be provided.

7.4 Keyboard (DTE)


The MES shall have a keyboard (part of the DTE) for the purposes of:

(a) entering and editing of message text;

(b) entering various signalling information as described in Section 7.6.3; and

(c) control of MES functions.

Additional dedicated function keys or controls for controlling the MES and message handling functions
are recommended.

7.5 Mobile Earth Station Memory Capacity Requirements

7.5.1 Message Storage (DCE)


Message storage shall be in the MES (DCE). As a minimum, the MES shall have sufficient random
access memory to store messages up to a total of 32,768 bytes, with incoming messages having
priority over MES originated messages.

For the purpose of editing messages prior to transmission and for off line use of the DTE, it is
recommended that additional memory should be provided within the DTE so as to avoid potential
memory conflicts.

If a received message cannot be stored, due to the memory allocation in the DCE being full of
previously received messages, an indication shall be given to the operator via the corresponding
control code (see Chapter 4) and the message dumped to the display device or printer (printer in the
case of a SOLAS MES).

Volume 3: User Services, Part 2: Services and Facilities, Page: 31


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

7.5.2 Non-Volatile Memory (DCE)


The following information shall be held in non-volatile memory and used for the purposes described:

(a) NCS IDs and channel numbers (provision for up to 76 excluding the four global beam IDs and
channel numbers).

With the four permanently assigned global beam NCS IDs and channel numbers, this will form
the list of (up to 80) NCS Common Channels to be scanned as described in Section 6.3.4.

(b) Current NCS ID and channel number.

This is the NCS to which the MES last logged in. Following a power failure or other interruption
the MES shall tune to this NCS Common Channel.

(c) Test log.

This is a log of the last performance verification (or commissioning) test. This shall include the
date and time the test was performed and the results.

(d) Preferred ocean region.

MESs that may operate in satellite coverage area overlap regions may wish to restrict the 24
hourly NCS Common Channel scan to a preferred (current) ocean region in order to avoid the
possibility that the MES may be forced to log-in to another ocean region against the wish of the
operator (see Section 6.3.4).

The non-volatile memory should be capable of retaining the stored data for a minimum of six months
under the applicable environmental conditions and in the absence of applied primary power.

7.6 The DTE-DCE Interface


This section presents the recommended specifications for the interface between the DCE and the
DTE. It is not mandatory.

7.6.1 Technical Requirements


The following combination of characteristics which are equivalent to EIA RS-449 are recommended.
Optionally, the alternative characteristics specified in Section 3 of Chapter 3 may be implemented.

(a) Data Interchange Circuits:

The interchange circuits between the DTE and the DCE should conform to CCITT Red Book
Recommendation V.24.

(b) Electrical Characteristics:

The electrical characteristics of the interchange circuits should comply with CCITT Red Book
Recommendation V.11/X.27.

Note: Electrically equivalent to EIA RS-422A.

(c) Mechanical Characteristics:

The input/output ports between the DTE and the DCE should use an ISO 4902, 37 pin
connector with the following connections provided as a minimum:

ISO 4902 Pin No. CCITT V.24 Designation

Volume 3: User Services, Part 2: Services and Facilities, Page: 32


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

19 102 Signal Ground/Common Ret.


4,22 103 Transmitted Data
6,24 104 Received Data
11,29 107 Data Set Ready
12,30 108/2 Data Terminal Ready

7.6.2 Message Transfer


For simple message transfer, the DCE shall accept complete messages from the DTE.

7.6.3 Control Codes


A recommended series of control codes used to transfer commands to the DCE and data between the
DTE and DCE are given in Chapter 4.

8 Alerting Functions
The requirements relating to the alerting functions are presented in the following chapters of this
volume for the various MES types.

9 Testing Functions
All MES models shall be equipped with a number of testing functions to ensure correct operation of
the MES and to maintain the integrity of the INMARSAT system.

The purposes of these testing functions are:

(a) to prevent erroneous transmissions;

(b) to alert the operator in the event of a malfunction; and

(c) to alert the operator to the possibility that reliable communications may not be achievable due
to a degraded link.

9.1 Fail-Safe Features


Means shall be provided to alert the MES operator to fault conditions. The following features shall be
included to inhibit RF output in the event of a fault condition:

(a) the MES shall be designed so that no transmission shall occur if an equipment module fails or
is
removed;

(b) a failure condition shall be indicated when the transmitter is on and:

(i) the MES is not transmitting a burst message; or

(ii) the MES has not been authorized for message transmission;

(c) if an RF switch is used, it shall be of the non-latching variety, configured such that when the
power supply to the switch is interrupted, the MES is unable to transmit;

(d) a hardware watchdog timer shall be provided to protect against operational software faults. This
shall be configured such that abnormal software operation such as a software crash or halt will
cause a software reset and self-testing.

Volume 3: User Services, Part 2: Services and Facilities, Page: 33


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

In addition to the above, it shall be possible to disable the transmitter for testing and/or safety
reasons.

9.2 Self Monitoring Functions


The MES shall continuously monitor the received bulletin board error rate (BBER) whenever it is
tuned and synchronized (defined as detection of a unique word) to a TDM (NCS or LES). The MES
shall store a count of the number of bulletin boards received in error out of the last 100 received. This
count shall be continuously updated frame by frame.

9.3 Performance Verification and Commissioning Testing

9.3.1 General
Automatic testing of MESs through an operational satellite, for the purpose of MES performance
verification, link quality checking and MES commissioning testing, is a feature of the Inmarsat-C
system.

Detailed descriptions of the performance verification and commissioning tests are found in Volume 1,
Chapter 4, Section 10.

The results of a performance verification or commissioning test transmitted to an MES shall be made
available to the MES operator.

9.3.2 Performance Verification Testing


For the From-Mobile message transfer test stage in the performance verification test, the MES is
required to retransmit the test message sent by the LES during the To-Mobile message transfer
stage.

The first message packet contains an Additional Information field (see Volume 4, Chapter 5, Section
3.1.2.7) of one byte containing the current BBER.

9.3.3 Commissioning Testing


The commissioning tests for MESs are based on the performance verification test. Test details are
presented in Volume 1, Chapter 4, Section 10.

For details of the commissioning procedures for MESs, refer to "Commissioning Procedures for
Inmarsat-C Mobile Earth Stations" which is available from Inmarsat.

10 Electromagnetic Compatibility

10.1 General
This section presents the common electromagnetic compatibility (EMC) requirements for land mobile
earth stations and land portable earth stations. The EMC requirements for maritime MESs (including
maritime EGC receivers) and AMESs are referenced separately, in Volume 3, Part 2, Chapter 5 and
Annexes A, B and C, Section 10 and Volume 3, Part 2, Chapter 9, Section 10, respectively.

10.2 Limits for Mains Conducted Spurious Emissions


This section presents a requirement for the limits to the electromagnetic emissions emanating from
any mains operated (a.c or d.c) MES along the mains power cable. The level of emission measured
as a voltage generated by the equipment under test between earth and each terminal of a defined
artificial mains network shall not exceed the limits shown in Figure 9 when measured using the

Volume 3: User Services, Part 2: Services and Facilities, Page: 34


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

measurement methods and apparatus described in CISRP publication 16, "CISRP Specification for
Radio Interference Measuring Apparatus and Measurement Methods".

Volume 3: User Services, Part 2: Services and Facilities, Page: 35


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 9: Maximum Level of Conducted Spurious Voltage into Mains (dBuV referred
to 50 OHMS)

11 Environmental Conditions
The environmental conditions stated here do not apply to maritime MESs (including maritime EGC
receivers) or AMESs. The environmental conditions under which these types of MESs are required to
operate are presented in Volume 3, Part 2, Chapter 5 and Annexes A, B and C, Section 11 and
Volume 3, Part 2, Chapter 9, Section 11, respectively.

Volume 3: User Services, Part 2: Services and Facilities, Page: 36


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

11.1 Purpose
The purpose of this section is to define the minimum environmental conditions for MESs which are to
be type approved as suitable for operation within the INMARSAT system.

MES models intended for use under alternative or restricted ranges of environmental conditions will
also be considered for type approval. In any case, the range of environmental conditions over which
the MES is designed to fulfil the INMARSAT requirements shall be specified by the manufacturer and
made known to prospective users of the MES model.

11.2 Recommended Minimum Environmental Conditions for INMARSAT-C MESS

The following specification is recommended for all MESs.

EME - Externally Mounted Equipment

IME - Internally Mounted Equipment

(a) Ambient Temperature: –35°C to +55°C (EME)


0°C to +35°C (IME)

(b) Relative Humidity: up to 95% at +40°C;

(c) Ice: up to 25mm of ice (EME);

(d) Precipitation: up to 100mm/hour (EME);

(e) Wind: normal operation with relative average wind


speeds up to 100 knots (EME);

(f) Solar Radiation: Maximum flux density 1200 W/m2 (EME)

Spectral composition:
Infra Red 51%
Visible 44.5%
Ultra Violet 4.5%

(g) Prime Power Variations:

AC Mains Supply: frequency ±6%


voltage ±10%

DC Mains Supply: voltage +10%, –20%

(h) Vibration:

Frequency Range (Hz) Level

2 – 10 2.54mm peak amplitude

10 – 100 1.0 g peak acceleration

See Figure 10, curve (a).


Note: 1g = 9.807 m/s2

Acceptable alternative levels for Internally Mounted Equipment only:

Frequency Range (Hz) Level

Volume 3: User Services, Part 2: Services and Facilities, Page: 37


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

2 – 15.8 1.00mm peak amplitude

15.8 – 100 1.0 g peak acceleration

See Figure 10, curve (b)

During type approval, certain tests that are required to be conducted under vibration conditions
may be performed using pink noise vibration spectra instead of the sinusoidal swept frequency
range specified above. Refer to "Type Approval Procedures for Inmarsat-C Mobile Earth
Stations", which is available from Inmarsat;

Note: Consideration will be given to the relaxation of these conditions if necessary, in respect
of a printer if this is an integral part of the equipment (IME only). An example of acceptable
minimum conditions with respect to printer operation is given below:

Frequency Range (Hz) Level

2 – 13.6 0.4mm peak amplitude

13.6 – 50 0.3 g peak acceleration

See Figure 5-1, curve (c).

Volume 3: User Services, Part 2: Services and Facilities, Page: 38


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 10: Vibration Test Curves

Volume 3: User Services, Part 2: Services and Facilities, Page: 39


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Annex 1: Year 2000 Compliance

Inmarsat-C MESs (DCEs and DTEs) shall be compliant with the year 2000 date change so that they
can:

• handle date information before, during and after 1 January 2000, including but not limited to
accepting date input and performing calculations on dates or portions of dates

• function accurately and without interruption before, during and after 1 January 2000 without
changes in operation associated with the advent of the new century

• respond to two-digit year date input in a way that resolves the ambiguity as to the century in a
disclosed, defined and pre-determined manner

• store and provide output of date information in ways that are unambiguous as to century

• manage the leap year occurring in the year 2000 following the quad-centennial rule.

In addition, GPS receivers, which may be part of Inmarsat-C MES installations should be able to
manage the rollover occurring in that system at midnight on 21 August 1999.

Volume 3: User Services, Part 2: Services and Facilities, Page: 40


Chapter 2: Technical Requirements for a Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Chapter 3: Optional Capabilities for an Inmarsat C


Mobile Earth Station

Contents

1 Optional Functional Capabilities ............................................. 2

2 Optional Design Features ........................................................ 2


2.1 Alternative Antenna Configurations ...................................................................2
2.1.1 Steerability and Tracking................................................................................2
2.1.2 Additional Environmental Conditions.............................................................2
2.1.3 Alternative Unstabilized Antennas ................................................................2
2.2 Navigational Interface .......................................................................................3
2.3 Unattended Operation .......................................................................................3
2.4 Multiple Mobile Earth Station Output Devices ..................................................3
2.5 NCS Common Channel Scanning .....................................................................3
2.6 FLEETNETSM Reception During Restoration Mode Network Operation .............3

3 Optional Alternative Interface .................................................. 3

4 Required Capabilities for Supporting Optional Services........... 4


4.1 Required Functions ...........................................................................................4
4.2 Data Reporting and Polling Closed Network Management ...............................4
4.2.1 Non-Volatile Memory......................................................................................4
4.2.2 Operator Access ............................................................................................5
4.2.3 Polls from Alternate Ocean Regions ..............................................................5
4.3 Store and Forward Message to a Closed Network ID (DNID) ...........................5
4.4 MES Retuning Timing for Pre-Assigned Data Reporting...................................5

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 1
Chapter 3: Optional Capabilities for an Inmarsat C Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

1 Optional Functional Capabilities


In addition to MESs having the mandatory capabilities outlined in Chapter 2, Section 2.4, application
for the type or case approval of MESs with reduced or alternative functional capabilities will be
considered by INMARSAT.

2 Optional Design Features

2.1 Alternative Antenna Configurations


The baseline Mobile Earth Station Technical Requirements are based on the use of an
omnidirectional antenna. The use of mechanically stabilized or electronically steered directional
antennas is also acceptable, provided that the additional technical requirements presented below are
satisfied.

2.1.1 Steerability and Tracking


If an antenna is used with a directivity such that electronic or mechanical beam steering are
necessary to maintain the required G/T and EIRP in the direction of the satellite, the antenna beam
shall be capable of being steered in the direction of any geostationary satellite whose orbit inclination
does not exceed 5° and whose longitudinal excursions do not exceed ±0.5°. Means shall be provided
to automatically point the antenna beam towards the satellite with sufficient accuracy to ensure that
the G/T and EIRP requirements are satisfied continuously under operational conditions.

2.1.2 Additional Environmental Conditions


The following environmental conditions are additional to those of Chapter 5, Section 11 for stabilized
antennas for maritime installations:

Motion Amplitude Period

Roll ±30° 6s
Pitch ±30° 6s
Yaw ±10° 10s
Surge ±0.2g
Sway ±0.2g
Heave ±0.2g
Turning Rate 10°/s
Headway 60 knots

Maximum tangential acceleration of up to 1.2g.

2.1.3 Alternative Unstabilized Antennas


It may be permissible for MESs to use antennas with radiation pattern characteristics optimised for a
particular location (or range of locations).

Applications for the type or case approval of MESs equipped with special antennas should be
accompanied by detailed antenna characteristics and supporting information, including the proposed
operating environment and location(s), to justify the use of a special antenna configuration.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 2
Chapter 3: Optional Capabilities for an Inmarsat C Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

2.2 Navigational Interface


For the purpose of providing position updating information for a distress message generator, or for
automatic EGC geographical addressing/area polling recognition, it is recommended that MESs be
equipped with an interface to navigational instruments.

A suggested standard interface is defined in IEC 1162, Part2 (NMEA 0183) Standard for Interfacing
Electronic Marine Navigational devices.

2.3 Unattended Operation


For unattended operation, the MES distress alerting function shall be disabled.

2.4 Multiple Mobile Earth Station Output Devices


The signalling system allows for different output devices to be directly addressed. The DTE port sub-
address (default) is 0016. The sub-address range is 0016 to FF16 (0 to 25510).

2.5 NCS Common Channel Scanning


A gradual increase in BBER may be due to the MES leaving a spot beam or ocean region coverage
area. Manufacturers may wish to consider providing a character string indication from the DCE to the
DTE in the event that the BBER exceeds a threshold prompting the operator to initiate a scan or
alternatively, if the MES is idle, automatically initiate a scan (Automatically initiated scanning is
prohibited in all maritime MESs, Volume 3, Part 2, Chapter 5, Annex A, Sections 2.4 and 6 refer.
Automatically initiated scanning is also prohibited in maritime EGC receivers, Volume 3, Part 2,
Chapter 8, Annex A, Section 6.3.2 refers).

2.6 FLEETNETSM Reception During Restoration Mode Network Operation


If an NCS failure occurs, the LES nominated to act as standby NCS will transmit EGC SafetyNETSM
traffic for the region. EGC FleetNETSM traffic will be handled by individual LESs.

Class 2 MESs, in the EGC mode, shall remain tuned to the NCS common (Standby NCS TDM). In the
Inmarsat-C mode of operation, Class 2 MESs will be tuned to a selected LES TDM when idle. In this
situation, it is permissible for the MESs to receive EGC FleetNETSM traffic when idle.

3 Optional Alternative Interface


As an alternative to the DTE-DCE interface requirements recommended in Chapter 2, Section 7.6.1,
the following technical requirements (equivalent to EIA RS-232C) may be implemented:

(a) Data Interchange Circuits:

The interchange circuits between the DTE and the DCE should conform to CCITT Red Book
Recommendation V.24.

(b) Electrical Characteristics:

The electrical characteristics of the interchange circuits should comply with CCITT Red Book
Recommendation V.28;

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 3
Chapter 3: Optional Capabilities for an Inmarsat C Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

(c) Mechanical Characteristics:

The input/output ports between the DTE and the DCE should use an ISO 2110, 25 pin
connector with the following connections provided as a minimum:

ISO 2110 Pin No. CCITT V.24 Designation

7 102 Signal Ground/Common Ret.

2 103 Transmitted Data

3 104 Received Data

6 107 Data Set Ready

20 108/2 Data Terminal Ready

4 Required Capabilities for Supporting Optional Services


For MESs supporting the polling and data reporting services (Volume 1, Chapters 5, 6, and 7 refers)
the following requirements are applicable.

4.1 Required Functions


Each protocol (polling, data reporting and pre-assigned data reporting) is optional, however MESs
supporting these protocols shall operate in accordance with the descriptions given in Volume 1,
Chapters 5, 6, and 7 and fulfil the requirements stated below.

4.2 Data Reporting and Polling Closed Network Management

4.2.1 Non-Volatile Memory


For security of operation and DNID management, the MES DCE shall use non-volatile memory for
storing data reporting and polling closed network IDs (DNIDs) and parameters associated with each
closed network. Provision for storing at least 64 16-bit DNIDs (and associated parameters) is
recommended. The parameters to be stored following a DNID download are as follows:

- DNID

- LES ID

- Member Number

- First 25 characters of the [Free] field in the initial DNID download command.

For MESs supporting pre-assigned data reporting, the following additional parameters shall be stored
in non-volatile memory along with each DNID:

- Start Frame Number

- Slot Number

- Logical Channel Number

- Number of Packets per Report

- Reporting interval

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 4
Chapter 3: Optional Capabilities for an Inmarsat C Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

- Assignment Duration

- MES signalling channel Number

4.2.2 Operator Access


The DNIDs stored shall only be accessible for downloading and deleting via the RF path.

It shall not be possible for a MES to send a message or a data report to a DNID of which it is not a
member (see Section 4.3).

The following requirements need not apply to MESs intended for unattended (remote) operation:

Following the initial download the DNID and "free" field shall be printed and/or displayed.

It shall be possible for the MES operator to inhibit (or activate as required), via the DTE, selected
DNIDs previously downloaded. In the event that a download command is received and the DNID
storage area is full, then DNIDs which have been inhibited (de-activated) by the MES operator shall
be overwritten. If none have been inhibited then the new download shall not be accepted.

4.2.3 Polls from Alternate Ocean Regions


MESs may receive polls from LESs having a different ocean region identifier from the ocean region
that the MES is currently logged in. This is to facilitate seamless data reporting DNID operation across
multiple ocean regions, where this can be supported by LESs.

If an acknowledgement data report is requested this should indicate the LES ID and Ocean Region
identifier of the originating LES as indicated in the poll.

Note; if an LES sends a poll to an alternative ocean region and requests acknowledgement, only
Global DNID capable mobiles will respond.

4.3 Store and Forward Message to a Closed Network ID (DNID)


As described in Volume 4, Chapter 4, an MES may send a Store and Forward message to an
address, which is a Closed Network ID (DNID). However it is a requirement that, the MES be a
member of the Closed Network to which the DNID belongs at the selected LES.

4.4 MES Retuning Timing for Pre-Assigned Data Reporting


In order to minimise the time that the MES is tuned away from the NCS Common Channel TDM, the
following requirement shall be met for MESs intending to provide pre-assigned data reporting:

For transmission in frame N, retuning from NCS to LES TDM shall commence in frame N-X1 on the
NCS, where

⎧⎛ T ⎞ ⎫
X1 = INT ⎨⎜ t ⎟ + 3⎬
⎩ ⎝ 8. 64 ⎠ ⎭

Where Tt is the retuning time for an acquisition probability > 99%.

From Chapter 2, Section 4.6.1, the required maximum 99% acquisition probability time (Tt) is 25s.
Therefore X1 ≤ 5. The actual value of Tt,, and hence X1, shall be determined for the MES model in
order to provide an optimum retuning time.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 5
Chapter 3: Optional Capabilities for an Inmarsat C Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 4: DTE-DCE Interface Control Codes

Contents

1 Introduction ............................................................................ 4

2 Commands, Queries, Responses and Indications ..................... 4


2.1 Operating Parameters .......................................................................................4
2.1.1 NCS TDM Channels.......................................................................................5
2.1.2 Preferred NCS ...............................................................................................5
2.2 EGC Parameters ...............................................................................................5
2.2.1 Geographical Coordinates .............................................................................5
2.2.2 Manual / NAV Equipment ...............................................................................6
2.2.3 NAVAREA Code ............................................................................................6
2.2.4 Navtex Code ..................................................................................................6
2.2.5 WMO Code ....................................................................................................7
2.3 Message Parameters ........................................................................................7
2.3.1 Address ..........................................................................................................7
2.3.2 Destination LES .............................................................................................8
2.3.3 Destination Type ............................................................................................8
2.3.4 Delivery Class ................................................................................................8
2.3.5 Delivery Confirmation .....................................................................................9
2.3.6 Distress Message Parameters .......................................................................9
2.3.7 Message Priority .......................................................................................... 10
2.3.8 Presentation ................................................................................................. 10
2.3.9 Service Type ................................................................................................ 10
2.3.10 Set Special Access Code ........................................................................... 11
2.3.11 Destination Extension ................................................................................ 11
2.4 Inmarsat-C Operation ..................................................................................... 11
2.4.2 Clear Waiting Message ................................................................................ 11
2.4.3 Commission Request ................................................................................... 11

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 1
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.4.4 Confirm Operation ........................................................................................ 12


2.4.5 Distress Alert................................................................................................ 12
2.4.6 Distress Alert (Test) ..................................................................................... 12
2.4.7 Forced Clear ................................................................................................ 12
2.4.8 Log in ........................................................................................................... 12
2.4.9 Log out ......................................................................................................... 12
2.4.10 Message Delivery Status Request ............................................................. 13
2.4.11 PV Test ...................................................................................................... 13
2.4.12 Scan NCS TDMs ........................................................................................ 13
2.4.13 Transfer Message to DCE.......................................................................... 13
2.4.14 Transmit Message ..................................................................................... 13
2.4.15 Tune to NCS Channel ................................................................................ 14
2.5 MES Status Queries ....................................................................................... 14
2.5.1 Current Channel? ......................................................................................... 14
2.5.2 Current TDM? .............................................................................................. 14
2.5.3 Link Performance? ....................................................................................... 15
2.5.4 Message Transfer Status? ........................................................................... 15
2.5.5 Messages Waiting? ...................................................................................... 15
2.5.6 Network? ...................................................................................................... 16
2.5.7 Next Message Descriptor? ........................................................................... 16
2.5.8 Parameter Setting? ...................................................................................... 17
2.5.9 PVT Result? ................................................................................................. 17
2.5.10 Request Next Message? ............................................................................ 18
2.5.11 MES Query? .............................................................................................. 18
2.5.12 MES Status? .............................................................................................. 18
2.5.13 Current TDM? ............................................................................................ 19
2.7 DCE Indication ................................................................................................ 20
2.7.1 Memory Available......................................................................................... 20
2.7.2 Protocol Indication / Alarm ........................................................................... 20
2.8 DCE Indication (EGC Only Codes) ................................................................. 20

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 2
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.8.1 EGC Messages ............................................................................................ 20


2.8.2 Group IDs..................................................................................................... 21

3 Summary of DTE/DCE Commands, Queries, Responses and


Indications ............................................................................ 21
3.1 Set Operating Parameters .............................................................................. 21
3.2 Set EGC Parameters ...................................................................................... 22
3.3 Set Message Parameters................................................................................ 22
3.4 Inmarsat-C Operation ..................................................................................... 22
3.5 Query .............................................................................................................. 23
3.6 DCE Responses ............................................................................................. 24
3.7 DCE Indication ................................................................................................ 25
3.8 DCE Indication (EGC-Only Codes) ................................................................. 25

4 Alphabetical List of Commands, Queries and Responses by


Code ..................................................................................... Letter
26

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 3
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
In the following definition of the codes used to transfer commands to the DCE and data between the
two devices, use is made of special characters to denote the start of a command, a request or a reply.

CSI (Control Sequence Indicator).

Commands and Responses employing a single parameter use this control code as the first character.
If the DCE-DTE link is working with eight bit data, then the value of CSI is 15510. CSI can also be
denoted by the escape sequence ESC[.

The format of commands and responses employing this control code is:

<CSI>[PARAM]<literal indicator>.

The <literal indicator> is a single letter, which, together with the parameter, uniquely defines the
command/response. It may be in upper case or lower case; the two cases being treated as distinct.

This form is also used for all queries, which take the form:

<CSI>?<literal indicator>

DCS & ST (Data Control Start and Stop)

Commands and Responses employing several parameters, use these two special characters to start
and end the command/response. The eight bit representation for DCS is 14410 and for ST is 15610.
The corresponding escape sequences are ESCP and ESC/ for DCS and ST respectively.

The format of commands/responses employing these control codes is:

<DCS><literal indicator>;<Parameter list><ST>

The parameters in the Parameter list are separated by ';'. The literal indicator uniquely defines the
command/response and will be the same as the literal indicator for the corresponding Query, if any.

2 Commands, Queries, Responses and Indications


The following list shows the recommended controls together with their character code (see Table 1 for
a summary of these control codes). Additional functions may be added if desired by a manufacturer
by employing the recommended sequence of <CSI> followed by an identification code of the
manufacturer within 'backslash' characters ' \ ' as shown below:

<CSI>\[MFR ID]\[ADD CTRL]

where [ADD CTRL] is a sequence indicating the additional control function: this sequence shall not
contain any characters <CSI>, <DCS> or <ST>.

It is envisaged that the DTE will normally have a high-level software program interfacing the User
(Windows, Menus, and so on) and these codes will only be used across the DTE/DCE interface.

2.1 Operating Parameters


This group of codes is concerned with the setting of the basic operating parameters of the Inmarsat-C
MES.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 4
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.1.1 NCS TDM Channels


Command:

<DCS>F; <NCS TDMs><ST>

Purpose: to set the NCS channels in the DCE's non-volatile memory; four NCS channels (plus one
spare) are permanently stored in the DCE (see Chapter 2, Section 6.3.1); the string <NCS TDMs>
shall be used to set up the remaining 76 NCS channels and it contains the sequence of NCS IDs and
Channel Numbers separated by ';'.

<NCS TDMs> ::= [NCS IDj];[CH NOj];..;[NCS IDk];[CH NOk]

where [NCS IDi] is a three-character ASCII representation of the ID Number and [CH NOi] is a five-
character ASCII representation of the Channel Number expressed in Decimal base (see Chapter 2,
Section 3.3.4).

Example: to set NCSs 144,261,355,53 to channels 8004, 11542, 9500, 13006 the code transmitted
shall be:

<DCS>F;144;08004;261;11542;355;09500;053;13006<ST>

The current setting can be requested with the Query: <CSI>?F and the response returned will have
the same format as the command above.

2.1.2 Preferred NCS


Command:

<CSI> [NCS] a

where [NCS] is as [NCS ID] in 2.1.1

Purpose: to inform the DCE of the preferred NCS to use, when a scanning operation is subsequently
initiated. If no value is entered, the MES will search for the first valid NCS common channel.
Example: to set NCS 037 as preferred, the code shall be:

<CSI>037a

The current setting can be requested with the Query: <CSI>?a and the response returned will have
the same format as the command above.

2.2 EGC Parameters


The codes in this group are used to set operating parameters when EGC reception capability is
provided.

2.2.1 Geographical Coordinates


Command:

<DCS>A;<GEOGR><ST>

Purpose: to provide the DCE with the geographical coordinates which will be used in recognising
certain types of EGC addressing; the string <GEOGR> shall contain the geographical data separated
by ' ; '.

<GEOGR> ::= [DEG];[MIN];[N/S];[DEG];[MIN];[E/W]

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 5
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

where [DEG] and [MIN] are respectively three-character and two-character ASCII representations of
the latitude (and longitude) in degrees and minutes. [N/S] is either 'N' or 'S' (North or South) and [E/W]
is either 'E' or 'W' (East or West).

Example: to set the current geographical coordinates to 56o23'S, 12o45'W (it is assumed that a code
<CSI>0u has been previously sent; see b.1), the code shall be:

<DCS>A;056;23;S;012;45;W<ST>

The current setting can be requested with the Query: <CSI>?A and the response returned will have
the same format as the command above.

2.2.2 Manual / NAV Equipment


Command:

<CSI> [NAV] u

Purpose: to indicate to the DCE whether the geographical coordinates are input by Navigational
Equipment (for example, via the NMEA interface) or by the DTE (manual input).

[NAV] is an ASCII character, either '0' for Manual Input or '1' for Input by Navigation Equipment.

Example: for geographical coordinates to be received by the DTE (operator entered), the code shall
be:

<CSI>0u

The current setting can be requested with the Query: <CSI>?u and the response returned will have
the same format as the command above.

2.2.3 NAVAREA Code


Command :

<CSI> [NAVAREA] o

Purpose: to set the Navarea code for certain types of EGC addressing. [NAVAREA] is a two-character
ASCII representation of the Navarea code from 00 up to 99.

Example: to set Navarea code '17' the code shall be:

<CSI>17o

The current setting can be requested with the Query: <CSI>?o and the response returned will have
the same format as the command above.

2.2.4 Navtex Code


Command :

<DCS> q; <NAVTEX><ST>

Purpose to set the Navtex code for certain types of EGC addressing. <NAVTEX> is a string
containing one or more Area code characters and one or more Report codes. The two groups are
separated by a semi-colon. Within each group the characters are separated by commas. Area code

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 6
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

characters are the B1 codes and Report codes are the B2 codes as defined in Part 1, Chapter 2,
Section 9.3.3.5. Thus:

<NAVTEX>::= <AREA CODES>;<REPORT CODES>

where

<AREA CODES>::= [B1 code],...[B1 code] and

<REPORT CODES>::= [B2 code],...[B2 code]

Example: to set Navtex transmitter coverage area B1 = T and Ice Report (B2 = C) the code shall be:

<DCS>q;T;C<ST>

The current setting can be requested with the Query: <CSI>?q and the response returned will have
the same format as the command above.

2.2.5 WMO Code


Command:

<CSI> [WMO] p

Purpose: to set the WMO area code for certain types of EGC addressing. [WMO] is a three-character
ASCII representation of the WMO areas from 000 up to 999.

Example: to set WMO area '27' the code shall be:

<CSI>027p

The current setting can be requested with the Query: <CSI>?p and the response returned will have
the same format as the command above.

2.3 Message Parameters


The codes in this group are mainly concerned with the setting of the parameters needed for
establishing a From-Mobile call.

2.3.1 Address
Command :

<CSI> [Id] c

Purpose: to select the address destination for From-Mobile messages as defined in Volume 4,
Chapter 4, Section 3.3.2.2.5. [ID] is an ASCII representation of the address information (6 characters
padded with leading zeroes) contained in the assignment request packet. Its interpretation will depend
on the service used.

Example 1: to select destination network ID code = 771 (republic of Vanuatu), the coding shall be:

<CSI>000771 c

Example 2: to select destination network ID code = CA5798 (special access code):

<CSI>CA5798 c

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 7
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

In addition, for destination addresses not included as part of the message text (ie, non-telex
destinations) the following command may be used:

<DCS> c;[COUNT];[ADD1];[ADD2];....[ADDN]<ST>

where [COUNT] is a 2 character ASCII representation of the number (in decimal) of addresses (N),
and [ADD1] to [ADDN] are the N addresses represented as character strings of ASCII characters.

Example: PSTN message transfer to number 44713830151 to be coded as:

<CSI>044 c

<DCS> c;01;44713830151<ST>

The current setting can be requested with the Query: <CSI>?c and the response returned will have
the same format as the command above.

2.3.2 Destination LES


Command :

<CSI> [LES] b

Purpose: to set the LES for From-Mobile messages. [LES] is a three-character ASCII representation
of the LES ID expressed in decimal base, in the range 0 to 363.

Example: to select the LES 27, the code shall be:

<CSI>027b

The current setting can be requested with the Query: <CSI>?b and the response returned will have
the same format as the command above.

2.3.3 Destination Type


Command :

<CSI> [TYPE] e

Purpose: to select the type of service of the destination for From-Mobile messages. [TYPE] is a one
character ASCII representation of the destination type (Volume 4, Chapter 4, Section 3.3.2.2.1)
expressed in decimal base.

Example: to select X.400 type destination, the code shall be

<CSI>4e

The current setting can be requested with the Query: <CSI>?e and the response returned will have
the same format as the command above.

2.3.4 Delivery Class


Command:

<CSI>[CLASS]f

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 8
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Purpose: to select the type of delivery required for the From-Mobile message transfer; [CLASS] is
either the character '0' for Immediate Delivery or '1' for Deferred Delivery (Volume 4, Chapter 5,
Section 3.1.2.1).

Example: to select Immediate Delivery, the code shall be:

<CSI>0f

The current setting can be requested with the Query: <CSI>?f and the response returned will have the
same format as the command above.

2.3.5 Delivery Confirmation


Command:

<CSI>[CONF]m

Purpose: to select the option of Delivery Confirmation from the LES for the From-Mobile message
transfer; [CONF] is either the character '0' for No Delivery Confirmation Required or '1' for Delivery
Confirmation (Volume 4, Chapter 5, Section 3.1.2.2).

Example: to select Delivery Confirmation, the code shall be:

<CSI>1m

The current setting can be requested with the Query: <CSI>?m and the response returned will have
the same format as the command above.

2.3.6 Distress Message Parameters


Command :

<DCS>G;<DMG><ST>

Purpose: to provide the DCE with the parameters to be used in the Distress Alert packet; the string
<DMG> shall contain the various data separated by ';' as specified below.

<DMS> ::= [LES ID]; <GEOGR>; [UPDATE HR]; [UPDATE MIN]; [PROT]; [NAT]; [COURSE];
[SPEED]

where

[PROT] is one ASCII character denoting the Protocol type (Volume 4, Chapter 4, Section 3.6.2);

[NAT] is a 2-character ASCII representation of the Nature of Distress expressed in decimal


base (Volume 4, Chapter 4, Section 3.6.3);

[COURSE] is a three-character ASCII representation of the Course code (Volume 4, Chapter 4,


Section 3.6.4) expressed in decimal base;

[SPEED] is a two-character ASCII representation of the Speed code (Volume 4, Chapter 4,


Section 3.6.5) expressed in decimal base;

[UPDATE HR] and [UPDATE MIN] are two-character ASCII representations respectively of the
hour and minute of the last update expressed in decimal base;

The formats of [LES ID] and <GEOGR> are as in Section 2.3.2 and Section 2.2.1 respectively.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 9
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Example: to set, at 03:45 UTC a Distress Alert message to LES 125 indicating maritime distress
because of sinking, with the mobile heading to SW at a speed of 10 knots from 56o23'S, 12o15'W, the
code shall be:

<DCS>A;125;056;23;S;012;15;W;03;45;0;06;225;10<ST>

The current setting can be requested with the Query: <CSI>?G and the response returned will have
the same format as the command above.

2.3.7 Message Priority


Command:

<CSI>[PRIOR]i

Purpose: to select the message priority (Priority field in the Request for Assignment packet) for From-
Mobile messages; [PRIOR] is either the character '0' for Normal Priority or '1' for Distress Priority
(Volume 4, Chapter 4, Section 1.1.1.1).

Example: to select Distress priority for a From-Mobile message transfer, the code shall be:

<CSI>1i

The current setting can be requested with the Query: <CSI>?i and the response returned will have the
same format as the command above.

2.3.8 Presentation
Command:

<CSI>[PRES]g

Purpose: to select the Presentation code with which the message will be transferred; [PRES] is a
three-character ASCII representation of the Presentation (Volume 4, Chapter 3, Section 4.13)
expressed in decimal base.

Example: to select Data presentation the code shall be:

<CSI>007g

The current setting can be requested with the Query: <CSI>?g and the response returned will have
the same format as the command above.

2.3.9 Service Type


Command :

<CSI> [SVCE] d

Purpose: to select the type of service required from the LES; [SVCE] is a two-character ASCII
representation of the service type (Volume 4, Chapter 4, Section 3.3.1) expressed in decimal base.

Example: to select Store-and-Forward, the code shall be:

<CSI>00d

The current setting can be requested with the Query: <CSI>?d and the response returned will have
the same format as the command above.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 10
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.3.10 Set Special Access Code


Command:

<DCS>S;[SAC]<ST>

Purpose: to select the destination for From-Mobile messages using a Special Access Code. [SAC] is
a 1 - six character ASCII representation of the Special Access Code.

Example: to select the Special Access Code = 33, the code shall be:

<DCS>S;33<ST>.

The current setting can be requested with the Query: <CSI>?S, and the response has the same
format as the setting command.

2.3.11 Destination Extension


Command:

<CSI>[DEXT] E

Purpose: to select the contents of the destination extension field of the assignment request packet (if
applicable). [DEXT] is an ASCII representation of the destination extension contents as defined in
Volume 4, Chapter 4, Section 3.3.2.2.4 (6 characters padded with leading zeroes).

Example: to select PSTN connection via a V.22 modem, the coding should be:

<CSI>000V22 E

The current setting can be requested with the Query: <CSI>?E, and the response has the same
format as the setting command.

2.4 Inmarsat-C Operation


2.4.1 Abort Current Operation

Command:

<CSI> 0 Z

Purpose: to terminate the current operation leaving the parameters in the DCE unchanged.

2.4.2 Clear Waiting Message


Command:

<CSI> 7 L

Purpose: to clear any pending message held, but not yet transmitted, for example because a
message is currently being received or an Announcement is awaited.

2.4.3 Commission Request


Command:

<CSI> 8 L

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 11
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Purpose: to request a Commissioning test from the NCS.

2.4.4 Confirm Operation


Command:

<CSI> 5 Y

Purpose: to provide a manual confirmation, for example of a Distress Alert or Test.

2.4.5 Distress Alert


Command:

<CSI > 5 L

Purpose: to initiate a Distress Alert. The DCE shall reply with within 1 second with:

Response from DCE : <CSI > 5 X

On receipt of this request for confirmation, the DTE shall prompt the operator to confirm the sending
of the distress message. When the operator confirms the request, the DTE sends:

From DTE : <CSI > 5 Y

2.4.6 Distress Alert (Test)


Command:

<CSI> 5 T

Purpose: same as in Section 2.4.5 except that the packet which will be sent is a Distress Alert Test
(Volume 4, Chapter 4, Section 3.8).

2.4.7 Forced Clear


Command :

<CSI> 2 L

Purpose: to cause the MES to transmit an MES Forced Clear packet, aborting the call in progress.

2.4.8 Log in
Command:

<CSI> 0 L

Purpose: to cause the MES to initiate the Log-in procedure. The MES will attempt to login to the
regional NCS. If the MES is already logged in to another ocean region, it is not necessary to initiate a
log out procedure with the NCS of that region, before attempting to synchronise with the NCS
common channel of the new region.

The current setting can be requested with the Query: <CSI>?L and the response returned will have
the same format as the command above with the parameter 0 if logged in or 1 if logged out.

2.4.9 Log out


Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 12
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Command:

<CSI> 1 L

Purpose: to cause the MES to initiate the Log-out procedure.

The current setting can be requested with the Query: <CSI>?L and the response returned will have
the same format as the command above with the parameter 0 if logged in or 1 if logged out.

2.4.10 Message Delivery Status Request


Command :

<CSI> 9 L

Purpose: to cause a Message Status Request packet to be sent to the LES to enquire about the
delivery status of the last Message transmitted. There is no immediate response.

2.4.11 PV Test
Command:

<CSI> 6 L

Purpose: to cause the MES to start a Performance Verification Test Request. The result of the test will
be held by the DCE until the DTE requests the result (see PVT Result query).

2.4.12 Scan NCS TDMs


Command:

<CSI> 1 h

Purpose: to cause the MES to start scanning through the NCS TDM channels, at present in memory,
for the best NCS common channel (strongest signal level).

2.4.13 Transfer Message to DCE


Command:

<DCS>M;[COUNT];[MESSAGE]<ST>

Purpose: to transfer a message to the DCE for subsequent transmission. [COUNT] is a five-character
ASCII representation of the number (in decimal) of bytes of data in the message being transferred,
and [MESSAGE] is the message data.

This command transfers a pre-formatted message from the DTE to the DCE prior to initiating
transmission.

In like manner, the first of any messages received may be requested with the Query: <CSI>?M and
the message returned will have the same format as the command above.

2.4.14 Transmit Message


Command:

<CSI> 3 L

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 13
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Purpose: if a message is residing in the DCE, the MES is logged in and the appropriate destination
parameters have been defined, the DCE will initiate the appropriate message transfer procedure.

2.4.15 Tune to NCS Channel


Command:

<CSI> [NCS] l

where [NCS] is a three-character ASCII representation of the ID number.

Purpose: to force the MES to acquire a particular NCS common channel.

Example: to tune the MES to NCS 261, the code shall be:

<CSI>261l

The current setting can be requested with the Query: <CSI>?l and the response returned will have the
same format as the command above.

2.5 MES Status Queries


The following sequences allow the DTE to obtain information on the current status of the DCE and the
Inmarsat-C network:

2.5.1 Current Channel?


Query:

<CSI> ? C

Purpose: to interrogate the DCE about the channel type it is currently engaged on.

Response from DCE:

<DCS> C; [CHANNEL] <ST>

where [CHANNEL] is one character, as follows:

'0' Unable to Synchronize

'1' NCS Common Channel

'2' LES TDM Channel

'3' Signalling Channel

'4' Message Channel

'5' Retuning

2.5.2 Current TDM?


Query:

<CSI> ? T

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 14
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Purpose: to interrogate the DCE receiver about the current TDM being received.

Response from DCE:

<DCS> T; [TDM TYPE]; [ID] <ST>

where [ID] is a three-character ASCII representation of the LES ID expressed in decimal base, in the
range 0 to 363 and [TDM TYPE] is one character as described below:

'0' Not Synchronised

'1' NCS Common Channel

'2' LES TDM

'3' Joint NCS Common and TDM

'4' Standby NCS Common Channel

2.5.3 Link Performance?


Query:

<CSI> ? P

Purpose: to interrogate the DCE receiver about the link quality.

Response from DCE:

<DCS> P; [PER] <ST>

where [PER] is a three-character ASCII representation of the Bulletin Board Error Rate represented
as a count of the number of errored Bulletin Boards detected out of the last 100 received.

2.5.4 Message Transfer Status?


Query:

<CSI> ? W

Purpose: to interrogate the DCE about the status of the current message transfer.

Response from DCE:

<DCS> W; [MESSAGE STATUS] <ST>

where [MESSAGE STATUS] is a string describing the current state of the message transfer in plain
language.

2.5.5 Messages Waiting?


Query:

<CSI> ? n

Purpose: to interrogate the DCE about the number of messages received and waiting to be read by
the DTE.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 15
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Response from DCE:

<CSI> [MSG COUNT] n

where [MSG COUNT] is a five-character ASCII representation of the number of messages received
but not read by the DTE.

2.5.6 Network?
Query:

<CSI> ? B

Purpose: to interrogate the DCE about the Network Configuration. This information is provided by the
NCS to the MES with the Log-in Acknowledgement packet.

Response from DCE:

<DCS>B; <NETWORK> <ST>

where <NETWORK> is a string formatted as follows:

<NETWORK> ::= [LES TOTAL];


[LES1 ID];[STATUS];[SVLES];CH;
[LES2 ID];[STATUS];[SVLES];CH;
.
.
[LESn ID];[STATUS];[SVLES];CH;

[LES TOTAL]: three-character ASCII representation of the number of LESs in


the Ocean Region (and therefore in the list) expressed in
decimal base (Volume 4, Chapter 3, Section 4.4);

[LESk ID]: three-character ASCII representation of the LES ID expressed


in decimal base.

[STATUS]: ASCII string of five characters B8B7B6B5B4, with each Bi


being either '0' or '1' (see Volume 4, Chapter 3, Section 4.2.1).

[SVLES]: ASCII string of eight characters B8B7B6B5B4B3B2B1, with


each Bi being either '0' or '1' (see Volume 4, Chapter 3, Section
4.2.2).

[CH]: a five-character ASCII representation of the Channel Number


expressed in decimal base.

2.5.7 Next Message Descriptor?


Query:

<CSI> ? D

Purpose: to interrogate the DCE about the description of the first received message waiting to be
read.
Response from DCE:

<DCS> D; <MSG DESCR>; <ST>

where <MSG DESCR> is formatted as follows:

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 16
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

<MSG DESCR> ::= [LES ID];[PRIOR];[SIZE];[MSG REF];[DD];[MM];[YR];[HR];[MIN]

[LES ID]: three-character ASCII representation of the LES ID expressed


in decimal base;

[PRIOR]: either '0' for Normal Priority or '3' for Distress;

[SIZE]: five-character ASCII representation of the Message Length in


bytes expressed in decimal base;

[MSG REF]: eight-character ASCII representation of the Message


Reference Number as given in Volume 4, Chapter 3, Section
4.11;

[DD],[MM],[YR],[HR],[MIN] two-character ASCII representation of, respectively, day,


month, year, hour and minute of reception.

2.5.8 Parameter Setting?


Query:

<CSI> ? [PARAM]

Purpose: to interrogate the DCE about the current setting of the specified parameter. [PARAM] is the
literal used when setting parameters as described in Sections 2.1, 2.2, 2.3 and the Login status in 2.4
as described above.

The Response returned is described in the relevant section above.

Examples: <CSI>?b will cause the DCE to respond with <CSI>079b if the
Destination LES ID has been previously set as 79;

<CSI>?q will cause the DCE to respond with


<DCS>q;C;E<ST> if the Navtex codes were previously set for a
Transmitter Coverage Area C and Meteorological Forecasts.

2.5.9 PVT Result?


Query:

<CSI> ? V

Purpose: to interrogate the DCE about the result of the previous Performance Verification Test.
Response from DCE :

<DCS> V; <RESULT> <ST>

where <RESULT> is a string formatted as described below:

<RESULT> ::= [REP];[BER];[FTA];[RTA];[DAT];[SS];[OVERALL]

[REP]: a one character ASCII representation of the number of full


attempts at testing, expressed in decimal base (Volume 4,
Chapter 3, Section 3.18.1.1).

[BER]: a one character ASCII representation of the BBER


assessment, expressed in decimal base (Volume 4, Chapter 3,
Section 3.18.1.2).

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 17
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

[FTA]: a one character ASCII representation of the number of forward


test message transfer attempts, expressed in decimal base
(Volume 4, Chapter 3, Section 3.18.1.3).

[RTA]: a one character ASCII representation of the number of return


test message transfer attempts, expressed in decimal base
(Volume 4, Chapter 3, Section 3.18.1.4).

[DAT]: a two-character ASCII representation of the distress alert test,


expressed in decimal base (Volume 4, Chapter 3, Section
3.18.1.5).

[SS]: a one character ASCII representation of the MES signal


strength observed by the LES, expressed in decimal base
(Volume 4, Chapter 3, Section 3.18.1.6).

[OVERALL]: a two-character ASCII representation of the overall results of


the tests, expressed in decimal base (Volume 4, Chapter 3,
Section 3.18.1.7).

2.5.10 Request Next Message?


Query:

<CSI> ? M

Purpose: to retrieve the next received message from the DCE. The DCE then removes it from the
head of the waiting queue.

Response from DCE : same format as transfer message

<DCS>M;[COUNT];[MESSAGE]<ST>

where [COUNT] is a five-character ASCII representation of the number (in decimal) of bytes of data in
the message being transferred, and [MESSAGE] is the message data.

2.5.11 MES Query?


Query:

<CSI> ? X

Purpose: to determine the sequence of events and actions within the DCE since the last enquiry.
Used for testing.

Response from DCE :

<DCS> X;(string1);(string2);......(stringn);<ST>

where (stringn) is a plain language string describing the action of the MES or the result; for example,
"Signalling channel failure: Congested".

2.5.12 MES Status?


Query :

<CSI> ? s

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 18
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Purpose: to interrogate the DCE about its status.

Response from DCE :

<CSI> [STATUS] s

where [STATUS] is one character representing the current status of the MES and is coded as follows:

'0' MES Idle

'1' MES busy

'2' MES busy (Distress Priority)

2.5.13 Current TDM?


Query:

<CSI> ? N

Purpose: to interrogate the DCE about the information contained in the currently received TDM
(Bulletin Board and Signalling Channel Descriptor packets).

Response from the DCE:

<DCS>N;<TDM INFO><ST>

where <TDM INFO> is a string formatted as described below:

<TDM INFO> ::= [CH TYPE];[LES ID];[STATUS];


[SVCES];[RND INT];[SIG];[2-F];
[SIG1];[MARK1];
[SIG2];[MARK2];
.
.
[SIGn];[MARKn]

[CH TYPE]: a one character ASCII representation in decimal base of the


code as given in Volume 4, Chapter 2, Section 3.1.4.1.

[LES ID]: a three-character ASCII representation of the LES ID


expressed in decimal base, in the range 0 to 363, as given in
Volume 4, Chapter 2, Section 3.1.4.4.

[STATUS]: ASCII string of five characters B8B7B6B5B4, with each Bi


being either '0' or '1' (see Volume 4, Chapter 2, Section
3.1.4.5).

[SVCES]: ASCII string of eight characters B8B7B6B5B4B3B2B1, with


each Bi being either '0' or '1' (see Volume 4, Chapter 2, Section
3.1.4.6).

[RND INT]: three-character ASCII representation of the Randomising


Interval as given in Volume 4, Chapter 2, Section 3.1.4.7.

[SIG]: two-character ASCII decimal representation of the number of


Signalling Channels as given in Volume 4, Chapter 2, Section
3.1.3.2.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 19
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

[2-F]: two-character ASCII decimal representation of the number of


the number of two-Frame Slots available in each Signalling
Channel as given in Volume 4, Chapter 2, Section 3.1.3.3.

[SIGj]: a five-character ASCII representation of the Channel Number


expressed in Decimal base (see Volume 4, Chapter 2, Section
3.2.7).

[MARKj]: string of either 14 or 28 ASCII characters coded as


S1S2S3..S14/28 where each Sk is the decimal representation
of the Slot Marker for slot k as given in Volume 4, Chapter 2,
Section 3.2.8.

Example: slot 7 unreserved and burst correctly received in slot 7 will result in S7 as '2'.

2.7 DCE Indication


In addition to the DCE Responses returned to Queries, the DCE can autonomously indicate certain
conditions.

2.7.1 Memory Available


Indication:

<DCS> Q; [MEM] <ST>

where [MEM] is the ASCII representation of the memory available in bytes.

Purpose: this status indicator will be presented by the DCE whenever the memory available is less
than 2 kbytes.

Example:

<DCS> Q; 1792 <ST>

2.7.2 Protocol Indication / Alarm


Indication :

<DCS> z; [TEXT] <ST>

Purpose: used by the DCE to send protocol related messages to the DTE. [TEXT] is a variable length
string of up to 255 ASCII characters.

Examples:

<DCS.z;MEMORY FULL: 1 KBYTE LEFT<ST>

<DCS.z;LOG IN FAIL: BARRED SHIP<ST>

<DCS.z;REQUEST PENDING<ST>

2.8 DCE Indication (EGC Only Codes)

2.8.1 EGC Messages


Indication :

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 20
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

<DCS> E; <MSG PARAMS>;[MESSAGE] <ST>

Purpose: this code is used by the DCE/EGC Receiver to transfer an EGC Message to the DTE.
[MESSAGE] is the message data and <MSG PARAMS> provides the message parameters formatted
as follows:

<MSG PARAMS> ::= [LES ID];[MSG SEQ];[PRIOR];[SVCE];[COUNT]

[LES ID]: [LES] is a three-character ASCII representation of the LES ID


expressed in decimal base, in the range 0 to 363;

[MSG SEQ]: a five-character ASCII decimal representation of the Message


Sequence Number as specified in Volume 4, Chapter 3,
Section 3.11.1.1.5;

[PRIOR]: a one character ASCII decimal representation ('0'..'3') of the


Priority Code as given in Volume 4, Chapter 3, Section
3.11.1.1.3;

[SVCE]: a three-character ASCII decimal representation of the Service


Code as given in Volume 4, Chapter 3, Section 3.11.1.1.1;

[COUNT]: a five-character ASCII representation of the number of bytes (in


decimal) of data in the message being transferred.

Example: An urgent NAVAREA warning message 'STORM FORCE WINDS, FORCE 10, EXPECTED
BISCAY IMMINENT' received from LES 68 with a sequence number of 221 will produce the following
code:

<DCS>E;068;00221;2;49;45;STORM FORCE WINDS, FORCE 10, EXPECTED BISCAY


IMMINENT<ST>

2.8.2 Group IDs


Indication :

<DCS> H; <GROUP IDs> <ST>

Purpose: to provide the DTE with information about the current Group IDs loaded in the EGC receiver.
The format of the string <GROUP IDs> is as follows:

<GROUP IDs> ::= [ID1];...;[IDn]

where [IDi] is an eight-character ASCII decimal representation of the 24-bit Group ID.

3 Summary of DTE/DCE Commands, Queries, Responses and


Indications

3.1 Set Operating Parameters


NCS TDM Channels <DCS>F;<NCS TDMs><ST>

Preferred NCS <CSI>[NCS]a

Additional functions <CSI>\[MFR ID]\[ADD CTRL]

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 21
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.2 Set EGC Parameters


Geographical Coordinates <DCS>A;<GEOGR><ST>

Manual/NAV Equipment <CSI>[NAV]u

NAVAREA Code <CSI>[NAVAREA]o

Navtex Code <DCS>q;<NAVTEX><ST>

WMO Code <CSI>[WMO]p

3.3 Set Message Parameters


Address <CSI>[ID]c

Destination LES <CSI>[LES]b

Destination Type <CSI>[TYPE]e

Delivery Class <CSI>[CLASS]f

Delivery Confirmation <CSI>[CONF]m

Distress Message Parameters <DCS>G;<DMG><ST>

Message Priority <CSI>[PRIOR]i

Presentation <CSI>[PRES]g

Service Type <CSI>[SVCE]d

Set Special Access Code <DCS>S:[SAC]<ST>

3.4 Inmarsat-C Operation


Abort Current Operation <CSI>0Z

Clear Waiting Send Message <CSI>7L

Commission Request <CSI>8L

Confirm Operation <CSI>5Y

Distress Alert <CSI>5L

Distress Alert (Test) <CSI>5T

Forced Clear <CSI>2L

Log in <CSI>0L

Log out <CSI>1L

Message Delivery Status Request <CSI>9L

PV Test <CSI>6L

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 22
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Scan NCS TDMs <CSI>1h

Transfer Message to DCE <DCS>M;[COUNT];[MESSAGE]<ST>

Transmit Message <CSI>3L

Tune to NCS Channel <CSI>[NCS]l

3.5 Query
Current Channel ? <CSI>?C

Current TDM ? <CSI>?T

Link Performance ? <CSI>?P

Message Transfer Status ? <CSI>?W

Messages Waiting ? <CSI>?n

Network ? <CSI>?B

Next Message Descriptor ? <CSI>?D

Parameter Setting ? <CSI>?[PARAM]

NCS TDM Channels ? <CSI>?F

Preferred NCS ? <CSI>?a

Manual/NAV Equipment ? <CSI>?u

Geographical Coordinates ? <CSI>?A

NAVAREA Code ? <CSI>?o

WMO Code ? <CSI>?p

Navtex Code ? <CSI>?q

Destination LES ? <CSI>?b

Address ? <CSI>?c

Destination Type ? <CSI>?e

Service Type ? <CSI>?d

Message Priority ? <CSI>?i

Delivery Class ? <CSI>?f

Delivery Confirmation ? <CSI>?m

Presentation ? <CSI>?g

Distress Message parameters ? <CSI>?G

Login/Logout Status <CSI>?L

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 23
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

PVT Result ? <CSI>?V

Request Next Message ? <CSI>?M

MES Query ? <CSI>?X

MES Status ? <CSI>?s

Current TDM ? <CSI>?N

Special Access Code? <CSI>?S

3.6 DCE Responses


Address <CSI>[ID]c

Current Channel <DCS>C;[CHANNEL]<ST>

Current TDM <DCS>T;[TDM TYPE];[ID]<ST>

Delivery Class <CSI>[CLASS]f

Delivery Confirmation <CSI>[CONF]m

Destination LES <CSI>[LES]b

Destination Type <CSI>[TYPE]e

Distress Alert Response <CSI>5X

Distress Message parameters <DCS>G;<DMG><ST>

Geographical Coordinates <DCS>A;<GEOGR><ST>

Link Performance <DCS>P;[PER]<ST>

Login Status <CSI>0L

Logout Status <CSI>1L

Manual/NAV Equipment <CSI>[NAV]u

Message Priority <CSI>[PRIOR]i

Messages Waiting <CSI><M>n

Message Transfer Status <DCS>W;[STATUS]<ST>

NAVAREA Code <CSI>[NAVAREA]o

Navtex Code <DCS>q;<NAVTEX><ST>

NCS TDM Channels <DCS>F;<NCS TDMs><ST>

Network <DCS>B;<NETWORK><ST>

Next Message <DCS>M;[COUNT];[MESSAGE]<ST>

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 24
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Next Message Descriptor <DCS>D;<MSG DESCRIPTOR><ST>

Preferred NCS <CSI>[NCS]a

Presentation <CSI>[PRES]g

PVT Result <DCS>V;<RESULT><ST>

Service Type <CSI>[SVCE]d

MES Query Response <DCS>X;<MES INFO><ST>

MES Status <CSI><S>s

Current TDM <DCS>N;<TDM INFO><ST>

WMO Code <CSI>[WMO]p

3.7 DCE Indication


Memory Available <DCS>Q;{Mem]<ST>

Protocol Indication/Alarm <DCS>z;[TEXT]<ST>

3.8 DCE Indication (EGC-Only Codes)


EGC Messages <DCS>E;<MSG PARAMS>;[MESSAGE]<ST>

Group IDs <DCS>H;<GROUP IDS><ST>

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 25
Chapter 4: DTE-DCE Interface Control Codes
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4 Alphabetical List of Commands, Queries and Responses by Code Letter

Code Meaning Command Query Response

A Geographical Coordinates <DCS>A; <GEOGR><ST> <CSI>?A same as command


a Preferred NCS <CSI>[NCS]a <CSI>?a same as command
B Network - <CSI>?B <DCS>B;<NETWORK><ST>
b Destination LES <CSI>[LES]b <CSI>?b same as command
C Current Channel - <CSI>?C <DCS>C;[CHANNEL]<ST>
c Address <CSI>[ID]c <CSI>?c same as command
D Next Message Descriptor - <CSI>?D <DCS>D;<MSG DESCRIPTOR><ST>
d Service Type <CSI>[SVCE]d <CSI>?d same as command
E EGC Messages - - <DCS>E;<MSG PARAMS>;[MESSAGE]<ST>
E Destination Extension <CSI>[DEXT] E <CSI>?E same as command
e Destination Type <CSI>[TYPE]e <CSI>?e same as command
F NCS TDM Channels <DCS>F;<NCS TDMs><ST> <CSI>?F same as command
f Delivery Class <CSI>[CLASS]f <CSI>?f same as command
G Distress Message Parameters <DCS>G;<DMG><ST> <CSI>?G same as command
g Presentation <CSI>[PRES]g <CSI>?g same as command
H Group Ids - - <DCS>H;<GROUP IDS><ST>
h Scan NCS TDMs <CSI>1h - -
i Message Priority <CSI>[PRIOR]i <CSI>?i same as command
0L Log in <CSI>0L <CSI>?L <CSI>0L or <CSI>1L
1L Log out <CSI>1L <CSI>?L <CSI>0L or <CSI>1L
2L Forced Clear <CSI>2L - -
3L Transmit Message <CSI>3L - -
5L Distress Alert <CSI>5L - -
6L PV Test <CSI>6L - -
7L Clear Waiting Send Message <CSI>7L - -

Inmarsat-C SDM Release 3.0 Page 4-26


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Code Meaning Command Query Response

8L Commission Request <CSI>8L - -


9L Message Delivery StatusRequest <CSI>9L - -
l Tune to NCS Channel <CSI>[NCS]l - -
M Transfer Message to DCE <DCS>M;[COUNT];[MESSAGE]<ST>/ <CSI>?M <DCS>M;[COUNT];[MESSAGE]<ST>
m Delivery Confirmation <CSI>[CONF]m <CSI>?m same as command
N Current TDM - <CSI>?N <DCS>N;<TDM INFO><ST>
n Messages Waiting - <CSI>?n <CSI><M>n
o NAVAREA Code <CSI>[NAVAREA]o <CSI>?o same as command
P Link Performance - <CSI>?P <DCS>P;[PER]<ST>
P WMO Code <CSI>[WMO]p <CSI>?p same as command
Q Memory Available - - <DCS>Q;{Mem]<ST>
Q Navtex Code <DCS>q;<NAVTEX><ST> <CSI>?q same as command
S Special Access Codes <DCS>S:[SAC]<ST> <CSI>?S same as command
s MES Status - <CSI>?s <CSI><S>s
5T Distress Alert (Test) <CSI>5T - -
T Current TDM - <CSI>?T <DCS>T;[TDM TYPE];[ID]<ST>
u Manual/NAV Equipment <CSI>[NAV]u <CSI>?u same as command
V PVT Result - <CSI>?V <DCS>V;<RESULT><ST>
W Message Transfer Status - <CSI>?W <DCS>W;[STATUS]<ST>
5X Distress Alert Response - - <CSI>5X
X MES Query Response - <CSI>?X <DCS>X;<SES INFO><ST>
Y Confirm Operation <CSI>5Y - -
Z Abort Current Operation <CSI>0Z - -
z Protocol Indication/Alarm - - <DCS>z;[TEXT]<ST>

Notes: Where there is a – (hyphen) in the command it means that the code cannot be used as a command.
Where there is a – (hyphen) in the query column it means that the code cannt be used as a query.
Where there is a – (hyphen) in the response column it means there is no response/indication corresponding to this code.
Where there is only an entry in the response column, it is to be understood that the code is used onlly in an Indictaion.
Inmarsat-C SDM Release 3.0 Page 4-26
Inmarsat Confidential C SDM
(Version Release CD004, CN138)

Chapter 5: Technical Requirements for Ship Earth


Stations

Contents

0 Scope ..................................................................................... 2

1 Introduction ............................................................................ 3

2 General Requirements for all Types of SESs ............................ 3


2.1 Classes of Inmarsat-C Mobile Earth Stations....................................................3
2.4 Mandatory Capabilities......................................................................................3

3 RF Subsystem Requirements ................................................... 3

4 Receiver Performance ............................................................. 3

5 Transmitter Performance ......................................................... 3

6 Access Control Requirements ................................................. 3

7 Message Processing Requirements ......................................... 3

8 Distress Calling ...................................................................... 4

9 Testing Functions ................................................................... 4


9.5.2 Alarms and Indications ...................................................................................4

10 Electromagnetic Compatibility ............................................... 4

11 Environmental Conditions ..................................................... 4


11.1 Purpose...........................................................................................................4
11.2 Environmental Conditions for INMARSAT-C SESS Suitable for General Use 4

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 1
Chapter 5: Technical Requirements for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN138)

0 Scope
Chapter 5 of Volume 3, Part 2 gives the specification for a basic maritime SES. This is an SES
designed for use on either unregulated (non-SOLAS) vessels or SOLAS (GMDSS) vessels (at the
discretion of National Administration), to enhance general communications capabilities. This type of
SES is not capable of transmitting distress calls and does not necessarily comply with the technical
requirements of IMO and IEC. Inmarsat does not require DTE for these SESs to comply with any
IMO/IEC requirements.

The numbering of sections in this Chapter follows that of Chapter 2. The requirements of Chapter 2
apply unless superseded by this Chapter.

The Chapter has three Annexes A, B, and C. When read in conjunction with the main text of
Chapter5, each Annex reflects an enhanced type of Inmarsat-C Ship Earth Station for use in special
circumstances as follows:

Annex A: Technical Requirements for a SOLAS Ship Earth Station with Distress Calling

An SES designed for use in a GMDSS installation on board a SOLAS vessel. The Inmarsat technical
requirements in Annex A are fully compatible with the specifications developed by IMO and IEC for
Inmarsat-C GMDSS equipment, including distress call capabilities. GMDSS SESs include "primary"
DTE (Data Terminating Equipment) which complies fully with the IMO/IEC requirements.

Annex B: Technical Requirements for a Supplementary SES for use in SOLAS Installations

An SES designed to enhance the general communication capabilities of a GMDSS installation. These
SESs are not capable of transmitting distress calls but do comply with the electro-magnetic
compatibility (EMC) and environmental requirements specified by IMO and IEC. SOLAS
supplementary SESs include DTE which complies with the IMO/IEC EMC and environmental
requirements.

Annex C: Technical Requirements for a Non-SOLAS SES with Distress Calling

An SES designed for use on either unregulated (non-SOLAS) vessels or SOLAS (GMDSS) vessels,
to enhance general communications capabilities. These SESs are capable of transmitting distress
calls but they do not necessarily comply with the technical requirements of IMO and IEC. The DTE is
a mandatory requirement in these SES installations as required by IMO COMSAR 3 but it need not
comply with IMO/IEC technical requirements.

The acceptability of any of these types of SES for installation in SOLAS vessels will be determined by
National Administrations.

The following tables may be used as a guide to the different sets of specifications for SESs and EGC
receivers:

Inmarsat-C SESs

SOLAS (IEC 945) Non-SOLAS


Distress Facilities Annex A Annex C
No Distress Facilities Annex B Chapter 5

SOLAS (IEC 945) Non-SOLAS

SafetyNETSM Chapter 5, Annex A and Chapter 8, Annex A Chapter 5 and Chapter 8, Annex B
FleetNETSM Chapter 5, Annex A and Chapter 8 Annex C Chapter 5 and Chapter 8 Annex C

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 2
Chapter 5: Technical Requirements for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN138)

1 Introduction
This Chapter and its Annexes describe the mandatory requirements for four different types of
Inmarsat-C Ship Earth Station (SES). An SES is Mobile Earth Station designed specifically for use at
sea.

The characteristics of an SES are generally the same as those of a Mobile Earth Station as described
in Chapter 2 of this volume. The purpose of this Chapter and Annexes is to point out the differences
that are applicable to the different types of maritime equipment.

2 General Requirements for all Types of SESs


As Chapter 2, Section 2 except where indicated below.

2.1 Classes of Inmarsat-C Mobile Earth Stations


In the case of Class 2 SESs not in the EGC receive only mode of operation, distress or safety related
messages shall be displayed or printed.

2.4 Mandatory Capabilities


The mandatory capabilities of each class of SES are as described in Chapter 2, with the following
additions (applicable to Class 1, 2 and 3 SESs):

e) 2-digit prefixed code addressing for From-Mobile Safety messages (see Volume 4, Chapter 4);

f) transmission of distress alerts;

g) transmission of distress priority messages

3 RF Subsystem Requirements
As Chapter 2, Section 3.

4 Receiver Performance
As Chapter 2, Section 4.

5 Transmitter Performance
As Chapter 2, Section 5.

6 Access Control Requirements


As Chapter 2, Section 6.

7 Message Processing Requirements


As Chapter 2, Section 7

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 3
Chapter 5: Technical Requirements for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN138)

8 Distress Calling
Neither Distress Alert nor Distress Priority Message transmission shall be possible from the basic
SES described in this Chapter.

9 Testing Functions
As Chapter 2, Section 9 except where indicated below.

9.5.2 Alarms and Indications


(i) SES fault indication: Chapter 2, Section 9 refers;

(ii) Loss of receiver synchronisation: Chapter 2, Section 7.3.2 refers; and

(iii) SES transmitting: Chapter 2, Section 7.3.2 (b) refers.

Additional alarms and indications may be provided at the manufacturer's discretion.

10 Electromagnetic Compatibility
As Chapter 2, Section 10.

11 Environmental Conditions

11.1 Purpose
The purpose of this section is to define the mandatory minimum environmental conditions for SESs
intended for maritime use which are to be type approved as suitable for operation within the
INMARSAT system.

11.2 Environmental Conditions for INMARSAT-C SESS Suitable for General Use
The following specification is mandatory for General Maritime SESs. Models of SES which are to be
type approved as suitable for maritime use within the INMARSAT system shall be designed so as to
operate over the following range of environmental conditions:

EME - Externally Mounted Equipment

IME - Internally Mounted Equipment

(a) Ambient Temperature: –35°C to +55°C (EME)


0°C to +45°C (IME)

(b) Relative Humidity: up to 95% at +40°C;

(c) Spray: solid droplets from any direction (EME);

(d) Ice: up to 25mm of ice (EME);

(e) Precipitation: up to 100mm/hour (EME);

(f) Wind: normal operation with relative


average wind speeds up to 100 knots (EME);

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 4
Chapter 5: Technical Requirements for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN138)

(g) Solar Radiation: Maximum flux density 1200 W/m2


Spectral composition:
Infra Red 51%
Visible 44.5%
Ultra Violet 4.5%

(h) Prime Power Variations:

AC Mains Supply: frequency ±6%


voltage ±10%

DC Mains Supply: voltage +10%, –20%

Battery Supply: voltage +35% (recharge),


–20% (discharge) of nominal

(i) Vibration:

Frequency Range (Hz) Level

2 – 10 2.54mm peak amplitude

10 – 100 1.0 g peak acceleration**

See Figure 5-1, curve (a)

**Note: 1g = 9.807 m/s2

Acceptable alternative levels for Internally Mounted Equipment only:

Frequency Range (Hz) Level

2 – 15.8 1.00mm peak amplitude

15.8 – 100 1.0 g peak acceleration

See Figure 5-1, curve (b)

During type approval, certain tests that are required to be conducted under vibration conditions may
be performed using pink noise vibration spectra instead of the sinusoidal swept frequency range
specified above. Refer to "Type Approval Procedures for Inmarsat-C Mobile Earth Stations", which is
available from Inmarsat;

Note: Consideration will be given to the relaxation of these conditions if necessary, in respect of a
printer if this is an integral part of the equipment (IME only). An example of acceptable minimum
conditions with respect to printer operation is given below:

Frequency Range (Hz) Level

2 – 13.6 0.4mm peak amplitude

13.6 – 50 0.3 g peak acceleration

See Figure 5-1, curve (c).

(j) Antenna Inclinations: Tilt in any direction up to 20° from


horizontal for satellite elevations >5°;

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 5
Chapter 5: Technical Requirements for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN138)

(k) Induced Acceleration: Maximum tangential or linear acceleration of up to


1.2 g;

(l) Velocity: Maximum velocity up to 60 knots (110 km/hr)

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 6
Chapter 5: Technical Requirements for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN140)

Chapter 5 - Annex A: Technical Requirements for a


Solas Ship Earth Station with Distress Calling
Capabilities

Contents

1 SOLAS and the GMDSS ............................................................ 3


1.1 Background .......................................................................................................3
1.2 Principal Relevant Documents ..........................................................................3

2 General Requirements ............................................................. 4


2.1 Classes of Inmarsat-C Mobile Earth Stations....................................................4
2.2 Inmarsat-C Ship Earth Station Definition...........................................................4
2.4 Mandatory Capabilities......................................................................................4
2.5 Software Storage Requirements .......................................................................5
2.6 GMDSS Documents ..........................................................................................5

3 RF Subsystem Requirements ................................................... 5

4 Receiver Performance ............................................................. 5

5 Transmitter Performance ......................................................... 5

6 Access Control Requirements ................................................. 5

7 Message Processing Requirements ......................................... 5


7.1 General .............................................................................................................5
7.1.1 Availability of the Primary DTE (Including GMDSS Printer) ...........................5
7.1.2 Additional Ports ..............................................................................................6
7.3 Display Devices ................................................................................................6
7.3.1 Printer Requirements .....................................................................................6
7.3.2 Status Display ................................................................................................6
7.5 Ship Earth Station Memory Capacity Requirements .........................................6
7.5.2 Non-Volatile Memory (DCE) ...........................................................................6

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 1
Chapter 5 - Annex A: Technical Requirements for a Solas Ship Earth Station with
Distress Calling Capabilities
Inmarsat Confidential C SDM
(Version Release CD004, CN140)

8 Distress Calling ...................................................................... 7


8.1 Signalling Channel Priorities for Distress Communication ................................7
8.2 Distress ALERT Generator ...............................................................................7
8.3 Distress Alert Activation ....................................................................................9
8.4 Distress Message Transmission .......................................................................9
8.5 Security Alert (MES Optional) ........................................................................ 10

9 Testing Functions ................................................................. 11


9.3 Performance Verification and Commissioning Testing .................................... 11
9.3.2 Performance Verification Testing ................................................................. 11
9.3.4 Distress Button Testing ................................................................................ 11
9.5 Alarms and Indications .................................................................................... 11
9.5.1 Distress Alarms ............................................................................................ 11
9.5.2 Other Alarms and Indications ....................................................................... 12
9.5.3 Security / Covert Alert ..................................................................................... 12

10 Interference and Electromagnetic Compatibility ................... 12


10.1 Mandatory Requirements .............................................................................. 12

11 Environmental Conditions ................................................... 13


11.1 Purpose......................................................................................................... 13
11.2 Environmental Conditions for Inmarsat-C SESS ........................................... 13

12 Optional Features ................................................................ 13


12.1 Connection Of External Equipment ............................................................... 14
12.2 Navigational Interface ................................................................................... 14

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 2
Chapter 5 - Annex A: Technical Requirements for a Solas Ship Earth Station with
Distress Calling Capabilities
Inmarsat Confidential C SDM
(Version Release CD004, CN140)

1 SOLAS and the GMDSS

1.1 Background
The Global Maritime Distress and Safety System (GMDSS) is a new and efficient
radiocommunications system based on satellite and terrestrial technology, designed to improve
communications relating to distress and the safety of life at sea. It was adopted by the International
Maritime Organization (IMO) in 1988, in the form of Amendments to the International Convention for the
Safety of Life at Sea (SOLAS), 1974 and came into effect on 1 February 1992. Completion of
implementation is scheduled for 1 February 1999.

It is the responsibility of National Administrations to determine whether a radio installation on board a


ship meets the GMDSS requirements. This is done by National Type Acceptance or Approval testing
of the sub-systems included in the installation and by inspection of the complete installation by a radio
surveyor.

National Type Acceptance testing for GMDSS equipment will usually be based on GMDSS
specifications and procedures prepared by the IMO and by the International Electrotechnical
Commission (IEC) on their behalf, although other national or regional specifications may be invoked
as well.

The major IMO and IEC documents, which are identified in following Section 1.2, not only summarise
the general requirements for GMDSS equipment, but also the special requirements for GMDSS
Inmarsat-C SESs, as specified by IMO/IEC.

To the extent possible, the technical requirements for ship earth stations as stated in this Annex have
been harmonised with the above mentioned specifications, and conflicts between the documents
should not arise. A number of the Inmarsat specifications have been completely revised to reflect the
latest IMO/IEC requirements, for example, the electro-magnetic compatibility and environmental
requirements. However, manufacturers should note that it has not been possible to incorporate all of
the IMO/IEC technical requirements, and reference must be made to the latest issues of the
documents listed overleaf (and any other relevant GMDSS documents), when designing new
Inmarsat-C SOLAS SESs. This will facilitate the passing of National Type Acceptance testing, should
this be required.

The characteristics of an SES are generally the same as those of a Mobile Earth Station as described
in Chapters 2 and 5 of this Volume. The purpose of this Annex is to point out the differences that are
applicable to SOLAS SESs. The numbering of sections in this Annex follow that of Chapter 2. The
requirements of Chapter 2 apply unless superseded by this Annex.

1.2 Principal Relevant Documents


For Inmarsat-C SESs and EGC receivers, the principal relevant documents in addition to this
Inmarsat-C SDM are:

i) "General Requirements for Shipborne Radio Equipment Forming Part of the Global Maritime
Distress and Safety System (GMDSS) and for Electronic Navigational Aids", published by the
IMO as Resolution A.694(17).

ii) "Performance Standards for Inmarsat Standard-C Ship Earth Stations Capable of Transmitting
and Receiving Direct-printing Communications"

Annex: Recommendations on Performance Standards for Inmarsat Standard-C Ship Earth


Stations Capable of Transmitting and Receiving Direct-printing Communications", published by
the IMO as Resolution A.663(16).

iii) "Performance Standards for Enhanced Group Call Equipment Communications"

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 3
Chapter 5 - Annex A: Technical Requirements for a Solas Ship Earth Station with
Distress Calling Capabilities
Inmarsat Confidential C SDM
(Version Release CD004, CN140)

Annex: Recommendations on Performance Standards for Enhanced Group Call Equipment",


published by the IMO as Resolution A.664(16).

iv) "Shipborne Radio Equipment Forming Part of the Global Maritime Distress and Safety System
and Marine Navigational Equipment", published by the IEC as IEC 945.

v) "Global Maritime Distress and Safety System (GMDSS), IEC 1097-4 - Part 4: Inmarsat-C Ship
Earth Station and Inmarsat-EGC (Enhanced Group Call) Equipment. Performance Standards,
Methods of Testing and Required Test Results", published by the IEC as IEC 1097-4 -Part 4.

The above mentioned documents may be obtained from the relevant authorities, whose
addresses are given below:

IMO IEC
International Maritime Organization International Electrotechnical Commission
4 Albert Embankment 3 Rue de Varembe
London P O Box 131,
SE1 7SR 1211 Geneva 20
United Kingdom Switzerland
Tel: +44 (0)71-735 7611 Tel: +41 (0)22 7340150
Fax: +44 (0)71-587 3210 Fax: +41 (0)22 7333843
Telex: 23588

2 General Requirements
As Chapter 2, Section 2 and Chapter 5, Section 2 except where indicated below.

2.1 Classes of Inmarsat-C Mobile Earth Stations


In the case of Class 2 SESs not in the EGC receive only mode of operation, distress or safety related
messages shall be printed.

2.2 Inmarsat-C Ship Earth Station Definition


SESs intended for use aboard vessels meeting the IMO SOLAS carriage requirements are required to
be equipped with INMARSAT approved primary DTE. The type approved SOLAS SES comprises a
specific combination of DCE and primary DTE, both of which must comply with the requirements of
this Annex, including Sections 10 and 11.

2.4 Mandatory Capabilities


The mandatory capabilities of each class of SOLAS SES are as described in Chapter 5, with the
following additions (applicable to Class 1, 2 and 3 SESs):

(h) If the BBER is 80% or more out of the last hundred received bulletin board packets, the SES
shall raise an alarm and the operator shall be advised to initiate a manual scan of NCS
Common Channels.

(i) Provision shall be made for a specific aural alarm and visual indication, at the position from
which the ship is normally navigated, to indicate receipt of a distress call. It shall not be possible
to disable this alarm and it shall only be possible to reset it manually.

(j) Provision shall be made for a visual indication at the primary DTE to indicate that the ship's
position has not been updated during the last 4 hours. It shall only be possible to reset this
indication by revalidating the ship's position.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 4
Chapter 5 - Annex A: Technical Requirements for a Solas Ship Earth Station with
Distress Calling Capabilities
Inmarsat Confidential C SDM
(Version Release CD004, CN140)

2.5 Software Storage Requirements


Software installed to meet IMO SOLAS carriage requirements shall comply with the latest issue of IEC
1097-4, at the time of Inmarsat type approval. At the time of writing, the current issue of this document
states that “Any programming material or software that forms part of the SES and which is necessary
for meeting the GMDSS requirements shall be permanently installed in the SES. Any software needed
to fulfil any distress and safety requirements of the GMDSS shall not be stored on any medium which
can be accessed, modified or corrupted.”

N.B. This programming material or software shall be resident in the DCE and/or the primary DTE.

2.6 GMDSS Documents


Manufacturers should note the requirements of the principal relevant documents identified in Section
1.2. Failure to design SESs in accordance with these requirements may result in National Type
Acceptance being withheld.

3 RF Subsystem Requirements
As Chapter 2, Section 3.

4 Receiver Performance
As Chapter 2, Section 4.

5 Transmitter Performance
As Chapter 2, Section 5.

6 Access Control Requirements


As Chapter 2, Section 6.

SOLAS SESs shall not perform automatic 24 hourly scanning of NCS common channels.

7 Message Processing Requirements


As Chapter 2, Section 7 except where indicated below.

7.1 General
Many of the GMDSS message processing functions will be carried out in the Data Terminating
Equipment (DTE). Therefore in SOLAS maritime equipment, DTE approved by Inmarsat as part of the
SES shall comply with the requirements of IEC 1097-4 and will be termed "primary DTE".

7.1.1 Availability of the Primary DTE (Including GMDSS Printer)


The primary DTE, including at least one visual display unit, keyboard and printer, shall be available
immediately on demand to service GMDSS functional requirements. All units comprising the primary
DTE shall be provided with fixing arrangements to prevent unauthorised removal or disconnection;
IEC 1097-4 refers.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 5
Chapter 5 - Annex A: Technical Requirements for a Solas Ship Earth Station with
Distress Calling Capabilities
Inmarsat Confidential C SDM
(Version Release CD004, CN140)

7.1.2 Additional Ports


If a port or ports are provided which allow the connection of external equipment, including additional
DTE(s), navigational receivers etc., a single user interface function shall be provided at the primary
DTE or the DCE which , when operated shall:

(i) force clear any From-Mobile message transfer in progress initiated from the additional port(s);

(ii) delete any queued operations initiated from the additional port(s); and

(iii) return the SES to the idle state.

7.3 Display Devices

7.3.1 Printer Requirements


Primary DTE shall include at least one printer. The printer requirements given in Volume 3, Part 2,
Chapter 2, Section 7.2 apply. In addition, any printer used for GMDSS purposes shall comply with the
following:

(i) The printing device shall be capable of printing at least 40 characters per line;

(ii) If a word cannot be accommodated in full on one line, it shall be transferred to the next line;

(iii) Messages with priorities higher than routine shall be printed out immediately on receipt,
regardless of character error rate. A low line mark shall be printed whenever a character is
received mutilated;

(iv) For messages with routine priority it shall be possible for the operator to select whether all are
printed immediately or stored for printing later;

(v) The printing device shall automatically feed 5 lines after completing a printed message; and

(vi) A local audible alarm shall be sounded to give advanced warning of a printer "paper low"
condition.

7.3.2 Status Display


An indication of reception of a valid distress alert acknowledgement from an LES following
transmission of an initial distress alert by the SES shall be provided.

7.5 Ship Earth Station Memory Capacity Requirements

7.5.2 Non-Volatile Memory (DCE)


In addition to the information to be held in non-volatile memory described in Chapter 5, the following
information shall also be held in non-volatile memory:

(c) Distress alert parameters

This shall be the latest update of the distress alert parameters (see Section 8.2)

(d) Section 2.5 of this Annex refers.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 6
Chapter 5 - Annex A: Technical Requirements for a Solas Ship Earth Station with
Distress Calling Capabilities
Inmarsat Confidential C SDM
(Version Release CD004, CN140)

8 Distress Calling
There are two types of distress calls; Distress Alerts and Distress Priority Messages.

A distress alert is a data packet carried on a signalling channel. A distress priority message is a store
and forward message, having distress priority, carried on a messaging channel.

It shall only be possible to initiate distress alerts from dedicated distress buttons; IEC 1097-4, Section
3.3.7 refers.

8.1 Signalling Channel Priorities for Distress Communication


Certain LESs and NCSs may be equipped with dedicated signalling channels for handling distress
alerts and distress priority From-Mobile message transfers. The priorities for using these or other
available channels for all live distress communications are as follows:

1 - The selected LESs dedicated distress signalling channel(s) if available;

2 - The selected LESs general signalling channels;

3 - The NCSs dedicated distress signalling channel(s) if available;

4 - The NCSs general signalling channels.

Note that dedicated distress signalling channels are channels for which only the maritime distress bit
has been set in the signalling channel descriptor.

8.2 Distress ALERT Generator


The SES shall include means to generate an automatically formatted distress alert. The information
shall be transmitted in a distress alert packet as defined in Volume 4, Chapter 4, Section 3.6. The
parameters of the distress alert packet shall be:

(1) SES 24 Bit Binary Identity (return link);

(2) LES ID (current NCS as default);

(3) Position Co-ordinates;

(4) Time of Last Update;

(5) Maritime protocol;

(6) Nature of Distress;

(7) Course;

(8) Speed;

(9) Security/covert alert;

(10) Indication that the position co-ordinates have, or have not, been updated within the last 24
hours
(to resolve ambiguity in date of last position update); and

(11) Indication that the course/speed has been updated within the last 60 mins.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 7
Chapter 5 - Annex A: Technical Requirements for a Solas Ship Earth Station with
Distress Calling Capabilities
Inmarsat Confidential C SDM
(Version Release CD004, CN140)

Means for manually updating distress parameters, 3, 4, 6, 7 and 8 shall be provided. Provision for
automatic updating of parameters 3, 4, 10 and 11 shall be made. Manual settings shall take priority
over automatic settings and shall be retained for 60 minutes after they have been entered, unless
reset manually.

A mobile that supports both Distress alerting and Covert / Security alerting will require a primary and
secondary LES setting in the mobile Distress Alert generator. The secondary LES must be an LES
operating with a permanent TDM channel.

A means shall be provided for an SES operator to pre-set the Distress Alert Generator (DAG) LES ID. If
the DAG LES ID is not set by the operator, the SES shall be able to set the LES ID automatically using
the following mechanism :

a) select a valid LES from the current network configuration;

b) default to the current NCS ID if the network configuration is unavailable;

c) automatic setting shall not take priority over the manual pre-set unless the pre-set LES ID
becomes invalid and a means for notifying the SES operator shall be provided when the manual
pre-set is overridden.

When any of the parameters are changed manually, they shall remain set until a distress alert
acknowledgement has been received or one hour elapses, whichever occurs sooner. The contents of
the distress alert generator shall then revert automatically to the "undesignated" state.

Fields for which the required information is unavailable shall be set to zero (except where indicated
otherwise in Volume 4, Chapter 4, Section 3.6 and the following table).

N.B.: An undesignated distress alert contains the following parameter settings:

(1) SES Identity (24 bits) SES return ID, as installed

(2) LES ID (8 bits) Pre-set by SES operator or automatically set based on


Network Information, or default- current NCS

(3) Position co-ordinates (40 bits) Last setting or as automatically updated or default - all
bits set to 1

(4) Time of last position update (11 bits) UTC, derived from NCS bulletin board frame number or
default - set to 1 (contained in default setting for (3)
above)

(5) Maritime protocol (2 bits) Both bits set to 0

(6) Nature of distress (4 bits) Default - all bits set to 0 ("Undesignated")*

(7) Course (9 bits) Last setting or default - all bits set to 1

(8) Speed (6 bits) Last setting or default - all bits set to 0

(9) Security/covert alert (1 bit) Default - set to 0, distress alert (only)set to 1


security/covert alert

(10) Position update (1 bit) Default - set to 1, not updated within the last 24 hours

(11) Course/speed update (1 bit) Default - set to 1, not updated within the last 60 minutes

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 8
Chapter 5 - Annex A: Technical Requirements for a Solas Ship Earth Station with
Distress Calling Capabilities
Inmarsat Confidential C SDM
(Version Release CD004, CN140)

* An "undesignated" nature of distress is a valid distress condition and will be forwarded to an RCC for
action.

Under normal (non-distress) conditions the distress alert parameters in memory shall be set to the
"undesignated" alert conditions. These will be transmitted on activation unless an alternative
parameter selection has been made manually less than one hour previously.

8.3 Distress Alert Activation


The following specification is mandatory:

It shall only be possible to initiate a distress alert (designated or undesignated) by pressing a


dedicated button. It shall be possible to initiate a distress alert at any time except during distress
button testing; Section 9.3 refers. It shall be possible to select the content of, but not initiate, a
designated distress alert, using the equipment keyboard or other means, before pressing one of the
dedicated buttons. The content of a distress alert will revert to undesignated 60 minutes after a
previous manual selection, if no further manual selection has taken place.

The buttons initiating a distress alert shall be clearly identified, dedicated to the function, and
protected against inadvertent activation. Such protection shall comprise two independent actions in
order to initiate transmission of an alert. Such a button shall not be any key of an ITU-T (CCITT)
digital input panel or of an ISO standard keyboard provided on the equipment.

The distress alert shall be initiated by pressing the button to activate the alert once, for at least 3
seconds.

A visual indication shall be provided within 6 seconds of the button first being pressed, to show that an
alert has been initiated. This indication shall be made at all positions from where the distress alert
may be initiated, and shall continue until reset manually. It shall be possible to initiate further alerts
without re-setting the first indication.

In addition, the following message shall be displayed at the primary DTE: "Sending Distress Alert".
On receipt of an acknowledgement packet from the LES, this message shall be changed to: "Distress
Acknowledgement received".

Activation of the distress alert mode shall terminate any call or PVT in progress, delete queued traffic
in the DCE, disable all additional DTE port(s) (but see Section 12.2 for the navigational interface port)
and transmit the distress alert packet. The distress alert will be retried a number of times (Volume 5,
Chapter 3 refers). If the SES cannot synchronise with the desired LES or fails to receive a distress
alert acknowledgement, it shall try to re-send the distress alert to the NCS in the same ocean region
as the LES. If the SES fails to receive a distress alert acknowledgement from the NCS, an indication
shall be given to the operator and the SES shall scan and attempt to synchronise to an NCS in
another ocean region. The SES shall make a number of attempts to send the distress alert before
abandoning the call and informing the SES operator.

If the LES is operating in demand assigned mode, the SES shall send the distress alert to the NCS.
The NCS shall acknowledge receipt of the distress alert by sending a distress alert acknowledgement
to the SES on the common channel.

8.4 Distress Message Transmission


A distress message is any text message composed and sent with distress priority from the primary
DTE keyboard. Upon selecting distress priority, the DTE shall insert the following into the fields
mentioned below (or the equivalent fields)

ADDRESS: SEARCH AND RESCUE

DELIVERY NOTIFICATION: YES


Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 9
Chapter 5 - Annex A: Technical Requirements for a Solas Ship Earth Station with
Distress Calling Capabilities
Inmarsat Confidential C SDM
(Version Release CD004, CN140)

PRESENTATION CODE: IA5

The DTE shall not allow the operator to modify the contents of these fields. If an attempt is made to
change any of these fields, the following message shall be displayed:

"Distress priority selected; modification of this field is not possible"

A visual indication shall be provided at the primary DTE on initiation of a distress message.

8.5 Security Alert (MES Optional)


Comment 1: It shall only be possible to initiate a security/covert alert from dedicated
security/covert alert buttons fulfilling the same requirements as the
dedicated distress buttons; IEC 1097-4, Section 3.3.7 refers.

The Distress alert has higher priority than the Covert / Security alert in all
situations even though they are both priority 3 communications. A Covert / Security
alert must never prevent or delay a Distress alert from the mobile.

Comment 2: Pressing a dedicated covert alert button will initiate the normal distress alert
protocol but with the following conditions:

i) There will be no audible alarms or visible indication given at any of the


distress alert activation points.

ii) There will be no indication to the operator that the alert has been activated
on any of the visual display devices e.g. the DCE, DTE or printer.

iii) There will be no confirmation messages of alert delivery, audible or visible


displayed on the DTE, DCE, alarm panels or printers whilst the alert is in
progress or at acknowledgement.

iv) The DAG will select “Piracy/ Armed Attack” as the nature of alert.

Comment 3: The security/covert alert shall be initiated by lifting the protective cover and
pushing the button once but the button must remain latched in the pushed state for
at least 30 seconds to activate the alert. During the 30 seconds period the operator
will have the option to cancel the alert by pressing the covert alert button a second
time, releasing the button to its un-pushed state.

Comment 4: The DTE would then indicate that the covert alert had been cancelled by an on
screen message. Alternatively a means of covert notification that the alert has
been cancelled shall be provided.

Comment 5: The covert alert will be processed as a distress alert and sent as a distress alert
packet to the LES/NCS according to the normal distress alert protocol. The
distress alert packet will indicate that it is a covert/security alert by utilising the
spare bit in the Distress Alert Generator, this should be clearly indicated at printout
at the LES.

A mobile that supports both Distress alerting and Covert/Security alerting will
require a primary and secondary LES setting in the mobile Distress Alert
generator. The secondary LES must be an LES operating with a permanent TDM
channel.

Comment 6: The LES will then process the Alert and forward to the designated authority.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 10
Chapter 5 - Annex A: Technical Requirements for a Solas Ship Earth Station with
Distress Calling Capabilities
Inmarsat Confidential C SDM
(Version Release CD004, CN140)

Comment 7: In the event that a security/covert alert is sent to the NCS, the NCS will
require an LES database look up table of all LES`s that support covert
alerting, to ensure forwarding to a competent authority.

Comment 8: In an SES which supports Distress alerting and Covert / Security alerting, if a
Covert / Security alert is activated after a distress alert has been activated
the Covert / Security alert must be queued until the Distress alert is complete.

If a Distress alert is activated within 10mins after a Covert / Security alert, the SES
must abandon the Covert / Security alert if this is in progress and immediately
send the Distress alert to a secondary LES, defined in the mobile Distress Alert
Generator.

Comment 9: A mobile which supports Distress alerting and Covert / Security alerting must
be inhibited from sending a Covert / Security alert when the mobile is not
logged into an NCS and has no current network configuration information. This is not
applicable to a mobile which supports only Covert / Security alerting
or only Distress alerting

9 Testing Functions
As Chapter 5, Section 9 except where indicated below.

9.3 Performance Verification and Commissioning Testing

9.3.2 Performance Verification Testing


For the duration of the PVT, the primary DTE or DCE shall display the message:

"Automatic test mode: Normal communication disabled. Do not press any distress button
unless you are in distress"

This message shall be removed at the end of the PVT or on initiation of a distress alert.
The PVT includes a distress alert test. On receipt of the distress test request packet from the LES, the
SES shall transmit the distress alert test packet automatically.

9.3.4 Distress Button Testing


It shall be possible for distress buttons, wiring and lamps to be tested locally, without transmitting, by
means of the SES being put into a special test mode, manually. The operator shall be informed via
the primary DTE that the distress buttons are under test and that he should cancel the test mode if a
real distress alert needs to be sent. This information shall remain on the DTE for the duration of the
test. Re-activation of the distress buttons after the test shall also be manual and shall remove the
message from the primary DTE.

9.3.5 Security/Alert Button Testing

Where this option is fitted it shall be possible to test the security buttons. Method as 9.3.4.

9.5 Alarms and Indications


The following alarms and indications shall be provided at the SES:

9.5.1 Distress Alarms

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 11
Chapter 5 - Annex A: Technical Requirements for a Solas Ship Earth Station with
Distress Calling Capabilities
Inmarsat Confidential C SDM
(Version Release CD004, CN140)

(i) initiation of a distress alert: Visual indication at all distress buttons and messages at

primary DTE (Section 8.3 refers);

(ii) initiation of a distress message: Visual indication at the primary DTE (Section 8.4 refers); and

(iii) Reception of a message with distress priority (Section 2.4 (i) refers)

Any of these conditions shall generate a common distress alarm signal at the SES, which is capable
of being extended to a remote alarm panel (e.g. by means of relay contacts) should this be required.

9.5.2 Other Alarms and Indications


(i) High BBER: Section 2.4 (h) refers;

(ii) Printer paper low: Section 7.3.1 (vi) refers;

(iii) SES fault indication: Chapter 2, Section 9 refers;

(iv) Loss of receiver synchronisation: Chapter 2, Section 7.3.2 refers; and

(v) Position update: Section 2.4 (j) refers.

It is recommended that any of these conditions shall generate a common alarm signal at the SES
(separate from that described in Section 9.5.1), which is capable of being extended to a remote alarm
panel (e.g. by means of relay contacts) should this be required.

The following indication shall also be provided at the SES but shall not be capable of being extended
remotely:

(vi) SES transmitting: Chapter 2, Section 7.3.2 (b) refers.

Additional alarms and indications may be provided at the manufacturer's discretion.

9.5.3 Security / Covert Alert


Cancellation of the security/covert alert should give an indication on the primary DTE (excluding the
GMDSS printer). Alternatively a means of covert notification that the alert has been cancelled shall be
provided.

10 Interference and Electromagnetic Compatibility

10.1 Mandatory Requirements


The requirements of IEC 945, Section 3.5 apply.

Manufacturers should note that National Administrations may apply the test procedures detailed in
IEC 9451, as part of their National Type Acceptance procedures. Inmarsat-C SESs for SOLAS
installations shall therefore be designed to meet the requirements of the latest issue of IEC 945.

(b) Experience at sea indicates that unwanted transmissions, including false distress alerts or
corruption of data, may be caused by unwanted external electrical/electromagnetic stimuli.
SESs shall therefore be designed so as not to malfunction under the influence of:

(i) strong radio frequency fields;

1 At the time of publication, this was, IEC 945 Edition 2: Section 4.5 and AnnexA.
Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 12
Chapter 5 - Annex A: Technical Requirements for a Solas Ship Earth Station with
Distress Calling Capabilities
Inmarsat Confidential C SDM
(Version Release CD004, CN140)

(ii) power supply failure (short and long term)/and or reversal;

(iii) transients on power supply and control lines;

(iv) conducted interference

(v) open and short circuited connecting cables; and

(vi) electrostatic discharge.

11 Environmental Conditions

11.1 Purpose
The purpose of this section is to define the mandatory minimum environmental conditions for SOLAS
SESs which are to be type approved as suitable for operation within the INMARSAT system. This
section should be read in conjunction with the latest issues of IEC 1097-4 and IEC 945.

11.2 Environmental Conditions for Inmarsat-C SESS


The following specification is mandatory for SOLAS SESs.

Models of SOLAS SES which are type approved as suitable for maritime use within the INMARSAT
system shall be designed to operate satisfactorily over the following range and environmental
conditions give in Chapter 5, Section 11.2:

(a) Ambient Temperature:

Operating: –35°C to +55°C (EME)


–15°C to +55°C (IME)

Non-operating: +70°C (EME)

(h) Prime Power Variations:

As Chapter 5.

Means shall be incorporated for the protection of equipment from the effects of excessive current and
voltage, transients and accidental reversal of the power supply polarity or phase sequence.

(i) Vibration:

The SES (including primary DTE and printers) shall operate satisfactorily when subjected to the
vibration specified in IEC 945, Section 4.4.7. In addition to the requirements of IEC 945, Externally
Mounted Equipment (EME) shall also operate satisfactorily when subjected to the sinusoidal
vibrations specified below:

Frequency Range Peak Amplitude

2-5 Hz 2.54 mm

Vibration shall be applied in three orthogonal axes.

12 Optional Features

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 13
Chapter 5 - Annex A: Technical Requirements for a Solas Ship Earth Station with
Distress Calling Capabilities
Inmarsat Confidential C SDM
(Version Release CD004, CN140)

12.1 Connection Of External Equipment

Where a manufacturer fits a port (or ports) allowing connection of external equipment1, for example,
additional DTE etc., the SOLAS SES (shall be designed so that operation of the SES via the port (or
ports) shall be restricted, as follows:

a) The following functions shall not be possible via the port(s):

i) initiation of a distress alert, Section 8 refers;

ii) modification of the contents of the distress alert generator;

iii) initiation of a distress priority message;

iv) overriding any From-Mobile or To-Mobile distress calling function being executed at the
primary DTE, distress buttons or DCE;

v) modification or corruption of any GMDSS programs;

vi) logging in and out of the network;

vii) initiation of receiver frequency scanning; and

viii) changing the idle frequency of the receiver.

b) It shall be possible to de-activate the port(s) from the primary DTE or the DCE, at any time. The
port(s) shall remain de-activated until re-set from the primary DTE or DCE. Operation of the
primary DTE, the DCE and distress buttons shall be unaffected by activation or de-activation of
the port(s); Section 7.1.2 refers.

c) Connection and disconnection of equipment connected to the port(s) at any time shall have no
adverse effect on the operation of the SES.

d) Connection of external equipment to the port shall not jeopardise the interference/electro-
magnetic compatibility of the SES; Section 10 refers.

12.2 Navigational Interface


In order that an SES's position may be automatically updated for the transmission of ship's position
and for the reception of geographically addressed messages, SESs may be equipped with an
interface solely for navigational instruments. A suggested standard interface is defined in IEC 1162
Part 1 (NMEA 0183). All limitations of Section 12.1 shall apply with the exception of (ii).

It shall not be possible for data from the navigational interface to change the position stored in the
Distress Alert Generator (DAG) while the contents of the DAG are being read.

1 National Type Acceptance requirements may apply to equipment connected to this port.
Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 14
Chapter 5 - Annex A: Technical Requirements for a Solas Ship Earth Station with
Distress Calling Capabilities
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 5 - Annex B: Technical Requirements for a


Supplementary Ship Earth Station Without Distress
Calling for use in SOLAS Installations

Contents

1 SOLAS and the GMDSS ............................................................ 2


1.1 Background .......................................................................................................2
1.2 Principal Relevant Documents ..........................................................................2

2 General Requirements ............................................................. 2


2.6 GMDSS Documents ..........................................................................................2

3 RF Subsystem Requirements ................................................... 2

4 Receiver Performance ............................................................. 3

5 Transmitter Performance ......................................................... 3

6 Access Control Requirements ................................................. 3

7 Message Processing Requirements ......................................... 3

8 Distress Calling ...................................................................... 3

9 Testing Functions ................................................................... 3

10 Interference and Electromagnetic Compatibility ..................... 3


10.1 Mandatory Requirements ................................................................................3

11 Environmental Conditions ..................................................... 4


11.1 Purpose...........................................................................................................4
11.2 Environmental Conditions for Inmarsat-C SESS .............................................4

12 Optional Features .................................................................. 5


12.1 Connection of External Equipment ..................................................................5

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 1
Chapter 5 - Annex B: Technical Requirements for a Supplementary Ship Earth
Station Without Distress Calling for use in SOLAS Installations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 SOLAS and the GMDSS

1.1 Background

The Global Maritime Distress and Safety System (GMDSS) is a new and efficient
radiocommunications system based on satellite and terrestrial technology, designed to improve
communications relating to distress and the safety of life at sea. It was adopted by the International
Maritime Organization (IMO) in 1988, in the form of Amendments to the International Convention for the
Safety of Life at Sea (SOLAS), 1974 and came into effect on 1 February 1992. Completion of
implementation is scheduled for 1 February 1999.

Inmarsat-C SESs designed to provide the GMDSS distress and safety functions defined by the IMO
are described in Volume 3, Part 2, Chapter 5, Annex A and are called SOLAS SESs.

This Annex to Chapter 5 describes the characteristics of ship earth stations for providing
supplementary general communication functions (e.g polling) for vessels already equipped with at
least one SOLAS SES for distress and safety purposes. SOLAS supplementary SESs described here
do not provide the distress and safety functions to be found in SOLAS SESs but they do comply with
the environmental and electro-magnetic compatibility requirements of IEC 945.

The characteristics of these SES are generally the same as those of a Mobile Earth Station as
described in Chapters 2 and 5 of this Volume. The purpose of this Annex is to point out the
differences that are applicable to SOLAS Supplementary equipment. The numbering of sections in
this Annex follows that of Chapter 2. The requirements of Chapter 2 apply unless superseded by this
Annex.

1.2 Principal Relevant Documents


For SOLAS supplementary Inmarsat-C SESs, the principal relevant document in addition to this
Annex to Chapter 5 of the Inmarsat-C SDM is:

"Shipborne Radio Equipment Forming Part of the Global Maritime Distress and Safety System and
Marine Navigational Equipment", published by the IEC as IEC 945.

The above mentioned document may be obtained from:

International Electrotechnical Commission


3 Rue de Varembe
P O Box 131,
1211 Geneva 20
Switzerland

2 General Requirements
As Chapter 2, Section 2 except where indicated below.

2.6 GMDSS Documents


Manufacturers should note the requirements of IEC 945. Failure to design SOLAS supplementary
SESs in accordance with these requirements may result in National Type Acceptance being withheld.

3 RF Subsystem Requirements
As Chapter 2, Section 3.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 2
Chapter 5 - Annex B: Technical Requirements for a Supplementary Ship Earth
Station Without Distress Calling for use in SOLAS Installations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4 Receiver Performance
As Chapter 2, Section 4.

5 Transmitter Performance
As Chapter 2, Section 5.

6 Access Control Requirements


As Chapter 2, Section 6.

7 Message Processing Requirements


As Chapter 2, Section 7.

8 Distress Calling
Neither Distress Alert nor Distress Priority Message transmissions shall be possible from SOLAS
supplementary SESs designed in accordance with the specification given in this Annex.

9 Testing Functions
As Chapter 2, Section 9.

The PVT includes a distress alert test. On receipt of test request packet from the LES, the SES shall
transmit a distress alert test packet automatically without the operator being made aware of the
transmission.

10 Interference and Electromagnetic Compatibility

10.1 Mandatory Requirements


(a) The requirements of IEC 945, Section 3.5 apply.

Manufacturers should note that National Administrations may apply the test and test procedures
detailed in IEC 9451, as part of their National Type Acceptance procedures. Inmarsat-C SOLAS
supplementary SESs shall therefore be designed to meet the requirements of the latest issue of IEC
945.

(b) Experience at sea indicates that unwanted transmissions or corruption of data, may be caused
by unwanted external electrical/electromagnetic stimuli. SOLAS supplementary SESs shall
therefore be designed so as not to malfunction under the influence of:

(i) strong radio frequency fields;

(ii) power supply failure (short and long term)/and or reversal;

1 At the time of publication, this was, IEC 945 Edition 2: Section 4.5 and Annex A.
Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 3
Chapter 5 - Annex B: Technical Requirements for a Supplementary Ship Earth
Station Without Distress Calling for use in SOLAS Installations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(iii) transients on power supply and control lines;

(iv) conducted interference

(v) open and short circuited connecting cables; and

(vi) electrostatic discharge.

11 Environmental Conditions

11.1 Purpose
The purpose of this section is to define the mandatory minimum environmental conditions for SOLAS
Supplementary SESs which are to be type approved as suitable for operation within the INMARSAT
system. This section should be read in conjunction with the latest issues of IEC 945 .

11.2 Environmental Conditions for Inmarsat-C SESS


The following specification is mandatory for SOLAS Supplementary SESs.

Models of SES which are to be type approved as suitable for maritime use within the INMARSAT
system shall be designed so as to operate satisfactorily over the range of environmental conditions
given in Chapter 5, Section 11.2, except indicated as follows:

EME - Externally Mounted Equipment

IME - Internally Mounted Equipment

(a) Ambient Temperature:

Operating: –35°C to +55°C (EME)


–15°C to +55°C (IME)

Non-Operating: +70°C (EME)

(h) Power Supply Requirements:

Same as Chapter 5.

Means shall be incorporated for the protection of equipment from the effects of excessive current and
voltage, transients and accidental reversal of the power supply polarity or phase sequence.

(i) Vibration:

The SES (including DTE and printers) shall operate satisfactorily when subjected to the vibration
specified in IEC 945, Section 4.4.7. In addition to the requirements of IEC 945, Externally Mounted
Equipment (EME) shall also operate satisfactorily when subjected to the sinusoidal vibrations
specified below:

Frequency Range Peak Amplitude

2-5 Hz 2.54 mm

Vibration shall be applied in three orthogonal axes.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 4
Chapter 5 - Annex B: Technical Requirements for a Supplementary Ship Earth
Station Without Distress Calling for use in SOLAS Installations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

12 Optional Features

12.1 Connection of External Equipment


a) Connection and disconnection of equipment connected to any external equipment port(s) at
any time shall have no adverse effect on the operation of the SES.

b) Connection of external equipment to the port(s) shall not jeopardise the interference/electro-
magnetic compatibility of the SES; Section 10 refers.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 5
Chapter 5 - Annex B: Technical Requirements for a Supplementary Ship Earth
Station Without Distress Calling for use in SOLAS Installations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 5 - Annex C: Technical Requirements for a


Non-SOLAS SES with Distress Calling

Contents

1 Introduction ............................................................................ 2

2 General Requirements ............................................................. 2

3 RF Subsystem Requirements ................................................... 2

4 Receiver Performance ............................................................. 2

5 Transmitter Performance ......................................................... 2

6 Access Control Requirements ................................................. 2

7 Message Processing Requirements ......................................... 2


7.3 Display Devices ................................................................................................2
7.3.2 Status Display ................................................................................................2
7.5 Ship Earth Station Memory Capacity Requirements .........................................2
7.5.2 Non-Volatile Memory (DCE) ...........................................................................2

8 Distress Calling ...................................................................... 3

9 Testing Functions ................................................................... 3


9.5.1 Distress Alarms ..............................................................................................3
9.5.2 Other Alarms and Indications .........................................................................3

10 Electromagnetic Compatibility ............................................... 3

11 Environmental Conditions ..................................................... 3

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 1
Chapter 5 - Annex C: Technical Requirements for a Non-SOLAS SES with Distress
Calling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
This Annex describes the mandatory requirements for Non-SOLAS Inmarsat-C Ship Earth Stations
with distress facilities.

The characteristics of an SES are generally the same as those of a Mobile Earth Station as described
in Chapter 2 of this volume. The purpose of this Annex is to point out the differences that are
applicable for Non-SOLAS SES with distress facilities. The numbering of sections in this Annex follow
those of Chapter 2 and where a Chapter 2 section is not included it must be assumed that the original
Chapter 2 or the subsequent of Chapter 5 requirements still apply.

2 General Requirements
As Chapter 2, Section 2 and Chapter 5 Section 2.

3 RF Subsystem Requirements
As Chapter 2, Section 3.

4 Receiver Performance
As Chapter 2, Section 4.

5 Transmitter Performance
As Chapter 2, Section 5.

6 Access Control Requirements


As Chapter 2, Section 6.

7 Message Processing Requirements


As Chapter 2, Section 7.

7.3 Display Devices

7.3.2 Status Display


An indication of reception of a valid distress alert acknowledgement from an LES following
transmission of an initial distress alert by the SES shall be provided.

7.5 Ship Earth Station Memory Capacity Requirements

7.5.2 Non-Volatile Memory (DCE)


In addition to the information to be held in non-volatile memory described in Chapter 2, the following
information shall also be held in non-volatile memory:

(c) Distress alert parameters.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 2
Chapter 5 - Annex C: Technical Requirements for a Non-SOLAS SES with Distress
Calling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

This shall be the latest update of the distress alert parameters (see Annex A, Section 8.2).

8 Distress Calling
As Chapter5, Annex A, Section 8

9 Testing Functions
As Chapter 5, Annex A, Section 9, except for the following:

9.5.1 Distress Alarms


The inclusion of a common alarm and output is optional.

9.5.2 Other Alarms and Indications


The inclusion of a common alarm and output is optional.

10 Electromagnetic Compatibility
As Chapter 2, Section 10.

11 Environmental Conditions
As Chapter 2, Section 11 and Chapter 5, Section 11.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 3
Chapter 5 - Annex C: Technical Requirements for a Non-SOLAS SES with Distress
Calling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 6: Technical Requirements for a Land


Mobile Earth Station

Contents

1 Introduction ............................................................................ 3

2 General Requirements ............................................................. 3


2.4 Mandatory Capabilities......................................................................................3

3 RF Subsystem Requirements ................................................... 3


3.2 Antenna Requirements .....................................................................................3
3.3 Receiver RF Requirements ...............................................................................3
3.3.1 Gain-to-Noise Temperature Ratio ..................................................................3
3.3.3 Immunity to Out of Band Signals ....................................................................4
3.4 Transmitter RF Requirements ...........................................................................4
3.4.1 EIRP...............................................................................................................4
3.4.3 Transmitter Off Power Level ..........................................................................4
3.4.4 Spurious Outputs ...........................................................................................5
3.4.5 Harmonic Outputs ..........................................................................................5
3.4.6 Phase Noise...................................................................................................5
3.4.8 Frequency Accuracy and Stability ..................................................................5

4 Receiver Performance ............................................................. 6


4.7 Performance Under Blockage Conditions .........................................................6
4.7.1 General ..........................................................................................................6
4.7.2 Channel Model For Blockage. ........................................................................6
4.7.3 Performance with Short Term Repetitive Blockage ........................................6
4.7.4 Performance with Long Term Blockage .........................................................7

5 Transmitter Performance ......................................................... 7

6 Access Control Requirements ................................................. 7


6.5 Ocean Region Registration Procedures ............................................................7

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 1
Chapter 6: Technical Requirements for a Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6.5.1 Logging In ......................................................................................................7

7 Message Processing Requirements ......................................... 8

8 Alerting Functions .................................................................. 8


8.1 LES Service ......................................................................................................8
8.2 Signalling Channel Precedence ........................................................................8
8.3 Land Mobile Alert Generator .............................................................................9
8.4 Alert Activation ..................................................................................................9

9 Testing Functions ................................................................... 9


9.3 Performance Verification and Commissioning Testing ......................................9

10 Electromagnetic Compatibility ............................................. 10

11 Environmental Conditions ................................................... 10


11.1 Purpose and Applicability .............................................................................. 10
11.2 Recommended Environmental Conditions for a Land Mobile Earth Station .. 10

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 2
Chapter 6: Technical Requirements for a Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
This chapter describes the requirements and recommendations for a Land Mobile Earth Station
(LMES), which is a Mobile Earth Station designed specifically for use in a vehicle.

The characteristics of an LMES are generally the same as those of a Mobile Earth Station as
described in Chapter 2 of this volume. The purpose of this chapter is to point out the differences that
are applicable for land mobile equipment. The numbering of sections in this chapter follow those of
Chapter 2 and where a section of Chapter 2 is not mentioned, it must be assumed that the original
Chapter 2 requirement still applies.

It should not be assumed that this chapter covers any national or regional requirements, which may
have to be met in addition to those referred to here.

2 General Requirements

2.4 Mandatory Capabilities


Chapter 2, Section 2.4, items relating to EGC messages, are applicable to Class 2 and Class 3
LMESs, but only for reception of FleetNETSM messages; that is, reception of SafetyNETSM is not
mandatory. Class 2 and Class 3 LMESs should be capable of receiving EGC messages which are not
classified as either SafetyNETSM or FleetNETSM, namely 'All Mobiles call' (General call) and
'INMARSAT System message', but reception of such messages may be inhibited by the user.

3 RF Subsystem Requirements

3.2 Antenna Requirements


For the case of an omnidirectional antenna suitable for general land mobile use, a reduction in
antenna gain at low elevation angles (that is, θ ≤ 0° ) is desirable (see Chapter 2, Section 3.2.1).

It is permissible for LMESs to use antennas with radiation patterns optimised for a defined coverage
region. Any restrictions in coverage should be made known to prospective users of the equipment
(see Chapter 2, Section 3.2.2).

Applications for the type or case approval of LMESs equipped with special antennas should be
accompanied by detailed antenna characteristics and supporting information, including the proposed
operating environment and location(s), to justify the use of a special antenna configuration (see
Chapter 2, Section 3.2.3). Technical requirements for alternative antenna configurations are
presented in Chapter 3.

3.3 Receiver RF Requirements


As Chapter 2, Section 3.3, except where indicated below.

3.3.1 Gain-to-Noise Temperature Ratio


For the case of LMESs intended for general Land Mobile use, the requirements are as stated in
Chapter 2, Section 3.3.1, except that the G/T ratio need not be maintained for low elevation angles
(that is, θ ≤ 0°).

For LMESs with optimised antennas, the G/T ratio need only be maintained for the applicable antenna
elevation angles, with due regard being given to the anticipated tilting of the antenna.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 3
Chapter 6: Technical Requirements for a Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.3.3 Immunity to Out of Band Signals


As Chapter 2, Section 3.3.3, except that the frequency band of emissions is extended as follows:

30 MHz to 1400 MHz and

1626.5 MHz to 4000 MHz

The flux density of –15 dBW/m2 remains unchanged.

A maximum of 6 identified spurious responses to signals at a flux density of –45 dBW/m2 are
permitted in the above bands.

Consideration will be given to relaxing this requirement for the special case of receiver image
response, providing that the image band lies at a frequency unlikely to contain interfering signals at
such a level as to increase the packet error probability. As a guideline, it is recommended that the
image rejection should not be less than 60dB. Where doubt exists, the higher limit of -45 dBW/m2
shall apply.

3.4 Transmitter RF Requirements


As Chapter 2, Section 3.4, except where indicated below.

3.4.1 EIRP
For the case of LMESs intended for general Land Mobile use, the requirements are as stated in
Chapter 2, Section 3.4.1, except that the minimum EIRP need not be maintained for low elevation
angles (that is, θ ≤ 0°).

For LMESs with optimised antennas, the minimum EIRP need only be maintained for the applicable
antenna elevation angles, with due regard being given to the anticipated tilting of the antenna.

The maximum EIRP radiated by the LMES in any direction shall not exceed +16 dBW. The variation in
EIRP due to all causes shall be such as to maintain the EIRP towards the satellite within these
specified limits under all operational conditions.

3.4.3 Transmitter Off Power Level


In addition to the requirements of Chapter 2, Section 3.4.3, the LMES shall not radiate more than the
following power levels when in the idle (not transmitting) state:

– 87 dBW total power in the band 100 kHz to 1000 MHz

– 77 dBW total power in the band 1000 MHz to 4000 MHz

When the transmitter is off spurious and noise EIRP between 1500 - 1800 MHz should not exceed the
limits specified in Figure 2-4 of Chapter 2, except where specified in the following table.

Frequency Range (MHz) EIRP (dBW) Measurement Bandwidth (kHz)

960-1525 -72 100


1525-1530 -103 3
1800 - 10700 -72 100
10700-21200 -66 100
21200-40000 -60 100

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 4
Chapter 6: Technical Requirements for a Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.4.4 Spurious Outputs


As Chapter 2, Section 3.4.4 with the additional requirement that the total radiated power (excluding
harmonics) from the LMES in the following bands should not exceed the levels specified below:

Frequency Band Total Radiated Power

100 kHz – 1000 MHz –66 dBW


1000 MHz – 1626.5 MHz –60 dBW
1646.5 MHz – 4000 MHz –60 dBW

Measurement Bandwidth
Frequency Range (MHz) EIRP (dBW)
(kHz)
960 - 1530 -71 100
1530-1690 as Chapter 2, Fig. 2-4a 3
1690-3400 -71b 100
3400-10700 -65c 100
10700-21200 -59 100
21200-40000 -53 100

a In the band 1620 - 1623.5 MHz the maximum EIRP/3 kHz shall not exceed -61dBW. In the
band 1623.5 - 1626 MHz this figure shall be -61 dBW/3kHz after 1st January 1996.

b In the band 3253.0-3321.0 MHz the maximum EIRP in one, and only one, 100 kHz
measurement bandwidth shall not exceed -38 dBW. Prior to 1st January 1996 this figure shall
be -28 dBW.

c In each of the bands 4879.5-4981.5, 6506.0-6642.0 and 8132.5-8302.5 MHz the maximum
EIRP in one, and only one, 100 kHz measurement bandwidth shall not exceed -48 dBW. Prior
to 1st Jaunary 1996 this figure shall be -38 dBW. In the band 9759.0-9963.0 MHz the maximum
power in one, and only one, 100 kHz measurement bandwidth shall not exceed -59 dBW. Prior
to 1st January 1996 this figure shall be -49 dBW.

3.4.5 Harmonic Outputs


Harmonic output limits are covered by the requirements of section 3.4.4.

3.4.6 Phase Noise


The limits are as in Chapter 2, Section 3.4.6. This specification should be met under the vibration
conditions set out in Chapter 2, Section 11.2.
Under the more severe vibration conditions specified for LMESs in Section 11.2 (i) of this chapter,
consideration will be given to relaxation of the phase noise limits.

3.4.8 Frequency Accuracy and Stability


As Chapter 2, Section 3.4.8.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 5
Chapter 6: Technical Requirements for a Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4 Receiver Performance
As Chapter 2, Section 4, except performance under blockage conditions is as described in Section
4.7 below.

4.7 Performance Under Blockage Conditions

4.7.1 General
The LMES is required to comply with the performance requirements of the maritime fading channel
(Chapter 2, Sections 4.5 & 4.6). This ensures that performance of the LMES will be satisfactory in the
presence of short random fades due to blockage and multipath effects prevalent in many land mobile
channels including usage on inland waters.

Land mobile conditions also produce examples of blockage lasting from seconds to many minutes,
and additional performance checks are necessary to ensure adequate performance over the full
range of land mobile channels.

In the following sections, the precise model for blockage is defined, and performance requirements
are given for both short term repetitive blockage and long term blockage situations.

4.7.2 Channel Model For Blockage.


For the purpose of these performance requirements, the channel has two states — an un-blocked
state and a blocked state. The different channel situations are defined by assuming that the channel
switches between one state and the other in a particular time sequence.

1 Definition of un-blocked state

The "un-blocked state" of the channel is the channel as defined in Chapter 2, Section 4.4, with
the C/M ratio set to infinity, not 7dB.

2 Definition of blocked state

In the "blocked" state no signal from the satellite reaches the receiving antenna. The only input
to the receiver is the system noise from the antenna, LNA, etc.

Thus the blockage situation is defined by the power-flux density of the carrier at the antenna in the
unblocked state, and the time sequence in which the channel switches states.

4.7.3 Performance with Short Term Repetitive Blockage


Manufacturers are advised to refer to " Design Notes for Blockage Performance of Standard-C MESs
in Land Mobile Applications"; obtainable on request from INMARSAT.

For short term repetitive blockage, the time sequence is a repeating period of 8.9s containing a
blocked period of B seconds and an unblocked period of (8.9 – B) seconds.

Note that this period is slightly longer than the 8.64s signal frame and the blockage will therefore
occupy all possible positions in the frame over a period of time.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 6
Chapter 6: Technical Requirements for a Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Performance requirements for a 128 byte packet error probability PEP(128) against different values of
B seconds and unblocked power flux density at the antenna are given in the following table:

PFD for PEP(128) (dBW/m2) B = 2s B= 2.7s C/No assuming G/T = -23 dB/K

–145.5 0.1 not specified 35.0


–144.5 0.02 0.1 36.0

Note: In the performance requirements above, the value of the Doppler variation is +/–50Hz over 10s.

4.7.4 Performance with Long Term Blockage


During periods of blockage lasting up to several minutes, information will be lost. The critical
parameter used to minimise information loss is the re-acquisition time measured from the end of
blockage. For performance in single events of blockage, the relevant parameters are as follows:

1 the length of blockage, B seconds.

2 the frequency difference between the received carrier immediately prior to the start of blockage,
and at the end of blockage, 'dF' Hz.

3 the time taken between end of blockage and re-acquisition of the carrier and timing (clock
recovery), Traq seconds.

Range of blockage B Limits of dF Traq

5s to 25s +/–100Hz <1 sec.

25s to 90s +/–200Hz 4s max : 2 secs average

90s to 180s +/–500Hz 10s max : 5 secs average

Note: The above table is based on swept acquisition at 100Hz/s after the first 25s of blockage.

5 Transmitter Performance
As Chapter 2, Section 5.

6 Access Control Requirements


As Chapter 2, Section 6, except where indicated below.

6.5 Ocean Region Registration Procedures


As Chapter 2, Section 6.5 with the following exceptions.

6.5.1 Logging In
If an MES cannot tune to its preferred ocean region, it shall not automatically scan NCS common
channels. If the preferred NCS common channel is not available, the operator shall be alerted who
may then tune to another common channel or request the terminal to scan, otherwise the terminal
should continue to tune to the preferred NCS common channel.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 7
Chapter 6: Technical Requirements for a Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

7 Message Processing Requirements


As Chapter 2, Section 7.

8 Alerting Functions
Land Mobile Earth Stations are not permitted to send maritime distress alerts. Maritime
Distress Alerts must be inhibited on MESs intended for land use.

This inhibition should be implemented in the DCE, i.e. it should not be possible for any code on the
DCE/DTE interface to trigger a maritime distress alert. LMESs should not send any packet with the
packet 'priority' bit set. This applies to distress alerts and distress priority assignment requests.
However, Land Mobile terminals may optionally have the capability of sending 'Land Mobile Alerts'.
Land Mobile Alerts are defined as using the distress alerting protocol, but with the alert packet 'priority'
bit set to zero. The remaining packet format is similar to the maritime case, except some of the packet
contents are redefined for land mobile (see Volume 4, Chapter 11).

The alerting requirements detailed in Chapter 2 also apply to Land Mobile Alerting, (where this is
provided) except for the cases listed in the following sections.

Use of the Land Mobile Alerting service is generally only available to land mobile users on a pre-
arranged basis. Not all LESs will accept Land Mobile Alerts.

It is recommended that all LMESs are fitted with the Land Mobile Alerting function, but with the
capability of enabling and disabling the function at the LMES by some means not easily accessible to
the user (e.g. internal switch or secret software code). A common LMES model may then be supplied
irrespective of whether or not the alerting function is required. Supplying LMESs with the alerting
function initially disabled will discourage mobile users from attempting to send alerts where no prior
arrangements for routing or service have been made.

Note: Additionally, or as an alternative to sending Land Mobile Alerts using the 'Distress Alerting'
protocol, emergency messages may also be conveyed by Position Report. Position Reports use the
Data Reporting protocol, and are described in Volume 2.

8.1 LES Service


Land Mobile Alerts should only be sent to LESs which have the 'LES Services' field in the Bulletin
Board packet set to indicate Land Mobile service is provided (refer to Volume 4, Chapter 2, Section
3.1.4.6).

If an attempt is made to send an alert when the LES Bulletin Board indicates that no Land Mobile
Alerting service is available, a message or indication to that effect should be displayed to the mobile
user.

8.2 Signalling Channel Precedence


The use of a 'Land Mobile Alerting' bit in the Signalling Channel Descriptor (SCD) packet [previously
spare and set to zero] allows dedicated signalling channel(s) for Land Mobile Alerts if required (refer
to Volume 4, Chapter 2, Section 3.2 ).

The precedence for using these or other available channels for live Land Mobile Alerts are as follows:

1) LES dedicated Land Mobile Alerting channel(s) if available;

2) LES general signalling channels;

3) NCS dedicated Land Mobile Alerting channel(s) if available;

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 8
Chapter 6: Technical Requirements for a Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4) NCS general signalling channels.

The above categories of channel all refer to channels whose 'Land Mobile Alerting' bit have been set.
Land Mobile Alerts should not be sent on other channels.

8.3 Land Mobile Alert Generator


The Land Mobile Alert packet is as defined in Volume 4, Chapter 11. The contents are as follows:

(1) MES ID

(2) LES ID

(3) Land Position Coordinates (defined differently from maritime)

(4) A field which is set to indicate Land Mobile format

(5) A flag to indicate if following fields are user defined

(6) Nature of Alert

(7) A flag to indicate if alert has been generated automatically

(8) Time of position

(9) Speed of vehicle

(10) Direction of travel

(11) Extra Information (user defined)

Normally this information, with the possible exception of (6), would be preset or automatically
updated, but means for manual updating of (2), (3), (6), (10) and (11) may be provided.

8.4 Alert Activation


Means must be provided (mechanical and/or electrical/software) to prevent the unintentional
transmission of "live" Land Mobile alerts for all possible methods of activation.

9 Testing Functions
As Chapter 2, Section 9, with the following exceptions:

9.3 Performance Verification and Commissioning Testing


A performance verification test (PVT) is carried out as part of the commissioning procedure and at
other times to check performance. This PVT includes an alert test. For LMESs a Land Mobile Alert
(test) should be sent.

This applies irrespective of whether or not the LMES is fitted with the Land Mobile Alerting option.

The type field for this packet should be 06H ('alert test') and the packet contents should be as defined
for Land Mobile Alerts (refer to Volume 4, Chapter 11). Fields not containing valid information should
be set to zero. Note that the 'priority' bit for alert test packets should always be zero.

No distress alert test prompt shall be sent to the operator. The distress alert test shall be activated
automatically and immediately after receiving the distress test request packet from the LES.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 9
Chapter 6: Technical Requirements for a Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

A Land Mobile Alert Test sent during a PVT should follow the same procedure with respect to
signalling channel priorities as a real alert (refer to Sections 8.1 and 8.2 above), with the exception
that the 'Land Mobile Alerting' bit in the 'LES Services' field of the Bulletin Board and in the Signalling
Channel Descriptor packet need not be set for the test packet to be sent. Alert tests during PVTs
should not be sent to the NCS.

10 Electromagnetic Compatibility
As Chapter 2, Section 10.

11 Environmental Conditions

11.1 Purpose and Applicability


The following environmental conditions are based on inputs received from a number of different
countries and are intended to be indicative rather than a comprehensive set of conditions.

It is recommended that Land Mobile Earth Stations which are to be type approved for general use
comply with the performance requirements under these environmental conditions.

At the discretion of Inmarsat, LMES models may be tested to an alternative set of environmental
conditions. The MES manufacturer may propose such conditions, but these should be adequate to
confirm proper operation and performance in the environments in which the LMES is likely to be used.

In any case, the range of environmental conditions over which the LMES is designed to fulfil the
Inmarsat requirements shall be specified by the manufacturer and made known to prospective users
of the LMES model.

It should be noted that many countries and regions have their own requirements, in respect of
environmental and other testing, which may differ from those given here.

The environmental conditions for Internally Mounted Equipment (IME) generally apply to both DCE
and DTE (see Chapter 2, Section 2.2 for definition of these terms). However, where a non-dedicated
DTE (such as a portable PC) is to be supplied as part of the LMES model, alternative environmental
performance for the DTE may be acceptable. When selecting such a DTE it is strongly recommended
that particular regard is given to performance with the relatively high levels of vibration and extremes
of temperature expected in typical land mobile environments.

11.2 Recommended Environmental Conditions for a Land Mobile Earth Station


Note:

EME - Externally Mounted Equipment.

IME - Internally Mounted Equipment.

(a) Ambient Temperature: Operational: –25°C to +50°C +solar radiation (EME)

–25°C to +55°C (IME)

Survival with power on 1: –40°C to +80°C

(b) Relative Humidity: up to 95% at 40°C

(c) Ice 1: up to 25 mm of ice for EME

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 10
Chapter 6: Technical Requirements for a Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(d) Rain: 5 cm/hour, droplet size 0.5 to 4.5 mm, wind speed
as below (EME).

(e) Wind: Relative wind speeds up to 200 km/ hr (EME)

(f) Solar Radiation: (EME)

Infra-red radiation: 500W/m2

(g) Power Supply: Maximum voltage of 1.3 times nominal battery


rating. Minimum voltage of 0.9 times the nominal
battery rating. (These requirements are for a lead
acid battery, 12 or 24 volts nominal.)

Alternator whine in the form of a saw tooth wave-


form 0.2Vp-p, induced on the supply at
frequencies from 300 to 3400 Hz.

(h) Vibration : Survival1: Random vibration:

5 to 20 Hz: 0.05 g2/Hz

20 to 150 Hz: –3dB/oct. (1.7 g rms)

Vibration to be performed for a period of 2 hours


in each of 3 mutually perpendicular axes.

(i) Vibration : Operational 2 : Random vibration:

5 to 20 Hz: 0.005 g2/Hz


20 to 150 Hz: –3dB/oct. (0.5 g rms)

Performance shall not be degraded under


vibration in each of 3 mutually perpendicular
axes.

(j) Mechanical Shock 1 : Half sine wave shock with a peak of 20g and a
duration of 11 ms.

A total of 18 shocks shall be performed (3 shocks


in each of three mutually perpendicular axes).

(k) Induced Acceleration: Maximum tangential or linear acceleration of up to


2 g.

(l) Velocity: Maximum velocity up to 140 km/hr.

(m) Vehicle Motion: [TBD] Relevant only for steered antennas.

Note 1 : Indicates survival recommendations only. The MES is NOT expected to operate within
specification under these conditions, but the MES performance after they are removed
should not be degraded.

Note 2 : See Section 3.4.6.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 11
Chapter 6: Technical Requirements for a Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(n) Antenna Inclinations: Not specified.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 12
Chapter 6: Technical Requirements for a Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 7: Technical Requirements for a Land-


Based Portable Earth Station

Contents

1 Introduction ............................................................................ 3

2 General Requirements ............................................................. 3


2.1 Inmarsat-C Land-Based Portable Earth Station Definition ................................3
2.2 Mandatory Capabilities......................................................................................3

3 RF Subsystem Requirements ................................................... 3


3.2 Antenna Requirements .....................................................................................3
3.2.1 Gain ...............................................................................................................3
3.2.4 Sidelobes .......................................................................................................3
3.2.5 Antenna Pointing ............................................................................................4
3.2.6 Maximum Antenna Pointing Error ..................................................................4
3.2.7 Satellite Acquisition ........................................................................................4
3.3 Receiver RF Requirements ...............................................................................4
3.3.1 Gain-to-Noise Temperature Ratio ..................................................................4
3.3.3 Immunity to Out of Band Signals ....................................................................4
3.4 Transmitter RF Requirements ...........................................................................5
3.4.1 EIRP...............................................................................................................5
3.4.3 Transmitter Off Power Level ..........................................................................5
3.4.4 Spurious Outputs ...........................................................................................5
3.4.5 Harmonic Outputs ..........................................................................................6

4 Receiver Performance ............................................................. 6

5 Transmitter Performance ......................................................... 6

6 Access Control Requirements ................................................. 6


6.3.4 Spot Beam Operation.....................................................................................6
6.5 Ocean Region Registration Procedures ............................................................6

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 1
Chapter 7: Technical Requirements for a Land-Based Portable Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6.5.1 Logging In ......................................................................................................6

7 Message Processing Requirements ......................................... 7

8 Alerting Functions .................................................................. 7

9 Testing Functions ................................................................... 7


9.1 Performance Verification Testing ......................................................................7

10 Electromagnetic Compatibility ............................................... 7

11 Environmental Conditions ..................................................... 7


11.2 Recommended Environmental Conditions For An LPES ................................7

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 2
Chapter 7: Technical Requirements for a Land-Based Portable Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
This chapter describes the requirements and recommendations for a Land-based Portable Earth
Station (LPES), which is an earth station which is operated from a stationary position rather than
being mounted in a vehicle. An LPES may be transported from site to site or may be used as a fixed
station.

The characteristics of an LPES are generally the same as those of a Mobile Earth Station as
described in Chapter 2 of this volume. The purpose of this chapter is to point out the differences that
are applicable for land based portable equipment. The numbering of sections in this chapter follow
those of Chapter 2 and where a section of Chapter 2 is not mentioned, it must be assumed that the
original Chapter 2 requirement still applies.

It should not be assumed that this document covers any national or regional requirements, which may
have to be met in addition to those referred to here.

2 General Requirements

2.1 Inmarsat-C Land-Based Portable Earth Station Definition


As Chapter 2, Section 2.2.

2.2 Mandatory Capabilities

As Chapter 2, Section 2.4.*

Chapter 2, Section 2.4, items relating to EGC messages, are applicable to Class 2 and Class 3
LPESs, but only for reception of FleetNETSM messages; that is, reception of SafetyNETSM is not
mandatory. Class 2 and Class 3 LPESs should be capable of receiving EGC messages which are not
classified as either SafetyNETSM or FleetNETSM, namely 'General Call' and 'INMARSAT System
message', but reception of such messages may be inhibited by the user.

3 RF Subsystem Requirements
As Chapter 2, Section 3, except where indicated below.

3.2 Antenna Requirements


For LPESs equipped with a directional antenna the requirements specified in the following paragraphs
shall be met (see Chapter 2, Section 3.2).

3.2.1 Gain
The effective gain at both the receive and transmit frequencies shall be such that the specified G/T
and EIRP requirements are satisfied (see Chapter 2, Sections 3.3.1 and 3.4.1 respectively). The
effective gain means antenna gain including pointing error.

3.2.4 Sidelobes
It is recommended that the sidelobe levels are suppressed sufficiently to prevent false satellite
acquisition.

*It is permissible to provide only optional services; that is, polling and data reporting or a subset of the
mandatory capabilities of Chapter 2, Section 2.4.
Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 3
Chapter 7: Technical Requirements for a Land-Based Portable Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.2.5 Antenna Pointing


All LPESs shall meet the requirements for G/T and EIRP (given in Chapter 2, Sections 3.3.1 to 3.4.1)
for satellite elevation angles 5° to 90° relative to the horizon and for 360° in azimuth. The antenna
pointing method can be either manual, automatic, or a combination of both.

3.2.6 Maximum Antenna Pointing Error


The nominal boresight shall be pointed to the satellite such that the overall pointing error, under all
environmental conditions, shall not degrade the G/T and EIRP requirements as specified in Chapter 2,
Sections 3.3.1 and 3.4.1.

3.2.7 Satellite Acquisition


LPESs shall have provision for indicating the Satellite Acquisition without any ambiguity; that is, by
means of a signal level indicator.

3.3 Receiver RF Requirements


As Chapter 2, Section 3.3, except where indicated below.

The receiver RF requirements specified below are applicable for LPESs equipped with a directional
antenna. For omni-directional (in the azimuth plane) antenna, the receiver RF requirements specified
in Section 3.3 of Chapter 2 shall be applicable.

3.3.1 Gain-to-Noise Temperature Ratio


The overall LPES RF equipment receiving system gain-to-temperature ratio (G/T) shall be equal to or
greater than –23 dB/K in the direction of the satellite, under the following conditions:

(i) clear sky climatic conditions;

(ii) sky at elevations greater than 0°, and ground (black body at 300K) at elevations less than 0°;

(iii) antenna boresight elevation angle equal to 5° (for the purpose of antenna noise temperature
measurement)* ;

(iv) with residual antenna pointing errors;

(v) including the noise contribution of the receiver low noise amplifier;

(vi) including the loss introduced by a dry radome, where a radome is fitted, or any other covering
surface on top of the radiating element;

(vii) environmental conditions for which the LPES is to be Type Approved (see Section 11.1);

(viii) with the transmitter at the specified "off" level (see Section 3.4.3 of Chapter 2);

3.3.3 Immunity to Out of Band Signals


The operation or performance of the receiver shall not be impaired by a continuous wave carrier at
any frequency within the range 100 kHz to 1400 MHz and 1626.5 MHz to 4000 MHz, and at a flux
density level of –45 dBW/m2 at the receiver antenna, with the antenna oriented for maximum signal.

* As an alternative to measuring the antenna noise temperature under these conditions, it may
be assumed that the external antenna noise temperature (excluding antenna losses) is 300K.
Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 4
Chapter 7: Technical Requirements for a Land-Based Portable Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Consideration will be given to relaxing this requirement for the special case of receiver image
response, providing that the image band lies at a frequency unlikely to contain interfering signals at
such a level as to increase the packet error probability. As a guide it is recommended that the image
rejection should not be less than 60 dB. Where doubt exists, the higher limit of –45 dBW/m2 shall
apply.

3.4 Transmitter RF Requirements


As Chapter 2, Section 3.4, except where indicated below.

The transmitter RF requirements specified below are applicable for LPESs equipped with a directional
antenna. For an omni-directional antenna (in the azimuth plane) the transmitter RF requirements
specified in Section 3.4 of Chapter 2 shall be applicable.

3.4.1 EIRP
The EIRP of LPESs shall not be less than +12 dBW in the direction of the satellite.

The maximum EIRP radiated by LPESs in any direction shall not exceed +16 dBW. The variation in
EIRP, including environmental, shall be such as to maintain the EIRP towards the satellite within
these specified limits under all operational conditions.

3.4.3 Transmitter Off Power Level


In addition to the requirements of Chapter 2, Section 3.4.3, when the LPES is not transmitting, the
spurious and noise EIRP between 1500 - 1800 MHz should not exceed the limits specified in Figure 4
of Chapter 2, except where specified in the following table.

Frequency Range (MHz) EIRP (dBW) Measurement Bandwidth (kHz)

960-1500 -72 100


1525-1530 -103 3
1800 - 10700 -72 100
10700-21200 -66 100
21200-40000 -60 100

3.4.4 Spurious Outputs


The spurious and noise output EIRP in the direction of the satellite shall fall below the limits given in
the following table:

Frequency Range (MHz) EIRP (dBW) Measurement Bandwidth (kHz)

960 - 1525 -71 100


1525-1600 -86 3
1600-1690 as Figure 4a 3

1690-3400 -71b 100

3400-10700 -65c 100


10700-21200 -59 100

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 5
Chapter 7: Technical Requirements for a Land-Based Portable Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

21200-40000 -53 100

a In the band 1620-1623.5 MHz the maximum EIRP/3kHz shall not exceed -61dBW. In the band
1623.5 - 1626 this figure shall be -61dBW/3kHz after 1st January 1996.

b In the band 3253.0-3321.0 MHz the maximum EIRP in one, and only one, 100 kHz measurement
bandwidth shall not exceed -38 dBW. Prior to 1st January 1996 this figure shall be -28 dBW.

c In each of the bands 4879.5-4981.5, 6506.0-6642.0 and 8132.5-8302.5 MHz the maximum EIRP in
one, and only one, 100 kHz measurement bandwidth shall not exceed -48 dBW. Prior to 1st Jaunary
1996 this figure shall be -38 dBW. In the band 9759.0-9963.0 MHz the maximum power in one, and
only one, 100 kHz measurement bandwidth shall not exceed -59 dBW. Prior to 1st January 1996 this
figure shall be -49 dBW.

In addition the total radiated power (excluding harmonics) from the LPES in the following bands
should not exceed the levels specified below:

Frequency Band Total Radiated Power


100 kHz – 1000 MHz –66 dBW
1000 MHz – 1626.5 MHz –60 dBW
1646.5 MHz – 4000 MHz –60 dBW

3.4.5 Harmonic Outputs


Harmonic output limits are covered by the requirements of section 3.4.4.

4 Receiver Performance
As Chapter 2, with the exception that in 4.4 (d), short term Doppler frequency variations need not be
included. Furthermore, for LPESs having directional antennas with an effective gain of not less than
6 dBi, the C/M ratio specified in (g) shall be relaxed to 10 dB.

5 Transmitter Performance
As Chapter 2, Section 5.

6 Access Control Requirements


As Chapter 2, Section 6, except where indicated below.

6.3.4 Spot Beam Operation


LPESs are not required to scan.

6.5 Ocean Region Registration Procedures


As Chapter 2, Section 6.5, with the following exceptions:

6.5.1 Logging In
If an LPES cannot tune to its preferred ocean region, it may not automatically scan NCS common
channels. If the preferred NCS common channel is not available, the operator shall be alerted. The

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 6
Chapter 7: Technical Requirements for a Land-Based Portable Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

operator may then tune to another common channel or request the terminal to scan, otherwise the
terminal should continue to tune to the preferred NCS common channel.

7 Message Processing Requirements


As Chapter 2, Section 7.

For remote, unmanned LPESs the requirements relating to the DTE message display (Chapter 2,
Section 7.3.1), keyboard (Chapter 2, Section 7.4), message storage (Chapter 2, Section 7.5.1) may
not be applicable.

8 Alerting Functions
Land Based Portable Earth Stations are not permitted to send maritime distress alerts.
Maritime distress alerts must be inhibited on LPESs.

This inhibition should be implemented in the DCE: that is, it should not be possible for any code on
the DCE/DTE interface to trigger a maritime distress alert. LPESs should not send any packet with the
packet 'priority' bit set. This applies to distress alerts and distress priority assignment requests. LPESs
may optionally provide Land Mobile alerting as described in Chapter 6, Section 8. The normal case for
LPESs, however, would be for no alerting facilities to be provided. If the alerting facilities are provided
then the same protocol procedures as described for the Land Mobile Alerting should be followed.

9 Testing Functions
As Chapter 2, Section 9.

9.1 Performance Verification Testing

As Chapter 6.*

10 Electromagnetic Compatibility
As Chapter 2.

11 Environmental Conditions
As Chapter 2, Section 11.2, except where indicated below.

11.2 Recommended Environmental Conditions For An LPES

(a) Survival with power on1: –40°C to +80°C

(b) Relative Humidity: up to 95% at 40°C

(c) Ice1: up to 25mm of ice (EME)

* LPESs not supporting the store and forward messaging protocols are not required to perform PVTs.

1 The LPES is NOT expected to operate within specification under these conditions, but the
LPES performance after the conditions are removed should not be degraded.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 7
Chapter 7: Technical Requirements for a Land-Based Portable Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(d) Rain : 5 cm/hour, droplet size 0.5 to 4.5 mm, wind speed as
below (EME).

(e) Wind : Relative wind speeds up to 200 km/ hr (EME).

(f) Solar Radiation: As Chapter 2.

(g) As Chapter 2, Section 11.2 with the following addition for battery operated equipment:

Power Supply: Maximum voltage of 1.3 times nominal battery rating.

Minimum voltage of 0.9 times the nominal battery


rating.

(h) Vibration: Survival1 [TBD]2

2 The LPES is NOT expected to operate within specification under these conditions, but the
LPES performance after the conditions are removed should not be degraded.
Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 8
Chapter 7: Technical Requirements for a Land-Based Portable Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 8: Technical Requirements for an Enhanced


Group Call Receiver
Contents

0 Scope ..................................................................................... 3

1 Introduction ............................................................................ 3
1.1 Enhanced Group Calls ......................................................................................3
1.2 EGC Receiver ...................................................................................................4
1.3 System Definition Documentation .....................................................................4
1.4 Type Approval ...................................................................................................4
Figure 1: Classes of Mobile Earth Stations .............................................................5
Figure 2: EGC Receiver ..........................................................................................6

2 General Requirements ............................................................. 6


2.1 Mandatory Capabilities......................................................................................6
2.2 Optional Capabilities .........................................................................................6

3 RF Subsystem Requirements ................................................... 6


3.1 General .............................................................................................................6

4 Receiver Performance ............................................................. 7


4.3 Receiver Selectivity ...........................................................................................7
4.4 Demodulator Performance ................................................................................7
4.5 Output Performance ..........................................................................................7

5 Transmitter Performance ......................................................... 7

6 Access Control Requirements ................................................. 8


6.3 NCS Common Channel Selection .....................................................................8
6.3.1 General ..........................................................................................................8

7 Message Processing Requirements ......................................... 8


7.1 General .............................................................................................................8

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 1
Chapter 8: Technical Requirements for an Enhanced Group Call Receiver
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

7.2 Character Codes ...............................................................................................9


7.3 Display Devices ................................................................................................9
7.3.1 Message Display ............................................................................................9
7.3.2 Status Display ................................................................................................9
7.4 Keyboard...........................................................................................................9
7.4.1 Operator Controls ..........................................................................................9
7.5 EGC Receiver Memory Capacity Requirements ...............................................9
7.5.1 Message Buffer ............................................................................................ 10
7.5.2 Non-Volatile Memory.................................................................................... 10
7.6 The DTE-DCE interface .................................................................................. 10
7.7 EGC Receiver Addressing .............................................................................. 10
7.7.4 Message Sequencing................................................................................... 10
7.7.5 Error Detection ............................................................................................. 10

8 Distress Calling .................................................................... 11

9 Testing Functions ................................................................. 11

10 Electromagnetic Compatibility ............................................. 11

11 Environmental Conditions ................................................... 11


11.1 Purpose......................................................................................................... 11

12 Optional Features ................................................................ 11


12.1 Reception of SafetyNET SM;; or FleetNET SM;; Service only .............................. 11

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 2
Chapter 8: Technical Requirements for an Enhanced Group Call Receiver
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

0 Scope
Chapter 8 of Volume 3, Part 2 which describes the general requirements for EGC receivers is
supported by Annex A, Annex B and Annex C, "SafetyNETSM EGC receivers for use in SOLAS
installations", "SafetyNETSM receivers for use on Non-SOLAS" vessels and "FleetNETSM receivers",
respectively.

Annex A: SafetyNETSM Receiver for SOLAS Vessels

An EGC receiver designed to receive SafetyNETSM (and optionally FleetNETSM) broadcasts in a


SOLAS installation on board a SOLAS vessel. SafetyNETSM receivers for use in the GMDSS comply
fully with the technical requirements of IMO and IEC.

Annex B: SafetyNETSM Receiver for Non-SOLAS Vessels

An EGC receiver designed to receive SafetyNETSM(and optionally FleetNETSM) broadcasts on board


non-regulated (Non-SOLAS) vessels. In general, Non-SOLAS SafetyNETSM receivers are required to
process SafetyNETSM messages in exactly the same way as the SOLAS SafetyNETSM receivers.

Inmarsat does not require Non-SOLAS EGC receivers to comply with the electromagnetic
compatibility (EMC) or environmental requirements specified by IMO/IEC.

Annex C: FleetNETSM Receiver

An EGC receiver designed to receive FleetNETSM transmissions. FleetNETSM receivers may be


designed for use on land or at sea but in the latter case, they must comply with the electromagnetic
compatibility and environmental requirements appropriate to the application, e.g a FleetNETSM
receiver for use in a SOLAS installation, must comply with the electromagnetic and environmental
specifications applicable to SOLAS SESs.

The following table gives a guide to the different sets of specifications for EGC receivers:

SOLAS (IEC 945) Non-SOLAS Land Mobile

Chapter 5, Annex A and Chapter 5 and


SafetyNETSM N/A
Chapter 8, Annex A Chapter 8, Annex B
Chapter 5, Annex A and Chapter 5 and Chapter 2 and
FleetNETSM
Chapter 8 Annex C Chapter 8 Annex C Chapter 8, Annex C

1 Introduction

1.1 Enhanced Group Calls


Enhanced Group Calls (EGC) are broadcast messages transmitted over the Inmarsat-C
Communications System. The service It allows terrestrial information providers to pass messages or
data to mobile EGC receivers and Class 2 or Class 3 MESs.

EGC messages are sent to Land Earth Stations by Information Providers using terrestrial facilities
such as Telex. The messages are processed at the LESs, and forwarded to an NCS which transmits
them on an NCS common channel.

In addition to Inmarsat system messages and other services, there are two primary services offered
by EGC; the SafetyNETSM service and the FleetNETSM service. SafetyNETSM is a service provided in
the GMDSS for the dissemination of maritime safety information, such as navigational warnings,
meteorological warnings and forecasts, and other urgent safety related information. FleetNETSM is a

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 3
Chapter 8: Technical Requirements for an Enhanced Group Call Receiver
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

commercial communication service allowing terrestrial information providers to send messages to pre-
defined groups of subscribers.

Both the SafetyNETSM and FleetNETSM services make use of flexible addressing techniques to allow
the reception of messages from a variety of service providers depending on the particular
requirements of the user. The SafetyNETSM service utilizes a geographical area addressing technique
to direct messages to MESs within a defined boundary. SafetyNETSM is not generally used to send
messages to individual receivers. The FleetNETSM service employs closed user group and unique
receiver addressing to provide secure transmission of messages from the terrestrial information
provider to the desired service recipient(s).

1.2 EGC Receiver


An EGC receiver is defined as a single channel receiver with a dedicated message processor. MES
Classes 2 and 3 provide an EGC capability in addition to To-Mobile and From-Mobile messaging
capabilities as indicated in Figure 1 and defined in Chapter 2, Section 2.1. Class 0 MESs are self
contained EGC receivers as shown in Figure 2.

1.3 System Definition Documentation


This chapter defines the mandatory requirements for reception and processing of SafetyNETSM and
FleetNETSM messages transmitted on an NCS common channel. Its purpose is to ensure that all EGC
receivers provide adequate performance for the intended application.

Designers of EGC receivers should familiarize themselves with the other chapters of this volume and
with other appropriate system definition documentation (see Chapter 1).

1.4 Type Approval


This document presents the technical requirements and recommendations for an Enhanced Group
Call (EGC) receiver. These requirements must be satisfied before the equipment can be utilized in the
Inmarsat system. Procedures for type approval by Inmarsat of a manufacturer's design are provided
in a complementary document entitled "Type Approval Procedures for Inmarsat-C Mobile Earth
Stations".

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 4
Chapter 8: Technical Requirements for an Enhanced Group Call Receiver
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: Classes of Mobile Earth Stations

Inm-C

transmitter receiver

Class 1 (no EGC)


message
processor

Inm-C

transmitter receiver

Class 2
message EGC message
processor processor

Inm-C

EGC
transmitter receiver
receiver

Class 3
message EGC message
processor processor

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 5
Chapter 8: Technical Requirements for an Enhanced Group Call Receiver
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 2: EGC Receiver

Inm-C

EGC receiver

EGC message
processor

Class 0: stand-alone EGC receiver

2 General Requirements

2.1 Mandatory Capabilities


The mandatory capabilities of an EGC receiver are:

(a) Continuous reception of an NCS common channel and processing of the information according
to the EGC message protocol;

(b) Automatic recognition of messages directed to fixed and absolute geographical areas and
service codes as selected by the receiver operator;

2.2 Optional Capabilities


Additional optional capabilities required for reception of FleetNETSM service broadcasts are:

(a) Automatic recognition of uniquely addressed messages directed to a particular EGC receiver;

(b) Automatic recognition of messages directed to a group to which the receiver operator
subscribes;

(c) Automatic response to group ID updates directed to that EGC receiver, adding or deleting
group IDs as commanded.

3 RF Subsystem Requirements

3.1 General
The antenna and receiver requirements of Chapter 2 are applicable to a stand alone EGC receiver or
an EGC receiver integrated with a Class 2 or Class 3 MES. The applicable sections are:

Section Title

- 3.2 Antenna Requirements, Gain and Polarization

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 6
Chapter 8: Technical Requirements for an Enhanced Group Call Receiver
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

- 3.3.1 Gain-to-Noise Temperature Ratio

- 3.3.2 Received Signal Levels

- 3.3.3 Immunity to Out of Band Signals

- 3.3.4 Receiver Tuning

4 Receiver Performance
The signal modulation and channel characteristics are identical to those presented in Chapter 2,
Sections 4.1 and 4.2.

4.3 Receiver Selectivity


As Chapter 2, Section 4.3.

4.4 Demodulator Performance


As Chapter 2, Section 4.4.

4.5 Output Performance


The continuous reception output performance shall be measured in terms of the packet error
probability (PEP). This is defined as:

PEP = (Total packets transmitted – Total packets received correctly)


Total packets transmitted

The limits for the maximum acceptable PEP for a range of equivalent unfaded power flux densities
(PFD) at the antenna are as follows:

PFD PEP PEP


(dBW/m2) (128 byte packet) (48 byte packet)
–146.5 0.080 0.027
–146.0 0.040 0.014
–145.5 0.020 0.007
–145.0 0.012 0.004
–144.5 0.004 0.002

Note: The power flux densities are assumed to be pure RHCP (0 dB axial ratio) at the antenna and
correspond to the demodulator input C/Nos given in Volume 1, Chapter 3, Table 6 assuming a
receiver system G/T of –23 dB/K and 5° satellite elevation.

5 Transmitter Performance
The requirements relating to this section of Chapter 2 are not applicable to EGC receivers.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 7
Chapter 8: Technical Requirements for an Enhanced Group Call Receiver
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6 Access Control Requirements


The requirements relating to these sections of Chapter 2 are not applicable to EGC receivers with the
exception of the following:

6.3 NCS Common Channel Selection

6.3.1 General
EGC receivers shall be equipped with facilities for storing up to 20 NCS channel numbers. Four of
these will be permanently assigned global beam frequencies as follows:

NCS NCS Common Channel

Channel No. Frequency

AOR (West) 11080 1537.70 MHz


AOR (East) 12580 1541.45 MHz
POR 12580 1541.45 MHz
IOR 10840 1537.10 MHz
Spare 11088 1537.72 MHz

These four Channel numbers shall be stored in ROM and shall not be alterable.

The spare Common channel will be transmitted in the event of interference on the nominated
frequency.

The remaining list of up to 16 valid NCS common channel frequencies will be published by Inmarsat
and will be assigned as expansion common channels. These shall be held in non-volatile, but
alterable storage and be capable of operator alteration in the event that Inmarsat decides to update
the frequency plan by adding, deleting or changing allocations.

7 Message Processing Requirements


The requirements of this section may be amended to comply with future recommendations of the IMO.

7.1 General
This Section describes the requirements and recommendations for the message processing
subsystem of the EGC receiver.

Message processing will be based on the header field described in Volume 4, Chapter 3 and in Part
1, Chapter 2, Section 9 in this volume.

For messages with a double header, the two packets must be regarded as a single message and
shall be treated in exactly the same manner as the individual packets of single header messages.

Messages shall not be printed until completely received, even in the case of multi-packet messages.

Note: The NCS may multiplex the packets of different EGC messages on the Common Channel.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 8
Chapter 8: Technical Requirements for an Enhanced Group Call Receiver
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Therefore it is possible for one or more messages to be interleaved and be addressed to a


particular EGC receiver. It is recommended that EGC receivers be capable of receiving and
processing at least four interleaved messages simultaneously.

7.2 Character Codes


For the EGC service, the International Reference Version of International Alphabet 5 (IA5) as defined
in CCITT Red Book Recommendation T.50, is used. Characters are coded as eight bits using odd
parity. Other character sets conforming to ISO 2022 or CCITT Red Book Recommendation T.61 are
used optionally for certain services.

It is recommended that EGC equipment capable of receiving messages composed using International
Telegraph Alphabet No. 2 (ITA2) do not make use of national options for character Nos. 6, 7 and 8 in
figure case to avoid varying interpretations in the international Inmarsat-C system (see CCITT
Recommendation S.1, §4.2).

7.3 Display Devices

7.3.1 Message Display


It is recommended that the EGC receiver has a printer.

The display, or printer if fitted, shall be capable of presenting at least 40 characters per line of text.
The EGC receiver should ensure that if a word cannot be accommodated in full on one line it shall be
transferred to the next line.

7.3.2 Status Display


For receive only EGC receivers, indication of EGC carrier frame synchronisation (or loss of
synchronisation) is required as a minimum.

7.4 Keyboard
Where a keyboard is fitted the requirements of Chapter 2 shall apply.

7.4.1 Operator Controls


The following control functions and displays shall be provided as a minimum:

(a) selection of EGC carrier frequency (see Section 6.3);

(b) means of inputting the following information:

(i) mobile's position coordinates;

7.5 EGC Receiver Memory Capacity Requirements


Both temporary and non-volatile memory is required in an EGC receiver for the following purposes:

(i) message buffering;

(ii) maintaining message identification records;

(iii) storing position coordinates and Navarea geographical area data; and

(iv) for storing expansion NCS common channel numbers.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 9
Chapter 8: Technical Requirements for an Enhanced Group Call Receiver
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

7.5.1 Message Buffer


A message buffer memory with a capacity of not less than 32768 bytes shall be provided.

7.5.2 Non-Volatile Memory


EGC receivers shall use non-volatile memory for storing ENIDs and expansion NCS common channel
numbers. 16 NCS common channel numbers in non-volatile memory shall be available.

The non-volatile memory should be capable of retaining the stored data for a minimum of six months
under the applicable environmental conditions and in the absence of applied primary power.

7.6 The DTE-DCE interface


The requirements relating to the DTE-DCE interface may not be applicable to receive only EGC
receivers.

7.7 EGC Receiver Addressing


The five basic methods of addressing EGC receivers are:

(i) All mobiles call;

(ii) Inmarsat System Message Addressing;

(iii) Group addressing (Annex C);

(iv) Unique addressing (Annex C); and

(v) Geographical Area addressing (Annex A and B).

The type of address used in the header of an EGC packet is uniquely determined by the service code
field.

7.7.4 Message Sequencing


All messages will be transmitted with a unique sequence number and the originating LES ID. Each
subsequent transmission of the message will contain the original sequence number. This facility
allows multiple printing of repeated messages to be inhibited.

When a message has been received error free, and a permanent record made, the unique 16 bit
sequence number, the LES identifier and the service code field associated with that message may be
stored in memory and the information used to inhibit the printing of repeated transmissions of the
same message.

If the printing of repeated messages is to be inhibited, the EGC receiver should be capable of
internally storing at least 255 such message identifications. These message identifications should be
stored with an indication of the number of hours that have elapsed since the message has been
received. Subsequent reception of the same message identification shall reset this timer. After
between 60 and 72 hours, message identifications may be automatically erased. If the number of
received message identifications exceeds the capacity of memory allocated for the store, the oldest
message identification may be erased.

7.7.5 Error Detection


The EGC message will employ three levels of error detection:

(i) an arithmetical checksum is used to detect packet errors;

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 10
Chapter 8: Technical Requirements for an Enhanced Group Call Receiver
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(ii) an arithmetical checksum is used to detect header errors; and

(iii) parity checking is used to indicate character errors in the information field.

Only packets with header fields received without error shall be processed for local message recording
(even if the packet itself contains an error). In the case of double header messages, the message
may be processed even if only one header has been received correctly. A parity check on all
incoming characters shall be performed and in the event of a parity error in a received character, the
"low line" character (5/15 in T.50) shall be displayed and/or printed.

Outputs for multi-packet messages which have been received incomplete should provide a positive
indication of the position of the missed packet(s). If further packets of an EGC message are expected
but none are received after waiting for three frames, the EGC message should be assumed to be
completed: this is to guard against the possibility of the last packet of an EGC message not being
received. The MES should return to the idle state and indicate that one or more packets of the EGC
message are missing.

8 Distress Calling
Not applicable.

9 Testing Functions
It is recommended that all receivers should have some self testing capability. Means should also be
provided for demonstrating that the receiver is functioning correctly and alerting the operator in the
event of a malfunction.

It is recommended that in common with MESs, EGC receivers should utilize the received carrier
bulletin board error rate as a measure of link performance (see Chapter 2, Section 9.2).

10 Electromagnetic Compatibility
As a minimum the electromagnetic compatibility requirements of Chapter 2, Section 10 are mandatory
for an EGC receiver.

11 Environmental Conditions

11.1 Purpose
Environmental conditions for each type of EGC receiver are given in the appropriate Chapter, Annex,
see table on page 8-6.

12 Optional Features

12.1 Reception of SafetyNET SM;; or FleetNET SM;; Service only


Manufacturers may choose to produce EGC receivers capable of receiving either the SafetyNETSM
service or the FleetNETSM service only.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 11
Chapter 8: Technical Requirements for an Enhanced Group Call Receiver
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 8 - Annex A: Technical Requirements for a


SafetyNETSM Receiver for SOLAS SESs

Contents

1 SafetyNETSM Receiver for SOLAS Installations .......................... 3


1.1 Background .......................................................................................................3
1.2 Principal Relevant Documents ..........................................................................3

2 General Requirements ............................................................. 4


2.1 Mandatory Capabilities......................................................................................4

3 RF Subsystem Requirements ................................................... 4


3.1 General .............................................................................................................4

4 Receiver Performance ............................................................. 4

5 Transmitter Performance ......................................................... 4

6 Access Control Requirements ................................................. 5


6.3.2 NCS Scanning ...............................................................................................5

7 Message Processing Requirements ......................................... 5


7.1 General .............................................................................................................5
7.3.1.1 Maritime Mobile ...................................................................................................................... 5

7.4 Operator Controls .............................................................................................5


7.5.2 Non-Volatile Memory......................................................................................6
7.7.3 Geographical Area Addressing ......................................................................6
7.7.4 Message Identification ...................................................................................6
7.7.4.1 Maritime Requirements .......................................................................................................... 6

7.7.5 Error Detection ...............................................................................................7


7.7.6 Distress / Urgency Call Alarm ........................................................................7

8 Distress Calling ...................................................................... 7

9 Testing Functions ................................................................... 7


Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 1
Chapter 8 - Annex A: Technical Requirements for a SafetyNETSM Receiver for
SOLAS SESs
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

9.1 Link Performance Monitoring ............................................................................7


9.2 Alarms and Indications ......................................................................................8
9.2.1 Distress / Urgency Alarms..............................................................................8
9.2.2 Other Alarms and Indications .........................................................................8

10 Electromagnetic Compatibility ............................................... 8

11 Environmental Conditions ..................................................... 8


11.1 Purpose...........................................................................................................8

12 Optional Features .................................................................. 8


12.1 Reception of SAFETYNETSM or FLEETNETSM Service Only .............................8
12.2 Navigational Interface .....................................................................................9

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 2
Chapter 8 - Annex A: Technical Requirements for a SafetyNETSM Receiver for
SOLAS SESs
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 SafetyNETSM Receiver for SOLAS Installations

1.1 Background
The Global Maritime Distress and Safety System (GMDSS) is a new and efficient
radiocommunications system based on satellite and terrestrial technology, designed to improve
communications relating to distress and the safety of life at sea. It was adopted by the International
Maritime Organization (IMO) in 1988, in the form of Amendments to the International Convention for the
Safety of Life at Sea (SOLAS), 1974 and came into effect on 1 February 1992. Completion of
implementation is scheduled for 1 February 1999.

It is the responsibility of National Administrations to determine whether a radio installation on board a


ship meets the SOLAS requirements. This is done by National Type Acceptance or Approval testing
of the sub-systems included in the installation and by inspection of the complete installation by a radio
surveyor.

National Type Acceptance testing for SOLAS equipment will usually be based on GMDSS
specifications and procedures prepared by the IMO and the International Electrotechnical
Commission (IEC) on their behalf, although other national or regional specifications may be invoked
as well.

The major IMO and IEC documents, which are identified in Section 1.2, not only summarise the
general requirements for GMDSS equipment, but also the special requirements for SafetyNETSM EGC
receivers for use in SOLAS installations, as specified by IMO/IEC.

To the extent possible, the technical requirements for SafetyNETSM EGC receivers for use in SOLAS
installations have been harmonised with the above mentioned specifications, and conflicts between
the documents should not arise. A number of the Inmarsat specifications have been completely
revised to reflect the latest IMO/IEC requirements, for example, the electro-magnetic compatibility and
environmental requirements. However, manufacturers should note that it has not been possible to
incorporate all of the IMO/IEC technical requirements, and reference must be made to the latest
issues of the documents listed overleaf (and any other relevant GMDSS documents), when designing
new SafetyNETSM EGC equipment for use on SOLAS ships. This will facilitate the passing of National
Type Acceptance testing, should this be required.

1.2 Principal Relevant Documents


For Inmarsat-C and EGC GMDSS SESs, the principal relevant documents in addition to the Inmarsat-
C SDM are:

i) "General Requirements for Shipborne Radio Equipment Forming Part of the Global Maritime
Distress and Safety System (GMDSS) and for Electronic Navigational Aids", published by the
IMO as Resolution A.694(17).

ii) "Performance Standards for Inmarsat Standard-C Ship Earth Stations Capable of Transmitting
and Receiving Direct-printing Communications-

Annex: Recommendations on Performance Standards for Inmarsat Standard-C Ship Earth


Stations Capable of Transmitting and Receiving Direct-printing Communications", published by
the IMO as Resolution A.663(16).

iii) "Performance Standards for Enhanced Group Call Equipment Communications-

Annex: Recommendations on Performance Standards for Enhanced Group Call Equipment",


published by the IMO as Resolution A.664(16).

iv) "Shipborne Radio Equipment Forming Part of the Global Maritime Distress and Safety System
and Marine Navigational Equipment", published by the IEC as IEC 945.
Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 3
Chapter 8 - Annex A: Technical Requirements for a SafetyNETSM Receiver for
SOLAS SESs
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

v) "Global Maritime Distress and Safety System (GMDSS), IEC 1097-4 - Part 4: Inmarsat-C Ship
Earth Station and Inmarsat-EGC (Enhanced Group Call) Equipment. Performance Standards,
Methods of Testing and Required Test Results", published by the IEC as IEC 1097-4 -Part 4.

The above mentioned documents may be obtained from the relevant authorities, whose
addresses are given below:

IMO IEC

International Maritime Organization International Electrotechnical Commission


4 Albert Embankment 3 Rue de Varembe
London P O Box 131,
SE1 7SR 1211 Geneva 20
United Kingdom Switzerland
Tel: +44 (0)71-735 7611 Tel: +41 (0)22 7340150
Fax: +44 (0)71-587 3210 Fax: +41 (0)22 7333843
Telex: 23588

2 General Requirements

2.1 Mandatory Capabilities


The mandatory capabilities of SafetyNETSM receivers for SOLAS applications are:

(a) Continuous reception of an NCS common channel and processing of the information according
to the EGC message protocol; A Class 2 Inmarsat-C SES shall continuously receive the NCS
common channel when not engaged in general communications;

(b) Automatic recognition of messages directed to fixed and absolute geographical areas and
service codes as selected by the receiver operator or by navigation equipment.

(c) SafetyNETSM receivers shall meet the requirements of IEC 1097-4 and IEC 945; and

(d) Provision shall be made for a visual indication that the ship's position has not been updated
during the last 12 hours. It shall only be possible to reset this indication by revalidating the
ship's position.

3 RF Subsystem Requirements

3.1 General
Same as Chapter 8

4 Receiver Performance
Same as Chapter 8.

5 Transmitter Performance
Not applicable.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 4
Chapter 8 - Annex A: Technical Requirements for a SafetyNETSM Receiver for
SOLAS SESs
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6 Access Control Requirements


Same as requirements of Chapter 8 with following addition:

6.3.2 NCS Scanning


Automatic NCS scanning, either as a result of high BBER, or on a regular basis, is prohibited in
SOLAS SafetyNETSM receivers. Instead, when the BBER is 80% or more out of the last hundred
received bulletin board packets, an alarm shall be raised and the operator advised to initiate NCS
scanning manually.

7 Message Processing Requirements


Same as Chapter 8 except indicated below:

7.1 General
Same as Chapter 8 with the following addition:

Acceptance or rejection of service code types shall be under operator control except that receivers
shall always receive navigational warnings, meteorological warnings, SAR information and To-Mobile
distress alerts which are directed to a geographical area within which the receiver is situated.

7.3.1.1 Maritime Mobile

For a SOLAS SafetyNETSM receiver the printer requirements of Volume 3, Part 2, Chapter 5, Section
7.3.1 apply. Received EGC messages may be stored for later printing with an indication to the
operator that the message has been received. However, distress or urgency priority calls shall be
directly printed as well as stored. Means shall be provided not to print or store the same EGC
message after it has been received error free and printed; Section 7.7.4 refers.

A local audible alarm shall be sounded to give advanced warning of a printer "paper-low" condition. It
shall not be possible to confuse the sound of the "paper-low" alarm with that of the distress alarm
described in Section 7.7.6.

All SafetyNETSM messages shall be annotated with the time (UTC) and date of reception. This
information shall be displayed or printed with the message. Note that UTC can be deduced from the
NCS frame number .

7.4 Operator Controls


The following control functions and displays shall be provided as a minimum:

(a) selection of EGC carrier frequency (see Section 6.3);

For SOLAS SafetyNETSM receivers:

(b) means of inputting the following information:

(i) mobile's position coordinates;

(ii) current and planned NAVAREA /METAREA; and

(iii) current and planned Coastal service coverage areas.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 5
Chapter 8 - Annex A: Technical Requirements for a SafetyNETSM Receiver for
SOLAS SESs
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Receivers shall be fitted with operator controls to allow the operator to select desired geographical
areas and message categories as described in Section 7.7. Details of the geographical areas and
message categories which have been selected for reception by the operator, shall be readily
available.

Attention is drawn to the additional requirements of IEC 1097-4, Section 3.5.2 for SOLAS
SafetyNETSMreceivers.

7.5.2 Non-Volatile Memory


Same as Chapter 8 with the following addition:

It is recommended that provision is made for non-volatile storage of position coordinates and Navarea
geographical area data.

7.7.3 Geographical Area Addressing


Geographical area addressing refers to messages transmitted to SESs in a particular area. The area
may be expressed in terms of a fixed, pre-defined area such as the NAVAREA, or Coastal warning
coverage area, or in terms of an absolute geographical address expressed as latitude and longitude
coordinates on the surface of the earth.

An absolute geographical area address is a representation of a closed boundary on the surface of the
earth given in the address field of the message header. The receiver shall recognize two forms of
absolute geographical addressing: rectangular and circular. Each form is specified in terms of an
absolute position in latitude and longitude and further parameters which completely specify the
boundary.

In order to process a geographical area address, the receiver must be programmed with the SESs
current position. The position may be entered automatically from an external navigation aid or entered
manually. The receiver shall provide notification to the operator when the position has not been
updated for four hours. If the SES's position has not been updated for more than 12 hours, or is
unknown because the equipment has been powered off, all SafetyNETSM messages with priorities
higher than routine shall be printed .

A geographical area address shall be considered valid for a particular SES if its current position falls
inside, or on, the boundary specified by the geographical address. It is a mandatory requirement that
the operator be able to select more than one area, so that messages directed to other area(s) of
interest can be provided. It is recommended that the operator be able to select at least four areas.

7.7.4 Message Identification


Messages will be transmitted with an associated identifying combination of "sequence number", an
originating LES ID and service code, carried in the packet header(s). Each subsequent transmission
of the message will contain the original sequence number. This facility allows multiple printing of
repeated messages to be inhibited.

7.7.4.1 Maritime Requirements

When a message has been received error free, and a permanent record made, the unique 16 bit
sequence number, the LES identifier and the service code field associated with that message shall
be stored in memory and the information used to inhibit the printing of repeated transmissions of the
same message. IEC 1097-4, Section 3.4.10, refers.

The EGC receiver shall be capable of internally storing at least 255 such message identifications.
These message identifications shall be stored with an indication of the number of hours that have
elapsed since the message has been received. Subsequent reception of the same message
identification shall reset this timer. After between 60 and 72 hours, message identifications may be
Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 6
Chapter 8 - Annex A: Technical Requirements for a SafetyNETSM Receiver for
SOLAS SESs
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

automatically erased. If the number of received message identifications exceeds the capacity of
memory allocated, the oldest message identification shall be erased.

7.7.5 Error Detection


The EGC message will employ three levels of error detection:

(i) an arithmetical checksum is used to detect packet errors;

(ii) an arithmetical checksum is used to detect header errors; and

(iii) parity checking is used to indicate character errors in the information field.

Only packets with header fields received without error shall be processed for local message recording
(even if the packet itself contains an error). In the case of double header messages, the message
may be processed even if only one header has been received correctly. A parity check on all
incoming characters shall be performed and in the event of a parity error in a received character, the
"low line" character (5/15 in T.50) shall be displayed and/or printed.

Outputs for multi-packet messages which have been received incomplete shall provide a positive
indication of the position of the missed packet(s). If further packets of an EGC message are expected
but none are received after waiting for three frames, the EGC message shall be assumed to be
completed: this is to guard against the possibility of the last packet of an EGC message not being
received. The MES shall return to the idle state and indicate that one or more packets of the EGC
message are missing.

For SafetyNETSMEGC receivers, subsequent reception of the same message, printed with mutilated
characters, shall continue to be printed until the message has been received error free and printed.
IEC 1097-4, Section 3.4.10 refers.

7.7.6 Distress / Urgency Call Alarm


For SOLAS SafetyNETSM receivers:

Provision shall be made for a specific aural alarm and visual indication at the position from which the
ship is normally navigated to indicate receipt of a distress or urgency call or a call having distress
priority. It shall not be possible to disable this alarm and it shall only be possible to re-set it manually
and then only from the position where the message is displayed or printed". IEC 1097-4, Section 3.4.6
refers.

The SES shall raise audible and visual alarms on receipt of a distress or an urgency call, in
compliance with the above.

8 Distress Calling
Not applicable.

9 Testing Functions
Same as Chapter 8 except where inidicated below:

9.1 Link Performance Monitoring


SafetyNETSM EGC receivers shall utilize the received bulletin board error rate as a measure of link
performance (see Chapter 2, Section 9.2).

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 7
Chapter 8 - Annex A: Technical Requirements for a SafetyNETSM Receiver for
SOLAS SESs
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

9.2 Alarms and Indications


The following alarms and indications shall be provided at a SOLAS SafetyNETSM receiver and shall
meet the operational requirements for alarms stated in IEC 945.

9.2.1 Distress / Urgency Alarms


Reception of an EGC message with distress or urgency priority (Section 7.7.6 refers). This condition
shall generate a distress alarm signal at a SOLAS SafetyNETSM receiver, which is capable of being
extended to a remote alarm panel (e.g. by means of relay contacts) should this be required. This may
be combined in the common distress alarm described in Chapter 5, Annex A, Section 9.5.1.

9.2.2 Other Alarms and Indications


(i) High BBER: Section 6.3.2 refers;

(ii) Printer paper low: Section 7.3.1.2 refers;

(iii) Receiver fault indication;

(iv) Loss of receiver synchronisation: Section 7.3.2 refers; and

(v) Position update: Section 2.1 (d) refers.

It is recommended that any of these conditions shall generate a common alarm signal at the
SafetyNETSM receiver (separate from that described in Chapter 5, Section 9.5.1), which is capable of
being extended to a remote alarm panel (e.g. by means of relay contacts) should this be required.

Additional alarms and indications may be provided at the manufacturer's discretion.

10 Electromagnetic Compatibility
The interference and electromagnetic compatibility requirements of Chapter 5, Annex A, Section 10
are mandatory for SOLAS SafetyNETSM receivers.

11 Environmental Conditions

11.1 Purpose
SOLAS SafetyNETSM receivers shall operate satisfactorily under the environmental conditions
specified in Volume 3, Part 2, Chapter 5, Annex A, Section 11. The latest issues of IEC 1097-4 and
IEC 945 refer.

12 Optional Features

12.1 Reception of SAFETYNETSM or FLEETNETSM Service Only


Manufacturers may choose to produce receivers capable of receiving both the SafetyNETSM service
and the FleetNETSM service. In case of conflict between the two sets of technical requirements, the
SafetyNETSM requirements shall apply.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 8
Chapter 8 - Annex A: Technical Requirements for a SafetyNETSM Receiver for
SOLAS SESs
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

12.2 Navigational Interface


In order that a receiver's position may be automatically updated, receivers may be equipped with an
interface to navigational instruments. A suggested standard interface is in IEC 1162, Part1 (NMEA
0183) Standard for Interfacing Electronic Marine Navigational devices.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 9
Chapter 8 - Annex A: Technical Requirements for a SafetyNETSM Receiver for
SOLAS SESs
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 8 - Annex B: Technical Requirements for a


SafetyNETSM Receiver for Non-SOLAS SESs

Contents

1 Introduction ............................................................................ 3
1.1 Non-Solas SafetyNETSM Receivers ....................................................................3

2 General Requirements ............................................................. 3

3 RF Subsystem Requirements ................................................... 3

4 Receiver Performance ............................................................. 3

5 Transmitter Performance ......................................................... 3

6 Access Control Requirements ................................................. 3

7 Message Processing Requirements ......................................... 3


7.1 General .............................................................................................................3
7.3 Display Devices ................................................................................................3
7.3.1 Message Display ............................................................................................3
7.4 Operator Controls .............................................................................................4
7.5.1 Message Buffer ..............................................................................................4
7.5.2 Non-Volatile Memory......................................................................................4
7.7.3 Geographical Area Addressing ......................................................................4
7.7.4 Message Identification ...................................................................................5
7.7.4.1 Maritime Requirements .......................................................................................................... 5

7.7.5 Error Detection ...............................................................................................5


7.7.6 Distress / Urgency Call Alarm ........................................................................5

8 Distress Calling ...................................................................... 5

9 Testing Functions ................................................................... 5


9.1 Link Performance Monitoring ............................................................................5
9.2 Alarms and Indications ......................................................................................5
Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 1
Chapter 8 - Annex B: Technical Requirements for a SafetyNETSM Receiver for Non-
SOLAS SESs
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

9.2.1 Distress / Urgency Alarms..............................................................................5


9.2.2 Other Alarms and Indications .........................................................................6

10 Electromagnetic Compatibility ............................................... 6

11 Environmental Conditions ..................................................... 6


11.1 Purpose...........................................................................................................6

12 Optional Features .................................................................. 6


12.1 Reception of SAFETYNETSM;; and FLEETNETSM;; Services ......................6
12.2 EGC Reception with Inmarsat-A or Inmarsat-B MESs ....................................6
12.3 Navigational Interface .....................................................................................6

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 2
Chapter 8 - Annex B: Technical Requirements for a SafetyNETSM Receiver for Non-
SOLAS SESs
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction

1.1 Non-Solas SafetyNETSM Receivers


The SafetyNETSM receivers described in this Annex are designed for use on non-SOLAS vessels.
They are not required to comply with the IMO's GMDSS requirements.

2 General Requirements
Same as Chapter 8.

3 RF Subsystem Requirements
As Chapter 8.

4 Receiver Performance
Same as Chapter 8.

5 Transmitter Performance
Not applicable.

6 Access Control Requirements


As Chapter 8.

7 Message Processing Requirements


Same as Chapter 8 except where indicated below. The requirements of this section may be amended
to comply with future recommendations of the IMO.

7.1 General
This Section describes the requirements and recommendations for the message processing
subsystem of the Non-SOLAS SafetyNETSM receiver.

Same as Chapter 8 with following addition:

Acceptance or rejection of service code types shall be under operator control except that receivers
shall always receive navigational warnings, meteorological warnings, SAR information and To-Mobile
distress alerts which are directed to a geographical area within which the receiver is situated.

7.3 Display Devices

7.3.1 Message Display


All SafetyNETSM messages shall be annotated with the time (UTC) and date of reception. This
information shall be displayed or printed with the message. Note that UTC can be deduced from the
NCS frame number.
Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 3
Chapter 8 - Annex B: Technical Requirements for a SafetyNETSM Receiver for Non-
SOLAS SESs
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

7.4 Operator Controls


The following control functions and displays shall be provided as a minimum:

(a) selection of EGC carrier frequency (see Section 6.3);

For Non-SOLAS SafetyNETSM receivers:

(b) means of inputting the following information:

(i) mobile's position coordinates;

(ii) current and planned IHO NAVAREA of ship operation;

(iii) current and planned Coastal service coverage areas of ship operation.

Receivers shall be fitted with operator controls to allow the operator to select desired geographical
areas and message categories as described in Section 7.7. Details of the geographical areas and
message categories which have been selected for reception by the operator, shall be readily
available.

7.5.1 Message Buffer


A message buffer memory with a capacity of not less than 32768 bytes shall be provided.

7.5.2 Non-Volatile Memory


Same as Chapter 8 with following addition:

Additionally it is recommended that provision is made for non-volatile storage of position coordinates
and Navarea geographical area data.

7.7.3 Geographical Area Addressing


Geographical area addressing refers to messages transmitted to SESs in a particular area. The area
may be expressed in terms of a fixed, pre-defined area such as the NAVAREA, or Coastal warning
coverage area, or in terms of an absolute geographical address expressed as latitude and longitude
coordinates on the surface of the earth.

An absolute geographical area address is a representation of a closed boundary on the surface of the
earth given in the address field of the message header. The receiver shall recognize two forms of
absolute geographical addressing: rectangular and circular. Each form is specified in terms of an
absolute position in latitude and longitude and further parameters which completely specify the
boundary.

In order to process a geographical area address, the receiver must be programmed with the SESs
current position. The position may be entered automatically from an external navigation aid or entered
manually. The receiver shall provide notification to the operator when the position has not been
updated for four hours. If the SES's position has not been updated for more than 12 hours, or is
unknown because the equipment has been powered off, all SafetyNETSM messages with priorities
higher than routine shall be displayed and/or printed.

A geographical area address shall be considered valid for a particular SES if its current position falls
inside, or on, the boundary specified by the geographical address. It is a mandatory requirement that
the operator be able to select more than one area, so that messages directed to other area(s) of
interest can be provided. It is recommended that the operator be able to select at least four areas.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 4
Chapter 8 - Annex B: Technical Requirements for a SafetyNETSM Receiver for Non-
SOLAS SESs
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

7.7.4 Message Identification


Messages will be transmitted with an associated identifying combination of "sequence number", an
originating LES ID and service code, carried in the packet header(s). Each subsequent transmission
of the message will contain the original sequence number. This facility allows multiple printing of
repeated messages to be inhibited.

7.7.4.1 Maritime Requirements

When a message has been received error free, and a permanent record made, the unique 16 bit
sequence number, the LES identifier and the service code field associated with that message shall be
stored in memory and the information used to inhibit the printing of repeated transmissions of the
same message.

The EGC receiver shall be capable of internally storing at least 255 such message identifications.
These message identifications shall be stored with an indication of the number of hours that have
elapsed since the message has been received. Subsequent reception of the same message
identification shall reset this timer. After between 60 and 72 hours, message identifications may be
automatically erased. If the number of received message identifications exceeds the capacity of
memory allocated, the oldest message identification shall be erased.

7.7.5 Error Detection


Same as Chapter 8 with following addition:

Subsequent receptions of messages printed with mutilated characters shall be output again until
received error free.

7.7.6 Distress / Urgency Call Alarm


For SafetyNETSM receivers:

"Provision shall be made for a specific aural alarm and visual indication to indicate receipt of a
distress or urgency call or a call having distress priority.

8 Distress Calling
Not applicable.

9 Testing Functions
Same as Chapter 8 except indicated below:

9.1 Link Performance Monitoring


SafetyNETSM EGC receivers shall utilize the received bulletin board error rate as a measure of link
performance (see Chapter 2, Section 9.2).

9.2 Alarms and Indications


The following alarms and indications shall be provided at a Non-SOLAS SafetyNETSM receiver :

9.2.1 Distress / Urgency Alarms


Reception of an EGC message with distress or urgency priority (Section 7.7.6 refers).
Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 5
Chapter 8 - Annex B: Technical Requirements for a SafetyNETSM Receiver for Non-
SOLAS SESs
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

9.2.2 Other Alarms and Indications


(i) High BBER: Section 6.3.2 refers;

(ii) Receiver fault indication; and

(iii) Loss of receiver synchronisation: Section 7.3.2 refers.

Additional alarms and indications may be provided at the manufacturer's discretion.

10 Electromagnetic Compatibility
As Chapter 8.

11 Environmental Conditions

11.1 Purpose
Non-SOLAS SafetyNETSM receivers shall operate satisfactorily under the environmental conditions
specified in Volume 3, Part 2, Chapter 5, Section 11.

12 Optional Features

12.1 Reception of SAFETYNETSM;; and FLEETNETSM;; Services


Manufacturers may choose to produce receivers capable of receiving both the SafetyNETSM service
and the FleetNETSM service. In case of conflict between the two sets of technical requirements, the
SafetyNETSM requirements shall apply.

12.2 EGC Reception with Inmarsat-A or Inmarsat-B MESs


An EGC receiver may be used with existing type approved Inmarsat-A or Inmarsat-B MES equipment.
In such cases the interconnection may be made at IF so that the EGC receiver will not require an
antenna and low noise down converter. The requirements of Section 3.1 will not apply.

The EGC receiver shall meet the technical requirements of Sections 4, 5, 6, 7, 8 and 9 of this
document with a specific model or models of a type approved Inmarsat-A or Inmarsat-B MES. The
performance of the MES shall not be affected in any way by the provision for, or inclusion of, the EGC
receiver option.

12.3 Navigational Interface


In order that a receiver's position may be automatically updated, receivers may be equipped with an
interface to navigational instruments. A suggested standard interface is in IEC 1162, Part1 (NMEA
0183) Standard for Interfacing Electronic Marine Navigational devices.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 6
Chapter 8 - Annex B: Technical Requirements for a SafetyNETSM Receiver for Non-
SOLAS SESs
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 8 - Annex C: Technical Requirements for a


FleetNETSM Receiver

Contents

1 Introduction ............................................................................ 2
1.1 FleetNETSM EGC Receiver .................................................................................2

2 General Requirements ............................................................. 2

3 RF Subsystem Requirements ................................................... 2

4 Receiver Performance ............................................................. 2

5 Transmitter Performance ......................................................... 2

6 Access Control Requirements ................................................. 2

7 Message Processing Requirements ......................................... 2


7.5.2 Non-Volatile Memory......................................................................................2
7.7.1 EGC Receiver Unique Identities ....................................................................2
7.7.2 EGC Receiver Closed Network Identities (ENIDS) ........................................3
7.7.2.1 Operator Access .................................................................................................................... 3

7.7.3 Message Identification ...................................................................................3


7.7.4 Manufacturer's EGC Closed Network Identity (MENID) ....................................3

8 Distress Calling ...................................................................... 3

9 Testing Functions ................................................................... 3

10 Electromagnetic Compatibility ............................................... 4

11 Environmental Conditions ..................................................... 4


11.1 Minimum Environmental Conditions for FleetNETSM EGC Receivers ...............4

12 Optional Features .................................................................. 4


12.1 Reception of SafetyNETSM and FleetNETSM Services .......................................4
12.2 EGC Reception with Inmarsat-A or Inmarsat-B MESs ....................................4

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 1
Chapter 8 - Annex C: Technical Requirements for a FleetNETSM Receiver
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
Same as Chapter 8, except where indicated below:

1.1 FleetNETSM EGC Receiver


FleetNET EGC receivers may be used in both maritime and land mobile applications. For maritime
applications, the applicable electromagnetic compatibility and environmental specifications depending
on the application envisaged, will be found in Chapter 5 and Chapter 5 Annex A of this Volume,
Section 10 and 11.

2 General Requirements
Same as Chapter 8.

3 RF Subsystem Requirements
Same as Chapter 8.

4 Receiver Performance
Same as Chapter 8.

5 Transmitter Performance
Not applicable.

6 Access Control Requirements


Same as Chapter 8.

7 Message Processing Requirements


Same as Chapter 8, except where indicated below:

7.5.2 Non-Volatile Memory


FleetNETSM receivers shall use non-volatile memory for storing ENIDs and expansion NCS common
channel numbers. Provision for storing at least 16 NCS common channel numbers in non-volatile
memory shall be available.

7.7.1 EGC Receiver Unique Identities


The FleetNETSM service provides a means of transmitting messages to both individual and selected
groups of EGC receivers. These receivers will be allocated unique 24 bit identities by Inmarsat.

Unique identities are required for the reception of EGC System Messages (Service code 23) and for
Download Group ID commands (Service code 33)

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 2
Chapter 8 - Annex C: Technical Requirements for a FleetNETSM Receiver
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

For further information regarding the allocation of these IDs, refer to "Type Approval Procedures for
Inmarsat-C Mobile Earth Stations" and "Commissioning Procedures for Inmarsat-C Mobile Earth
Stations".

7.7.2 EGC Receiver Closed Network Identities (ENIDS)


FleetNETSM services such as Group calls are only available to receivers having 16-bit EGC closed
network Identities (ENIDs). The facility for downloading and deleting the ENIDs, which are allocated
by Inmarsat, over the satellite link is available as part of the FleetNETSM service using service code
33.

7.7.2.1 Operator Access

The ENIDs stored shall only be accessible for downloading and deleting via the satellite path.

It shall be possible for the MES operator to inhibit (or activate as required), via the DTE, selected
ENIDs previously downloaded.

Along with the ENID, the name of the service provider shall be stored. This name will be contained in
the first 25 characters of the "free" field in the initial download command.

Following the initial download the ENID and "free" field shall be printed and/or displayed.

In the event that a download command is received and the ENID storage area is full, then an ENID
which has been inhibited (de-activated) by the MES operator shall be overwritten. If none have been
inhibited then the new download shall not be accepted.

7.7.3 Message Identification


All Messages will be transmitted with an associated identifying combination of "sequence number", an
originating LES ID and service code, carried in the packet header(s). Each subsequent transmission
of the message will contain the original sequence number. This facility allows multiple printing of
repeated messages to be inhibited.

7.7.4 Manufacturer's EGC Closed Network Identity (MENID)


Each MES shall have a 16-bit manufacturer's EGC closed network Identity (MENID). The MENID
shall be installed into the MES during the production and shall be protected against subsequent
alteration. It shall not be possible for an MES operator to create, modify or erase the MENID.

A unique MENID will be issued to each model type. As the MENID is to be used for the purpose of
communicating software or hardware upgrade information for a specific MES model, only the MES
manufacturers and Inmarsat are authorised to make used of this feature to advise the affected MES
users. For the purpose of security, the MENID shall not be made known to MES users through the
user iinterface or manual.

These requirements are applicable for Class 0,2 and 3 MESs.

8 Distress Calling
Not applicable.

9 Testing Functions
Same as Chapter 8.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 3
Chapter 8 - Annex C: Technical Requirements for a FleetNETSM Receiver
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

10 Electromagnetic Compatibility
Compliance with the electromagnetic compatibility requirements of Chapter 5 or Chapter 5 Annex A,
Section 10 may be mandatory for FleetNETSM EGC receivers intended for use aboard vessels,
depending on the application.

11 Environmental Conditions

11.1 Minimum Environmental Conditions for FleetNETSM EGC Receivers


The following specification is recommended for all FleetNETSM EGC receivers.

FleetNETSM receivers, which are to be type approved as suitable for maritime use within the
INMARSAT system, shall be designed so as to operate satisfactorily over the appropriate
environmental conditions given in Chapter 5 or Chapter 5, Annex A, depending on the application.

12 Optional Features

12.1 Reception of SafetyNETSM and FleetNETSM Services


Manufacturers may choose to produce receivers capable of receiving both the SafetyNETSM service
and the FleetNETSM service. In case of conflict between the two sets of technical requirements, the
appropriate SafetyNETSMrequirements shall apply.

12.2 EGC Reception with Inmarsat-A or Inmarsat-B MESs


A FleetNETSM EGC receiver may be used with existing type approved Inmarsat-A or Inmarsat-B
MES equipment. In such cases the interconnection may be made at IF so that the EGC receiver will
not require an antenna and low noise down converter. The requirements of Section 3.1 will not apply.

The EGC receiver shall meet the technical requirements of Sections 4, 5, 6, 7, 8 and 9 of this
document with a specific model or models of a type approved Inmarsat-A or Inmarsat-B MES. The
performance of the MES shall not be affected in any way by the provision for, or inclusion of, the EGC
receiver option.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 4
Chapter 8 - Annex C: Technical Requirements for a FleetNETSM Receiver
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 9: Technical Requirements for an


Aeronautical Mobile Earth Station

Contents

1 Introduction ............................................................................ 3
1.1 Purpose and Scope ..........................................................................................3

2 General Requirements ............................................................. 3


2.1 Classes of Aeronautical Mobile Earth Stations .................................................3
2.2 Inmarsat-C Mobile Earth Station Definition .......................................................3
2.4 Mandatory Capabilities......................................................................................3

3 RF Subsystem Requirements ................................................... 3


3.2.3 Axial Ratio ......................................................................................................3
3.2.4 Carrier to Multipath Discrimination .................................................................3
3.3 Receiver RF Requirements ...............................................................................3
3.3.1 Gain-to-Noise Temperature Ratio ..................................................................3
3.3.1.1 Definition of Service Coverage Requirement ......................................................................... 4

3.3.1.2 Minimum Coverage Requirement .......................................................................................... 4

3.3.3 Immunity to Out of Band Signals ....................................................................4


3.4 Transmitter RF Requirements ...........................................................................5
3.4.1 EIRP...............................................................................................................5
3.4.8 Frequency Accuracy and Stability ..................................................................5
3.4.8.1 High Stability Reference Oscillator Option ............................................................................. 5

3.4.8.2 Closed Loop Frequency Control Option ................................................................................ 5

4 Receiver Performance ............................................................. 5


4.1 To-Mobile Signal Characteristics ......................................................................5
4.4 Demodulator Performance ................................................................................5
4.7 Receiver Frequency Capture Range .................................................................6

5 Transmitter Performance ......................................................... 6

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 1
Chapter 9: Technical Requirements for an Aeronautical Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

5.5 Transmitted Signal Frequency Error Allowance ................................................6


5.6 Transmit Frequency Correction.........................................................................7

6 Access Control Requirements ................................................. 7


6.2.3 Signalling Channel Access Restrictions .........................................................7

7 Message Processing Requirements ......................................... 7

8 Alerting Functions .................................................................. 7

9 Testing Functions ................................................................... 7

10 Electromagnetic Compatibility ............................................... 7

11 Environmental Conditions ..................................................... 7


11.1 Purpose and Applicability ................................................................................7
11.2 Environmental Conditions for Inmarsat-C AMESs ..........................................8

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 2
Chapter 9: Technical Requirements for an Aeronautical Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction

1.1 Purpose and Scope


This document describes the requirements and recommendations for an Aeronautical Mobile Earth
Station; (AMES), which is a Mobile Earth Station designed specifically for use in aircraft.

The characteristics of an AMES are generally the same as those of a Mobile Earth Station as
described in Chapter 2 of this volume. The purpose of this chapter is to point out the differences that
are applicable for aeronautical mobile equipment. The numbering of the sections in this chapter
generally follow those of Chapter 2 and where a Chapter 2 section is not mentioned it must be
assumed that the original Chapter 2 requirement still applies.

It should not be assumed that this document covers any national or regional requirements, which may
have to be met in addition to those referred to here. Neither does this document cover any
requirements for the use of equipment under aeronautical conditions.

2 General Requirements

2.1 Classes of Aeronautical Mobile Earth Stations


As Chapter 2. Distress Alerts are not allowed.

2.2 Inmarsat-C Mobile Earth Station Definition


As Chapter 2.

2.4 Mandatory Capabilities


As Chapter 2.

3 RF Subsystem Requirements
As Chapter 2, except where indicated below.

3.2.3 Axial Ratio


The axial ratio shall not exceed 6dB for elevation angles from 5° to 90° and all azimuths, or the
antenna shall have enough gain to compensate for additional polarisation losses caused by the non-
compliant axial ratios. In the latter case, an axial ratio of 2.5 dB for the satellite antenna should be
assumed.

3.2.4 Carrier to Multipath Discrimination


With the aircraft in horizontal flight over sea in any sea condition, the AMES antenna shall attenuate
the reflected signal from the sea surface relative to the main signal in the direction of the satellite, so
as to achieve minimum C/M of 9 dB at 5° elevation and 12 dB at 20° elevation.

3.3 Receiver RF Requirements

3.3.1 Gain-to-Noise Temperature Ratio


The minimum gain profile and the receiver system noise temperature, including the antenna, shall be
such that in the frequency band 1530.0 to 1545.0 MHz the G/T ratio is not less than that represented
by the service coverage requirement.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 3
Chapter 9: Technical Requirements for an Aeronautical Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

G/T ≥ -23-1.5sin(θ-5) dB/K + 5° ≤ θ ≤ +90°

where θ is the elevation angle in degrees with zenith at +90°.

The G/T requirement shall be met under the following conditions:

(a) clear sky climatic conditions;

(b) satellite elevations greater than or equal to 5°;

(c) including the noise contribution of the receiver low noise amplifier and following stages at an
ambient temperature of 25°C;

(d) including the loss introduced by a dry radome, where a radome is fitted;

(e) with the transmitter at the specified output level where a diplexer is used (see Section 3.4.1), or
at the specified "off" level (see Chapter 2, Section 3.4.3); and

(f) under the operational RF environment.

The antenna gain is as defined in Section 3.2.1 and the receiving system noise temperature is
expressed in dB relative to 1K. Gain and Temperature must be referred to a suitable common point
within the receiving system.

3.3.1.1 Definition of Service Coverage Requirement

Service Coverage is the percentage of the “Inmarsat hemisphere” where all the antenna dependent
requirements are simultaneously met, e.g. G/T, EIRP, axial ratio and carrier to multipath
discrimination, at all operating frequencies.

The Inmarsat hemisphere is the part of the hemisphere above the aircraft with elevation angles
ranging from 5° to 90°.

3.3.1.2 Minimum Coverage Requirement

With the aircraft in horizontal flight, the service coverage of the AMES installation shall be greater than
60%.

3.3.3 Immunity to Out of Band Signals


The receiving system should have sufficient front end filtering to provide rejection of out of band
emissions from adjacent systems. In particular, sufficient rejection of from Mobile carriers in the
1626.5 to 1660.5 MHz frequency range must be provided in order to minimize the risk of interference
from other INMARSAT MESs operating in close proximity.

A continuous wave carrier at any frequency within the range 1626.5 MHz to 1660.5 MHz, and at a flux
density level of -15 dBW/m2 at the receiver antenna, with the antenna oriented for maximum signal,
shall not impair the operation or performance of the receiver in any way.

In addition to the requirements above, the AMES shall be capable of withstanding, without permanent
degradation, a 1 second out of band pulse with the following flux densities:

Frequency (MHz) Input Flux Density (dBW/m2)


1 - 1400 30
1700 - 6000 38

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 4
Chapter 9: Technical Requirements for an Aeronautical Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.4 Transmitter RF Requirements


As Chapter 2, except where indicated below.

3.4.1 EIRP
The maximum EIRP radiated by the AMES in any direction shall not exceed +16 dBW. The variation
in EIRP due to all causes shall be such as to maintain the EIRP towards the satellite within these
specified limits under all operational conditions.

3.4.8 Frequency Accuracy and Stability


The AMES may use either a high stability reference oscillator or closed loop frequency control to meet
the frequency accuracy requirements. All requirements of either Sections 3.4.8.1 or 3.4.8.2 below
must be met. All transmissions shall be inhibited if the required transmit frequency accuracy and
stability cannot be maintained (see Volume 1, Chapter 3, Tables 4.1 and 4.2).

3.4.8.1 High Stability Reference Oscillator Option

If the AMES uses a high stability reference oscillator, the transmit frequency shall be maintained
within +/- 720 Hz of the nominal transmit channel frequency (about 4.3 x 10-7), at L-band at all times,
without requiring adjustment more frequently than once every year. The AMES transmit frequency
shall be derived from the same master frequency oscillator as is used to determine the AMES receive
frequency.

3.4.8.2 Closed Loop Frequency Control Option

As Chapter 2, Section 3.4.8.

4 Receiver Performance
As Chapter 2, except where indicated below.

4.1 To-Mobile Signal Characteristics


As Chapter 2, Section 4.1 except that the frequency characteristics in part (d) are replaced by the
following:

(d) absolute average frequency: within ±1066 Hz including the residual Doppler
effects of the relative satellite-AMES motion, after
Doppler compensation at the AMES (see Volume
1, Chapter 3, Tables 4.1 and 4.2).

The frequency characteristics in part (e) do not apply.

4.4 Demodulator Performance


The acquisition and output performance requirements specified in Sections 4.5 and 4.6 shall be met
under the following RF (L-band) signal parameters assumed to exist in the vicinity of the antenna:

(a) a received frequency range of 1530.0 to 1545.0 MHz;

(b) an unfaded power flux density range of -146.5 to -144.5 dBW/m2 (corresponding to a worst
case C/No range at the demodulator of 34.0 to 36.0 dBHz);

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 5
Chapter 9: Technical Requirements for an Aeronautical Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(c) a C/No of 55.7 dBHz (excludes antenna and receiver noise);

(d) an initial frequency offset of ±900 Hz (99% probability contour), and a short term variation of
from + 50 Hz to -50 Hz in 3 seconds. This offset does not include receiver down-converter
errors but does include residual Doppler effects due to the relative satellite-AMES motion, after
Doppler compensation at the AMES (see Volume 1, Chapter 3, Tables 4.1 and 4.2).

(e) an initial clock frequency offset of ±0.06 Hz (±50 parts in 106);

(f) with phase noise superimposed on the received carrier with spectral characteristics as shown
in Chapter 2, Figure 4-6;

(g) in the presence of Rician distributed multipath fading. Chapter 2, Figure 4-8 illustrates the
Rician fading model. The parameters to be used are:

Elevation Angle C/M Ratio

5° 9 dB
20° 12 dB

The fading spectral characteristics corresponding to a second order Butterworth filter with f(3
dB) = 20 to 100 Hz;

(h) in the presence of one adjacent channel interferer (BPSK modulated at 1200 symbols/s) at
±5 kHz from the carrier with a relative level of +5 dBc.

(j) in the presence of out-of-band signals as specified in Section 3.3.3.

Frequency changes due to the Doppler effects of relative aircraft-satellite motion must be
compensated for by the AMES. The compensation must be adequate for the declared environmental
conditions of the AMES.

4.7 Receiver Frequency Capture Range


The AMES shall be capable of receiving signals with a frequency offset from nominal equal to ±900
Hz excluding any receiver downconverter errors and uncompensated Doppler shift induced by the
worst case AMES-satellite relative motion.

Note: It is assumed that the receiver uses a frequency compensation mechanism to remove Doppler
effects due to relative satellite-AMES motion with a residual error allowance of ±250 Hz.

For subsonic aircraft, the maximum offset due to aircraft velocity alone is approximately ±2kHz.
The frequency offset due to Doppler shift may be relaxed depending upon the maximum speed
of the aircraft.

5 Transmitter Performance
As Chapter 2, except where indicated below.

5.5 Transmitted Signal Frequency Error Allowance


Due to all causes, the total error of the transmitted frequency received at the satellite shall not exceed
1145 Hz relative to the nominal channel frequency (see Volume 1, Chapter 3, Tables 4.1 and 4.2).

All AMES transmissions shall be inhibited if the transmit frequency cannot be maintained to this
requirement.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 6
Chapter 9: Technical Requirements for an Aeronautical Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

5.6 Transmit Frequency Correction


The frequency of all transmitted signals shall be corrected for Doppler frequency shifts caused by the
relative motions of the aircraft and the satellite. The Doppler adjustment resolution shall not exceed 10
Hz and associated frequency changes shall be made without introducing phase discontinuities into
the transmitted signal. The maximum rate of change of the frequency of the transmitted signal
received at the satellite shall not exceed 65 Hz/sec.

6 Access Control Requirements


As Chapter 2, except where indicated below.

6.2.3 Signalling Channel Access Restrictions


AMESs shall only communicate with LESs which indicate, via their bulletin boards and network
configuration information, that the Aero-C service is supported (Volume 4, Chapter 2, Section 3.1.4.6
refers).

AMESs shall only use signalling channels which indicate, via the appropriate signalling channel
descriptor, that they are available for Aero-C use (Volume 4, Chapter 2, Section 3.2.7 refers).

7 Message Processing Requirements


As Chapter 2.

8 Alerting Functions
Aeronautical Mobile Earth Stations are not permitted to send maritime distress alerts. Maritime
Distress Alerts must be inhibited on MESs intended for aeronautical use.

9 Testing Functions
As Chapter 2.

10 Electromagnetic Compatibility
Inmarsat does not specify limits of electromagnetic emissions emanating from an AMES. Reference
should be made to specifications issued by the relevant authorities, e.g. RTCA/DO-160C*, Section 21.

11 Environmental Conditions

11.1 Purpose and Applicability


The environmental conditions defined in the DO-160C specifications vary according to the type of
aircraft, referred to by category in DO-160C. The approval will be given for the specific category in
which the equipment has been tested and will be valid for all other less demanding categories.

* Radio Technical Commission for Aeronautics, RTCA/DO-160C, "Environmental Conditions and


Test Procedures for Airborne Equipment".
Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 7
Chapter 9: Technical Requirements for an Aeronautical Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

11.2 Environmental Conditions for Inmarsat-C AMESs


The minimum environmental conditions for which any AMES shall be tested for each requirement are
set out in the following table. Depending on the intended application of the AMES, Inmarsat at its
discretion may require supplementary environmental tests to be performed.

The specific environmental tests against which each particular AMES design has been tested shall
\be noted on its Type Approval Certificate, and the manufacturer of the AMES shall ensure that
prospective purchasers and users of the AMES are aware of these and consequently of the suitability
of the product for different ranges of applications.

DO-160C Section
Inmarsat-C Requirement
* 4 6 8 16 19 20
3.2.1 - Antenna Gain X X
3.3.1 - G/T X X X X
3.3.4 - Receiver tuning X X X X
3.4.1 - EIRP X X X
3.4.2 - Transmitted spectrum X X X
3.4.4 - Spurious Output X X X X X
3.4.5 - Harmonics X X X
3.4.6 - Phase noise X X X
3.4.7 - Transmitter tuning X X
3.4.8 - Frequency accuracy X X
4.5 - Continuous reception output performance X X X X X

Key to Table:

* - Normal ambient (not included in DO-160C)

4 - Temperature and altitude

6 - Humidity

8 - Vibration

16 - Power input

19 - Induced signal susceptibility

20 - Radio frequency susceptibility

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 8
Chapter 9: Technical Requirements for an Aeronautical Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 10: Technical Requirements for Low Power


Land Mobile Earth Station

Contents

1 Introduction ............................................................................ 3

2 General Requirements ............................................................. 3


2.1 Mandatory Capabilities......................................................................................3
2.2 Return Link Budget ...........................................................................................3
Table 1: Return Link Budget for Low Power C MES ...............................................3

3 RF Subsystem Requirements ................................................... 4


3.2 Antenna Requirements .....................................................................................4
3.3 Receiver RF Requirements ...............................................................................4
3.3.1 Gain-to-Noise Temperature Ratio ..................................................................4
3.3.3 Immunity to Out of Band Signals ....................................................................4
3.4 Transmitter RF Requirements ...........................................................................5
3.4.1 EIRP...............................................................................................................5
3.4.3 Transmitter Off Power Level ..........................................................................5
Table 2: Transmitter “OFF” Narrow Band Emission Limits ......................................5
Figure 1: Sprectrum Envelope for Transmitter “OFF” Emission Limits ....................6
3.4.4 Transmitter On Spurious Outputs ..................................................................6
Table 3: Transmitter "ON" Composite Emission Limits ...........................................6
Figure 2: Transmitter “ON” Spurious and Noise EIRP Limits, 1500-1800 Mhz .......7
3.4.5 Harmonic Outputs ..........................................................................................8
3.4.6 Phase Noise...................................................................................................8
Table 4: MES Transmit Phase Noise Limits ............................................................8
Figure 3: MES Induced Single Sideband Phase Noise Power in 1Hz Bandwidth ...9
3.4.7 Transmitter Tuning .........................................................................................9
3.4.8 Frequency Accuracy and Stability ..................................................................9

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 1
Chapter 10: Technical Requirements for Low Power Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4 Receiver Performance ............................................................. 9


4.7 Performance Under Blockage Conditions .........................................................9
4.7.1 General ..........................................................................................................9
4.7.2 Channel Model for Blockage. ....................................................................... 10
4.7.3 Performance with Short Term Repetitive Blockage ...................................... 10
4.7.4 Performance With Long Term Blockage ...................................................... 10

5 Transmitter Performance ....................................................... 11

6 Access Control Requirements ............................................... 11


6.2.2 Random Access and Retransmission Slot Selection.................................... 11
6.2.3 Signalling Channel Access Restriction ......................................................... 11
6.5 Ocean Region Registration Procedures .......................................................... 11
6.5.1 Logging In .................................................................................................... 11

7 Message Processing Requirements ....................................... 11

8 Alerting Functions ................................................................ 12


8.1 LES Service .................................................................................................... 12
8.2 Signalling Channel Precedence ...................................................................... 12
8.3 Land Mobile Alert Generator ........................................................................... 13
8.4 Alert Activation ................................................................................................ 13

9 Testing Functions ................................................................. 13


9.3 Performance Verification ................................................................................. 13

10 Electromagnetic Compatibility ............................................. 14

11 Environmental Conditions ................................................... 14


11.1 Purpose and Applicability .............................................................................. 14

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 2
Chapter 10: Technical Requirements for Low Power Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
This chapter describes the requirements and recommendations for a Low Power Land Mobile Earth
Station (LPMES), which is a Mobile Earth Station designed specifically for use in a land environment
with a satellite elevation angle greater than 15 degree . The reduction of transmit power of the LPMES
has been made possible because of better link margin provided by the Inmarsat 3rd generation
satellites .

The characteristics of a Low Power MES are generally the same as those of a Mobile Earth Station as
described in Chapter 2 of this volume. The purpose of this chapter is to point out the differences that
are applicable for low power land mobile equipment. The numbering of sections in this chapter follow
those of Chapter 2 and where a section of Chapter 2 is not mentioned, it must be assumed that the
original Chapter 2 requirement still applies.

It should not be assumed that this Chapter covers any national or regional requirements, which may
have to be met in addition to those referred to here.

2 General Requirements

2.1 Mandatory Capabilities


Chapter 2, Section 2.4, items relating to EGC messages, are applicable to Class 2 and Class 3
LPMESs, but only for reception of FleetNETSM messages; that is, reception of SafetyNETSM is not
mandatory. Class 2 and Class 3 LPMESs should be capable of receiving EGC messages which are
not classified as either SafetyNETSM or FleetNETSM, namely 'All Mobiles call' (General call) and
'INMARSAT System message', but reception of such messages may be inhibited by the user.

2.2 Return Link Budget


The minimum MES EIRP of 5.5 dBW used in the return link budget calculation is derived empirically
using the results of low power MES test and a target fading margin of 4dB for 95% availability.
Other factors used in the link budget analysis are as follows :-

a) A Rician channel with C/M=10 dB for a land mobile environment

b) A target Packet Error Rate (PER) of 5% for packet length of 128 bytes

c) An LES’s G/T of 32 dBK.

Table 1: Return Link Budget for Low Power C MES

Inmarsat-3 Global Beam


(at 15° elevation angle)
Mobile Earth Station EIRP (dBW) 5.50
Path Loss (dB) 189.00
Absorption Loss (dB) 0.40
Satellite G/T (dB/K) -4.00
Mean Uplink C/No (dBHz) 40.70
Satellite Io (dBW/Hz) -69.00
Satellite C/Io (dBHz) 41.10
Transponder Gain (dB) 156.00

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 3
Chapter 10: Technical Requirements for Low Power Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Satellite Mean EIRP (dBW) -27.90


Path Loss (dB) 195.70
Absorption Loss (dB) 0.50
LES G/T (dB/K) 32.00
Mean Downlink C/No (dBHz) 36.50
Mean Unfaded C/No (dBHz) 34.13

Interference Loss (dB) 0.50


Total RSS random loss (95%) (dB) 0.77
Overall C/No (dBHz) 32.86
Overall Eb/No ( PER=5%) 5.06

3 RF Subsystem Requirements

3.2 Antenna Requirements


It is permissible for LPMESs to use antennas with radiation patterns optimised for a defined coverage
region. Any restrictions in coverage should be made known to prospective users of the equipment
(see Chapter 2, Section 3.2.2).

Applications for the type or case approval of LPMESs equipped with special antennas should be
accompanied by detailed antenna characteristics and supporting information, including the proposed
operating environment and location(s), to justify the use of a special antenna configuration (see
Chapter 2, Section 3.2.3). Technical requirements for alternative antenna configurations are
presented in Chapter 3.

3.3 Receiver RF Requirements


As Chapter 2, Section 3.3, except where indicated below.

3.3.1 Gain-to-Noise Temperature Ratio


Using an unstabilized, unsteered antenna, the minimum gain profile and the receiver system noise
temperature, including the antenna, shall be such that the G/T ratio is not less than that described by
the minimum G/T profile (elevation) in the frequency band 1525.0 to 1559.0 MHz and represented as:

G/T ≥ -24-1.5sin(θ-5) dB/K + 5° ≤ θ ≤ +90°

where θ is the elevation angle in degrees with zenith at +90°.

The G/T requirements shall be met under the conditions specified in Chapter 2 Section 3.3.1.

3.3.3 Immunity to Out of Band Signals


As Chapter 2, Section 3.3.3, except that the frequency band of emissions is extended as follows:

30 MHz to 1400 MHz and

1626.5 MHz to 4000 MHz

The flux density of –15 dBW/m2 remains unchanged.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 4
Chapter 10: Technical Requirements for Low Power Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

A maximum of 6 identified spurious responses to signals at a flux density of –45 dBW/m2 are
permitted in the above bands.

Consideration will be given to relaxing this requirement for the special case of receiver image
response, providing that the image band lies at a frequency unlikely to contain interfering signals at
such a level as to increase the packet error probability. As a guideline, it is recommended that the
image rejection should not be less than 60dB. Where doubt exists, the higher limit of -45 dBW/m2
shall apply.

3.4 Transmitter RF Requirements


As Chapter 2, Section 3.4, except where indicated below.

3.4.1 EIRP
For the case of LPMESs intended for general Land Mobile use, the requirements are as stated in
Chapter 2, Section 3.4.1, except that the minimum EIRP that must be maintained is given as follows:

EIRP ≥ 5.5 dBW for elevation angles not less than 15 °.

For LPMESs with optimised antennas, the minimum EIRP need only be maintained for the applicable
antenna elevation angles, with due regard being given to the anticipated tilting of the antenna.

The maximum EIRP radiated by the LPMES in any direction shall not exceed +16 dBW. The variation
in EIRP due to all causes shall be such as to maintain the EIRP towards the satellite within these
specified limits under all operational conditions.

3.4.3 Transmitter Off Power Level


In addition to the requirements of Chapter 2, Section 3.4.3, the LPMES shall not radiate more than the
following power levels when in the idle (not transmitting) state:

– 87 dBW total power in the band 100 kHz to 1000 MHz

– 77 dBW total power in the band 1000 MHz to 4000 MHz

When the transmitter is off spurious and noise EIRP between 1500 - 1800 MHz should not exceed the
limits specified in Figure 2-4 of Chapter 2, except where specified in the following table.

Table 2: Transmitter “OFF” Narrow Band Emission Limits

Frequency Range (MHz) EIRP (dBW) Measurement Bandwidth (kHz)

960-1525 -72 100


1525-1559 -130 3
1605 -95.2 3
1605-1610 see note 1 3
1610-1626.5 -87.2 3
1626.5-1656.5 -63 3
1656.5-1661 see note 2 3
1661 - 10700 -72 100
10700-21200 -66 100

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 5
Chapter 10: Technical Requirements for Low Power Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

21200-40000 -60 100

Notes:

Linearly interpolated from -95.2 dBW in 3 KHz at 1605.0 MHz to -87.2 dBW in 3 KHz at 1610.0 MHz.

Linearly interpolated from -63 dBW in 3KHz at 1656.5 MHz to -87.2 dBW in 3 KHz at 1661.0 MHz

A spectrum envelope mask representing these limits for the frequency range between 1500 and 1800
MHz is shown in Figure 1.

Figure 1: Sprectrum Envelope for Transmitter “OFF” Emission Limits

-40

-50

-60
Maximum EIRP/3Khz (dBW)

-70

-80

-90

-100

-110

-120

-130

-140
1500 1550 1600 1650 1700 1750 1800

Frequency in MHz

3.4.4 Transmitter On Spurious Outputs


As Chapter 2, Section 3.4.4 with the additional requirement that the total radiated power (excluding
harmonics) from the LPMES in the following bands should not exceed the levels specified below:

Frequency Band Total Radiated Power


100 kHz – 1000 MHz –66 dBW
1000 MHz – 1626.5 MHz –60 dBW
MHz – 4000 MHz –60 dBW

In addition the spurious within the frequency range between 960 MHz and 40000 MHz shall not
exceed the following values:

Table 3: Transmitter "ON" Composite Emission Limits

Frequency Range (MHz) EIRP (dBW) Measurement Bandwidth (kHz)

1500 - 1525 -71 100

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 6
Chapter 10: Technical Requirements for Low Power Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1525 - 1559 -130 3


1605.5 -97 3
1620 -63 3
1626 -61 3
1626 - 1661 -48 3
1661 -61 3
1668 -63 3
1690 -77 3
1690 - 1800 -71 100
1800 - 3400 -71 (note 1) 100
3400 - 10700 -65 (note 2) 100
10700 - 21200 -59 100
21200 - 40000 -53 100

Notes:

1) In the band 3253.0 MHz to 3321.0 MHz the maximum EIRP in one, and only one, 100 KHz
measurement bandwidth shall not exceed -38 dBW. Elsewhere in this band the power limit in
this table shall be applied.

2) In each of the bands 4879.5 to 4981.5 MHz, 6506.0 to 6642.0 MHz and 8132.5 to 8302.5 MHz
the maximum EIRP in one, and only one, 100 KHz measurement bandwidth shall not exceed -
48 dBW. In band 9759.0 to 9963.0 MHz the maximum power in one, and only one, 100 KHz
measurement bandwidth shall not exceed -59 dBW. Elsewhere in these bands the power limit
in this table shall be applied.

Figure 2 shows the spectrum envelope mask representing the above requirements for the frequency
range between 1500 and 1800 MHz.

Figure 2: Transmitter “ON” Spurious and Noise EIRP Limits, 1500-1800 Mhz

-40

-50

-60
Maximum EIRP/3KHz (dBW)

-70

-80

-90

-100

-110

-120

-130

-140
1500 1550 1600 1650 1700 1750 1800

Frequency in MHz

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 7
Chapter 10: Technical Requirements for Low Power Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.4.5 Harmonic Outputs


Harmonic output limits are covered by the requirements of Section 3.4.4.

3.4.6 Phase Noise


The limits are as in Chapter 2, Section 3.4.6. This specification should be met under the vibration
conditions set out in Chapter 2, Section 11.2.

Under the more severe vibration conditions specified for LPMESs in Section 11.2 (i) of this chapter,
consideration will be given to relaxation of the phase noise limits as specified below.

The phase noise induced on a carrier shall have a power density spectrum not exceeding the limit
mask defined in Table 4.

If discrete phase noise spectral components are included which exceed the limit mask, the sum of all
discrete and continuous spectral components between 10 Hz and 100 kHz from the carrier shall not
exceed 0.10 radians rms or –20 dBc in SSB. The limit mask for transmitted Phase Noise at L-band is
shown plotted in Figure 3.

Table 4: MES Transmit Phase Noise Limits

Offset from Carrier SSB Phase Noise limit, dBc (in 1 Hz bandwidth)

10 Hz to 100 Hz -3-28Log10(f)
100 Hz to 5 kHz -59
5 kHz to 100 kHz +15-20Log10(f)

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 8
Chapter 10: Technical Requirements for Low Power Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 3: MES Induced Single Sideband Phase Noise Power in 1Hz Bandwidth

-20

-30
SSB PHASE NOISE POWER IN 1 Hz (dBc)

-40

-50

-60

-70

-80

-90
101 102 103 104 105
OFFSET FROM CARRIER (Hz)

3.4.7 Transmitter Tuning


The transmitting system shall be capable of transmitting any channel in the band 1626.5 to 1646.5
MHz. Channel assignments are in 5 kHz steps starting at 1626.50000 MHz and extending up to
1646.50000 MHz.

3.4.8 Frequency Accuracy and Stability


As Chapter 2, Section 3.4.8.

4 Receiver Performance
As Chapter 2, Section 4, except performance under blockage conditions is as described in Section
4.7 below.

4.7 Performance Under Blockage Conditions

4.7.1 General
The LPMES is required to comply with the performance requirements of the maritime fading channel
(Chapter 2, Sections 4.5 & 4.6). This ensures that performance of the LPMES will be satisfactory in
the presence of short random fades due to blockage and multipath effects prevalent in many land
mobile channels including usage on inland waters.

Land mobile conditions also produce examples of blockage lasting from seconds to many minutes,
and additional performance checks are necessary to ensure adequate performance over the full
range of land mobile channels.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 9
Chapter 10: Technical Requirements for Low Power Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

In the following sections, the precise model for blockage is defined, and performance requirements
are given for both short term repetitive blockage and long term blockage situations.

4.7.2 Channel Model for Blockage.


For the purpose of these performance requirements, the channel has two states — an un-blocked
state and a blocked state. The different channel situations are defined by assuming that the channel
switches between one state and the other in a particular time sequence.

1) Definition of un-blocked state

The "un-blocked state" of the channel is the channel as defined in Chapter 2, Section 4.4, with
the C/M ratio set to infinity, not 7dB.

2) Definition of blocked state

In the "blocked" state no signal from the satellite reaches the receiving antenna. The only input
to the receiver is the system noise from the antenna, LNA, etc.

Thus the blockage situation is defined by the power-flux density of the carrier at the antenna in the
unblocked state, and the time sequence in which the channel switches states.

4.7.3 Performance with Short Term Repetitive Blockage


For short term repetitive blockage, the time sequence is a repeating period of 8.9s containing a
blocked period of B seconds and an unblocked period of (8.9 – B) seconds.

Note that this period is slightly longer than the 8.64s signal frame and the blockage will therefore
occupy all possible positions in the frame over a period of time.

Performance requirements for a 128 byte packet error probability PEP(128) against different values of
B seconds and unblocked power flux density at the antenna are given in the following table:

PFD for PEP(128) (dBW/m2) B = 2s B= 2.7s C/No assuming G/T = -23 dB/K

–145.5 0.1 not specified 35.0


–144.5 0.02 0.1 36.0

Note: In the performance requirements above, the value of the Doppler variation is +/–50Hz over 10s.

4.7.4 Performance With Long Term Blockage


During periods of blockage lasting up to several minutes, information will be lost. The critical
parameter used to minimise information loss is the re-acquisition time measured from the end of
blockage. For performance in single events of blockage, the relevant parameters are as follows:

1) the length of blockage, B seconds.

2) the frequency difference between the received carrier immediately prior to the start of blockage,
and at the end of blockage, 'dF' Hz.

3) the time taken between end of blockage and re-acquisition of the carrier and timing (clock
recovery), Traq seconds.

Range of blockage B Limits of dF Traq

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 10
Chapter 10: Technical Requirements for Low Power Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

5s to 25s +/–100Hz <1 sec.

25s to 90s +/–200Hz 4s max : 2 secs average

90s to 180s +/–500Hz 10s max : 5 secs average

Note: The above table is based on swept acquisition at 100Hz/s after the first 25s of blockage.

5 Transmitter Performance
As Chapter 2, Section 5.

6 Access Control Requirements


As Chapter 2, Section 6, except where indicated below.

6.2.2 Random Access and Retransmission Slot Selection


Same as 6.2.2 of Chapter 2.

6.2.3 Signalling Channel Access Restriction


In addition to Chapter 2, Section 6.2.4, an LPMES shall check the LES service descriptor of the LES
TDM bulletin board to validate that the LES supports the Low Power C MES service before attempting
to access the signalling channel. The LPSES shall select the signalling channel in the following order:

- A signalling channel with low power C bit set in its signalling channel descriptor, if available.

- A general signalling channel for unreserved access.

The user interface of a LPMES shall have the capability to ensure that only the LESs capable of
supporting lower power C service, as indicated in the LES service status, will be visible for the user to
select.

6.5 Ocean Region Registration Procedures


As Chapter 2, Section 6.5 with the following exceptions.

6.5.1 Logging In
If an MES cannot tune to its preferred ocean region, it shall not automatically scan NCS common
channels. If the preferred NCS common channel is not available, the operator shall be alerted who
may then tune to another common channel or request the terminal to scan, otherwise the terminal
should continue to tune to the preferred NCS common channel.

The LPMES shall set the low power C MES service bit in the class field of a login packet.

7 Message Processing Requirements


As Chapter 2, Section 7.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 11
Chapter 10: Technical Requirements for Low Power Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

8 Alerting Functions
Land Mobile Earth Stations are not permitted to send maritime distress alerts. Maritime
Distress Alerts must be inhibited on MESs intended for land use.

This inhibition should be implemented in the DCE, i.e. it should not be possible for any code on the
DCE/DTE interface to trigger a maritime distress alert. LPMESs should not send any packet with the
packet 'priority' bit set. This applies to distress alerts and distress priority assignment requests.
However, Land Mobile terminals may optionally have the capability of sending 'Land Mobile Alerts'.
Land Mobile Alerts are defined as using the distress alerting protocol, but with the alert packet 'priority'
bit set to zero. The remaining packet format is similar to the maritime case, except some of the packet
contents are redefined for land mobile (see Volume 4, Chapter 11).

The alerting requirements detailed in Chapter 2 also apply to Land Mobile Alerting, (where this is
provided) except for the cases listed in the following sections.

Use of the Land Mobile Alerting service is generally only available to land mobile users on a pre-
arranged basis. Not all LESs will accept Land Mobile Alerts.

It is recommended that all LPMESs are fitted with the Land Mobile Alerting function, but with the
capability of enabling and disabling the function at the LPMES by some means not easily accessible
to the user (e.g. internal switch or secret software code). A common LPMES model may then be
supplied irrespective of whether or not the alerting function is required. Supplying LPMESs with the
alerting function initially disabled will discourage mobile users from attempting to send alerts where no
prior arrangements for routing or service have been made.

Note: Additionally, or as an alternative to sending Land Mobile Alerts using the 'Distress Alerting'
protocol, emergency messages may also be conveyed by Position Report. Position Reports
use the Data Reporting protocol, and are described in Volume 2.

8.1 LES Service


Land Mobile Alerts should only be sent to LESs which have the 'LES Services' field in the Bulletin
Board packet set to indicate Land Mobile service is provided (refer to Volume 4, Chapter 2, Section
3.1.4.6).

If an attempt is made to send an alert when the LES Bulletin Board indicates that no Land Mobile
Alerting service is available, a message or indication to that effect should be displayed to the mobile
user.

8.2 Signalling Channel Precedence


The use of a 'Land Mobile Alerting' bit in the Signalling Channel Descriptor (SCD) packet [previously
spare and set to zero] allows dedicated signalling channel(s) for Land Mobile Alerts if required (refer
to Volume 4, Chapter 2, Section 3.2 ).

The precedence for using these or other available channels for live Land Mobile Alerts are as follows:

1) LES dedicated Land Mobile Alerting channel(s) if available;

2) LES general signalling channels;

3) NCS dedicated Land Mobile Alerting channel(s) if available;

4) NCS general signalling channels.

The above categories of channel all refer to channels whose 'Land Mobile Alerting' bit have been set.
Land Mobile Alerts should not be sent on other channels.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 12
Chapter 10: Technical Requirements for Low Power Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

8.3 Land Mobile Alert Generator


The Land Mobile Alert packet is as defined in Volume 4, Chapter 11. The contents are as follows:

(1) MES ID

(2) LES ID

(3) Land Position Coordinates (defined differently from maritime)

(4) A field which is set to indicate Land Mobile format

(5) A flag to indicate if following fields are user defined

(6) Nature of Alert

(7) A flag to indicate if alert has been generated automatically

(8) Time of position

(9) Speed of vehicle

(10) Direction of travel

(11) Extra Information (user defined)

Normally this information, with the possible exception of (6), would be preset or automatically
updated, but means for manual updating of (2), (3), (6), (10) and (11) may be provided.

8.4 Alert Activation


Means must be provided (mechanical and/or electrical/software) to prevent the unintentional
transmission of "live" Land Mobile alerts for all possible methods of activation.

9 Testing Functions
As Chapter 2, Section 9, with the following exceptions:

9.3 Performance Verification


A performance verification test (PVT) is carried out as part of the installation procedure and at other
times to check performance. This PVT includes an alert test. For LPMESs a Land Mobile Alert (test)
should be sent.

This applies irrespective of whether or not the LPMES is fitted with the Land Mobile Alerting option.

The type field for this packet should be 06H ('alert test') and the packet contents should be as defined
for Land Mobile Alerts (refer to Volume 4, Chapter 11). Fields not containing valid information should
be set to zero. Note that the 'priority' bit for alert test packets should always be zero.

No distress alert test prompt shall be sent to the operator. The distress alert test shall be activated
automatically and immediately after receiving the distress test request packet from the LES.

A Land Mobile Alert Test sent during a PVT should follow the same procedure with respect to
signalling channel priorities as a real alert (refer to Sections 8.1 and 8.2 above), with the exception
that the 'Land Mobile Alerting' bit in the 'LES Services' field of the Bulletin Board and in the Signalling

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 13
Chapter 10: Technical Requirements for Low Power Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Channel Descriptor packet need not be set for the test packet to be sent. Alert tests during PVTs
should not be sent to the NCS.

10 Electromagnetic Compatibility
As Chapter 2, Section 10.

11 Environmental Conditions

11.1 Purpose and Applicability


The following environmental conditions are based on inputs received from a number of different
countries and are intended to be indicative rather than a comprehensive set of conditions.

It is recommended that Land Mobile Earth Stations which are to be type approved for general use
comply with the performance requirements under these environmental conditions.

At the discretion of Inmarsat, LPMES models may be tested to an alternative set of environmental
conditions. The MES manufacturer may propose such conditions, but these should be adequate to
confirm proper operation and performance in the environments in which the LPMES is likely to be
used.

In any case, the range of environmental conditions over which the LPMES is designed to fulfil the
Inmarsat requirements shall be specified by the manufacturer and made known to prospective users
of the LPMES model.

It should be noted that many countries and regions have their own requirements, in respect of
environmental and other testing, which may differ from those given here.

The environmental conditions for Internally Mounted Equipment (IME) generally apply to both DCE
and DTE (see Chapter 2, Section 2.2 for definition of these terms). However, where a non-dedicated
DTE (such as a portable PC) is to be supplied as part of the LPMES model, alternative environmental
performance for the DTE may be acceptable. When selecting such a DTE it is strongly recommended
that particular regard is given to performance with the relatively high levels of vibration and extremes
of temperature expected in typical land mobile environments.

11.2 Recommended Environmental Conditions For A Land Mobile Earth Station

Note:

EME - Externally Mounted Equipment.

IME - Internally Mounted Equipment.

(a) Ambient Temperature: Operational: –25°C to +50°C +solar radiation (EME)


–25°C to +55°C (IME)

Survival with power on 1: –40°C to +80°C

(b) Relative Humidity: up to 95% at 40°C

(c) Ice 1: up to 25 mm of ice for EME

(d) Rain: 5 cm/hour, droplet size 0.5 to 4.5 mm, wind speed
as below (EME).

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 14
Chapter 10: Technical Requirements for Low Power Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(e) Wind: Relative wind speeds up to 200 km/ hr (EME)

(f) Solar Radiation: (EME)

Infra-red radiation: 500W/m2

(g) Power Supply: Maximum voltage of 1.3 times nominal battery


rating. Minimum voltage of 0.9 times the nominal
battery rating. (These requirements are for a lead
acid battery, 12 or 24 volts nominal.)

Alternator whine in the form of a saw tooth wave-


form 0.2Vp-p, induced on the supply at
frequencies from 300 to 3400 Hz.

(h) Vibration : Survival1 : Random vibration:

5 to 20 Hz: 0.05 g2/Hz


20 to 150 Hz: –3dB/oct. (1.7 g rms)

Vibration to be performed for a period of 2 hours


in each of 3 mutually perpendicular axes.

(i) Vibration : Operational 2 : Random vibration:

5 to 20 Hz: 0.005 g2/Hz


20 to 150 Hz: –3dB/oct. (0.5 g rms)

Performance shall not be degraded under


vibration in each of 3 mutually perpendicular
axes.

(j) Mechanical Shock 1 : Half sine wave shock with a peak of 20g and a
duration of 11 ms.

A total of 18 shocks shall be performed (3 shocks


in each of three mutually perpendicular axes).

(k) Induced Acceleration: Maximum tangential or linear acceleration of up to


2g.

(l) Velocity: Maximum velocity up to 140 km/hr.

(m) Vehicle Motion: [TBD] Relevant only for steered antennas.

(n) Antenna Inclinations: Not specified.

Note 1: Indicates survival recommendations only. The MES is NOT expected to operate within
specification under these conditions, but the MES performance after they are removed
should not be degraded.

Note 2: See Section 3.4.6.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 15
Chapter 10: Technical Requirements for Low Power Land Mobile Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 11: Technical Requirements for Low Power


Ship Earth Station

Contents

1 Introduction ............................................................................ 3

2 General Requirements ............................................................. 3


2.5 Return Link Budget ..............................................................................................3
Table 1: Return Link Budget For Low Power C SES...............................................3

3 RF Subsystem Requirements ................................................... 4


3.2 Antenna Requirements .....................................................................................4
3.3 Receiver RF Requirements ...............................................................................4
3.3.1 Gain-to-Noise Temperature Ratio ..................................................................4
3.3.3 Immunity to Out of Band Signals ....................................................................4
3.4 Transmitter RF Requirements ...........................................................................5
3.4.1 EIRP...............................................................................................................5
3.4.3 Transmitter Off Power Level ..........................................................................5
Table 2: Transmitter “OFF” Narrow Band Emission Limits ......................................5
Figure 1: Sprectrum Envelope for Transmitter “OFF” Emission Limits ...................6
3.4.4 Transmitter On Spurious Outputs ..................................................................6
Table 3: Transmitter "On" Composite Emission Limits ............................................6
Figure 2: Transmitter “ON” Spurious and Noise EIRP Limits, 1500-1800 Mhz .......7

4 Receiver Performance ............................................................. 8

5 Transmitter Performance ......................................................... 8

6 Access Control Requirements ................................................. 8


6.2.4 Signalling Channel Access Restriction ...........................................................8
6.5 Ocean Region Registration Procedures ............................................................8
6.5.1 Logging In ......................................................................................................8

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 1
Chapter 11: Technical Requirements for Low Power Ship Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

7 Message Processing Requirements ......................................... 8

8 Distress Calling ...................................................................... 8

9 Testing Functions ................................................................... 8

10 Electromagnetic Compatibility ............................................... 9

11 Environmental Conditions ..................................................... 9


11.1 Purpose...........................................................................................................9
11.2 Environmental Conditions for Inmarsat-C LPC SESs Suitable for General Use
........................................................................................................................ 9

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 2
Chapter 11: Technical Requirements for Low Power Ship Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
This chapter describes the requirements and recommendations for a Low Power Ship Earth Station
(LPSES), which is a Mobile Earth Station designed specifically for use in a maritime environment with
a satellite elevation angle of at least 5 degree . The reduction of transmit power of the LPSES has
been made possible because of better link margin provided by the Inmarsat 3rd generation satellites
in the return direction and the generally better than expected performance of an LES’s receiving
chain.

The characteristics of a Low Power SES are generally the same as those of a Mobile Earth Station as
described in Chapter 2 of this volume. This type of SES is not capable of transmitting distress calls
and does not necessarily comply with the technical requirements of IMO and IEC. Inmarsat does not
require DTE for these SESs to comply with any IMO/IEC requirements.

The purpose of this chapter is to point out the differences that are applicable for low power SES
equipment. The numbering of sections in this chapter follow those of Chapter 2 and where a section
of Chapter 2 is not mentioned, it must be assumed that the original Chapter 2 requirement still
applies.

It should not be assumed that this Chapter covers any national or regional requirements, which may
have to be met in addition to those referred to here.

2 General Requirements
As Chapter 2, Section 2 and the new sub-section as indicated below.

2.5 Return Link Budget


The minimum MES EIRP of 7 dBW at the edge of coverage of 5 degree elevation shall be expected to
provided a packet error probability of 5 % as shown in Table 1 on the return link budget for low power
C SES.

Other factors used in the link budget analysis are as follows:-

a) A Rician channel with C/M=7 dB, f(3 dB)=0.7 Hz for a maritime environment

b) A target Packet Error Rate (PER) of 5% for packet length of 128 bytes

c) An LES’s G/T of 32 dB/K

Table 1: Return Link Budget For Low Power C SES

Inmarsat-3 Global Beam


(at 5° elevation angle)
Mobile Earth Station EIRP (dBW) 7.0
Path Loss (dB) 189.00
Absorption Loss (dB) 0.40
Satellite G/T (dB/K) -4.00
Mean Uplink C/No (dBHz) 42.05
Satellite Io (dBW/Hz) -69.00
Satellite C/Io (dBHz) 42.45
Transponder Gain (dB) 156.00

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 3
Chapter 11: Technical Requirements for Low Power Ship Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Satellite Mean EIRP (dBW) -26.55


Path Loss (dB) 195.91
Absorption Loss (dB) 0.50
LES G/T (dB/K) 32.00
Mean Downlink C/No (dBHz) 37.64
Mean Unfaded C/No (dBHz) 35.36

Interference Loss (dB) 0.50


Total RSS random loss (95%) (dB) 0.77
Overall C/No (dBHz) 34.1
Overall Eb/No ( PER=5%) 6.2

3 RF Subsystem Requirements

3.2 Antenna Requirements


As Chapter 2, Section 3.2

3.3 Receiver RF Requirements


As Chapter 2, Section 3.3, except where indicated below.

3.3.1 Gain-to-Noise Temperature Ratio


Using an unstabilized, unsteered antenna, the minimum gain profile and the receiver system noise
temperature, including the antenna, shall be such that the G/T ratio is not less than that described by
the minimum G/T profile (elevation) in the frequency band 1530.0 to 1545.0 MHz and represented as:

G/T ≥ -23.7-1.5sin(θ-5) dB/K + 5° ≤ θ ≤ +90°

G/T ≥ -27.7+ 4cos[4.5(θ-5)] dB/K -15o ≤ θ ≤ +5°

where ? is the elevation angle in degrees with zenith at +90°.

The G/T requirements shall be met under the conditions specified in Chapter 2 Section 3.3.1.

3.3.3 Immunity to Out of Band Signals


As Chapter 2, Section 3.3.3, except that the frequency band of emissions is extended as follows:

30 MHz to 1400 MHz and

1626.5 MHz to 4000 MHz

The flux density of –15 dBW/m2 remains unchanged.

A maximum of 6 identified spurious responses to signals at a flux density of –45 dBW/m2 are
permitted in the above bands.

Consideration will be given to relaxing this requirement for the special case of receiver image
response, providing that the image band lies at a frequency unlikely to contain interfering signals at

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 4
Chapter 11: Technical Requirements for Low Power Ship Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

such a level as to increase the packet error probability. As a guideline, it is recommended that the
image rejection should not be less than 60dB. Where doubt exists, the higher limit of -45 dBW/m2
shall apply.

3.4 Transmitter RF Requirements


As Chapter 2, Section 3.4, except where indicated below.

3.4.1 EIRP
For the case of LPSESs intended for general Maritime use, the requirements are as stated in Chapter
2, Section 3.4.1, except that the minimum EIRP that must be maintained is given as follows :

EIRP ≥ 7.0 –1.5sin(θ-5) dBW +5 ° ≤ θ ≤ +90 o

EIRP ≥ 5.0 +2cos[4.5(θ-5)] dBW -15 ° ≤ θ ≤ +5 o

Where θ is the elevation angle in degrees with zenith at +90

The maximum EIRP radiated by the LPSES in any direction shall not exceed +16 dBW. The variation
in EIRP due to all causes shall be such as to maintain the EIRP towards the satellite within these
specified limits under all operational conditions.

3.4.3 Transmitter Off Power Level


In addition to the requirements of Chapter 2, Section 3.4.3, the LPSES shall not radiate more than the
following power levels when in the idle (not transmitting) state:

– 87 dBW total power in the band 100 kHz to 1000 MHz

– 77 dBW total power in the band 1000 MHz to 4000 MHz

When the transmitter is off spurious and noise EIRP between 1500 - 1800 MHz should not exceed the
limits specified in Figure 4 of Chapter 2, except where specified in the following table.

Table 2: Transmitter “OFF” Narrow Band Emission Limits

Frequency Range (MHz) EIRP (dBW) Measurement Bandwidth (kHz)

960-1525 -72 100


1525-1559 -130 3
1605 -95.2 3
1605-1610 see note 1 3
1610-1626.5 -87.2 3
1626.5-1656.5 -63 3
1656.5-1661 see note 2 3
1661 - 10700 -72 100
10700-21200 -66 100
21200-40000 -60 100

Notes:

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 5
Chapter 11: Technical Requirements for Low Power Ship Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1) Linearly interpolated from -95.2 dBW in 3 KHz at 1605.0 MHz to -87.2 dBW in 3 KHz at 1610.0
MHz.

2) Linearly interpolated from -63 dBW in 3KHz at 1656.5 MHz to -87.2 dBW in 3 KHz at 1661.0
MHz

A spectrum envelope mask representing these limits for the frequency range between 1500 and 1800
MHz is shown in Figure 1

Figure 1: Sprectrum Envelope for Transmitter “OFF” Emission Limits

-40

-50

-60
Maximum EIRP/3Khz (dBW)

-70

-80

-90

-100

-110

-120

-130

-140
1500 1550 1600 1650 1700 1750 1800

Frequency in MHz

3.4.4 Transmitter On Spurious Outputs


As Chapter 2, Section 3.4.4 with the additional requirement that the total radiated power (excluding
harmonics) from the LPSES in the following bands should not exceed the levels specified below:

Frequency Band Total Radiated Power


100 kHz – 1000 MHz –66 dBW
1000 MHz – 1626.5 MHz –60 dBW
MHz – 4000 MHz –60 dBW

In addition the spurious within the frequency range between 960 MHz and 40000 MHz shall not
exceed the following values:

Table 3: Transmitter "On" Composite Emission Limits

Frequency Range (MHz) EIRP (dBW) Measurement Bandwidth (kHz)

1500 - 1525 -71 100


1525 - 1559 -130 3
1605.5 -97 3

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 6
Chapter 11: Technical Requirements for Low Power Ship Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1620 -63 3
1626 -61 3
1626 - 1661 -48 3
1661 -61 3
1668 -63 3
1690 -77 3
1690 - 1800 -71 100
1800 - 3400 -71 (note 1) 100
3400 - 10700 -65 (note 2) 100
10700 - 21200 -59 100
21200 - 40000 -53 100

Notes:

1) In the band 3253.0 MHz to 3321.0 MHz the maximum EIRP in one, and only one, 100 KHz
measurement bandwidth shall not exceed -38 dBW. Elsewhere in this band the power limit in
this table shall be applied.

2) In each of the bands 4879.5 to 4981.5 MHz, 6506.0 to 6642.0 MHz and 8132.5 to 8302.5 MHz
the maximum EIRP in one, and only one, 100 KHz measurement bandwidth shall not exceed -
48 dBW. In band 9759.0 to 9963.0 MHz the maximum power in one, and only one, 100 KHz
measurement bandwidth shall not exceed -59 dBW. Elsewhere in these bands the power limit
in this table shall be applied.

Figure 2 shows the spectrum envelope mask representing the above requirements for the frequency
range between 1500 and 1800 MHz.

Figure 2: Transmitter “ON” Spurious and Noise EIRP Limits, 1500-1800 Mhz

-40

-50

-60
Maximum EIRP/3KHz (dBW)

-70

-80

-90

-100

-110

-120

-130

-140
1500 1550 1600 1650 1700 1750 1800

Frequency in MHz

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 7
Chapter 11: Technical Requirements for Low Power Ship Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4 Receiver Performance
As Chapter 2, Section 4

5 Transmitter Performance
As Chapter 2, Section 5.

6 Access Control Requirements


As Chapter 2, Section 6, except where indicated below.

6.2.4 Signalling Channel Access Restriction


In addition to Chapter 2, Section 6.2.4, an LPSES shall check the LES service descriptor of the LES
TDM bulletin board to validate that the LES supports the Low Power C MES service before attempting
to access the signalling channel. The LPSES shall select the signalling channel in the following order:

- A signalling channel with low power C bit set in its signalling channel descriptor, if available.

- A general signalling channel for unreserved access.

The user interface of a LPSES shall have the capability to ensure that only the LESs capable of
supporting lower power C service, as indicated in the LES service status, will be visible for the user to
select.

6.5 Ocean Region Registration Procedures


As Chapter 2, Section 6.5 with the following exceptions.

6.5.1 Logging In
If an MES cannot tune to its preferred ocean region, it shall not, as a default configuration setting, be
able to automatically scan NCS common channels. If the preferred NCS common channel is not
available, the operator shall be alerted who may then tune to another common channel or request the
terminal to scan, otherwise the terminal should continue to tune to the preferred NCS common
channel. However, if an LPSES were configured to allow automatically NCS common channel
scaning, it shall be able to automatcially scan and login to other region if the preferred NCS common
channel is not available.

The LPSES shall set the low power C MES service bit in the class field of a login packet.

7 Message Processing Requirements


As Chapter 2, Section 7.

8 Distress Calling
Neither Distress Alert nor Distress Priority Message transmission shall be possible from the basic
LPSES described in this Chapter.

9 Testing Functions

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 8
Chapter 11: Technical Requirements for Low Power Ship Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

As Chapter 2, Section 9, but with the with the following additions:

Alarms and Indications

When a display device is required, the following alarms and indications must be provided:

(i) SES fault indication: Chapter 2, Section 9 refers;

(ii) Loss of receiver synchronisation: Chapter 2, Section 7.3.2 refers; and

(iii) SES transmitting: Chapter 2, Section 7.3.2 (b) refers.

Additional alarms and indications may be provided at the manufacturer's discretion.

10 Electromagnetic Compatibility
As Chapter 2, Section 10.

11 Environmental Conditions

11.1 Purpose
The purpose of this section is to define the mandatory minimum environmental conditions for SESs
intended for maritime use which are to be type approved as suitable for operation within the
INMARSAT system.

11.2 Environmental Conditions for Inmarsat-C LPC SESs Suitable for General Use
The following specification is mandatory for General Maritime LPC SESs. Models of SES which are to
be type approved as suitable for maritime use within the INMARSAT system shall be designed so as
to operate over the following range of environmental conditions:

EME - Externally Mounted Equipment

IME - Internally Mounted Equipment

(a) Ambient Temperature: –35°C to +55°C (EME)


0°C to +45°C (IME)

(b) Relative Humidity: up to 95% at +40°C;

(c) Spray: solid droplets from any direction (EME);

(d) Ice: up to 25mm of ice (EME);

(e) Precipitation: up to 100mm/hour (EME);

(f) Wind: normal operation with relative average wind


speeds up to 100 knots (EME);

(g) Solar Radiation: Maximum flux density 1200 W/m2

Spectral composition:

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 9
Chapter 11: Technical Requirements for Low Power Ship Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Infra Red 51%


Visible 44.5%
Ultra Violet 4.5%

(h) Prime Power Variations:

AC Mains Supply: frequency ±6%


voltage ±10%

DC Mains Supply: voltage +10%, –20%

Battery Supply: voltage +35% (recharge),


–20% (discharge) of nominal;

(i) Vibration:

Frequency Range (Hz) Level

2 – 10 2.54mm peak amplitude

10 – 100 1.0 g peak acceleration

See Figure 5-1, curve (a).


Note: 1g = 9.807 m/s2

Acceptable alternative levels for Internally Mounted Equipment only:

Frequency Range (Hz) Level

2 – 15.8 1.00mm peak amplitude

15.8 – 100 1.0 g peak acceleration

See Figure 5-1, curve (b)

During type approval, certain tests that are required to be conducted under vibration conditions
may be performed using pink noise vibration spectra instead of the sinusoidal swept frequency
range specified above. Refer to "Type Approval Procedures for Inmarsat-C Mobile Earth
Stations", which is available from Inmarsat;

Note: Consideration will be given to the relaxation of these conditions if necessary, in respect
of a printer if this is an integral part of the equipment (IME only). An example of acceptable
minimum conditions with respect to printer operation is given below:

Frequency Range (Hz) Level

2 – 13.6 0.4mm peak amplitude

13.6 – 50 0.3 g peak acceleration

See Figure 5-1, curve (c).

(j) Antenna Inclinations: Tilt in any direction up to 20° from horizontal for
satellite elevations >5°;

(k) Induced Acceleration: Maximum tangential or linear acceleration of up to


1.2 g.

(l) Velocity: Maximum velocity up to 60 knots (110 km/hr)

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 10
Chapter 11: Technical Requirements for Low Power Ship Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 11 - Annex A: Technical Requirements for a


Non-SOLAS LPSES with Emergency Alert Calling

Contents

1 Introduction ............................................................................ 2

2 General Requirements ............................................................. 2

3 RF Subsystem Requirements ................................................... 2

4 Receiver Performance ............................................................. 2

5 Transmitter Performance ......................................................... 2

6 Access Control Requirements ................................................. 2

7 Message Processing Requirements ......................................... 2


7.3 Display Devices ................................................................................................2
7.3.2 Status Display ................................................................................................2
7.5 Ship Earth Station Memory Capacity Requirements .........................................2
7.5.2 Non-Volatile Memory (DCE) ...........................................................................2

8 Emergency Calling .................................................................. 3


8.1 Signalling Channel Priorities for Emergency Communication ...........................3

9 Testing Functions ................................................................... 3


9.5.1 Emergency Alarms ........................................................................................3
9.5.2 Other Alarms and Indications .........................................................................3

10 Electromagnetic Compatibility ............................................... 3

11 Environmental Conditions ..................................................... 4

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 1
Chapter 11 - Annex A: Technical Requirements for a Non-SOLAS LPSES with
Emergency Alert Calling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
This Annex describes the mandatory requirements for Non-SOLAS Inmarsat-C Low Power Ship Earth
Stations (LPSES) with emergency calling facilities.

The characteristics of an LPSES are generally the same as those of a Mobile Earth Station as
described in Chapter 2 and Chapter 11 of this volume. The purpose of this Annex is to point out the
differences that are applicable for Non-SOLAS LPSES with emergency calling facilities. The
numbering of sections in this Annex follows those of Chapter 2 and Chapter 11and where a Chapter 2
or Chapter 11 section is not included it must be assumed that the original Chapter 2 or the Chapter
11 requirements still apply. Unless stated otherwise the requirements for emergency calling and
testing functions (Section 8 and 9) follows that of Chapter 5 Annex A.

2 General Requirements
As Chapter 2, Section 2 and Chapter 11 Section 2.

3 RF Subsystem Requirements
As Chapter 2 and Chapter 11, Section 3.

4 Receiver Performance
As Chapter 2, Section 4.

5 Transmitter Performance
As Chapter 2, Section 5.

6 Access Control Requirements


As Chapter 2 and Chapter 11, Section 6.

7 Message Processing Requirements


As Chapter 2, Section 7.

7.3 Display Devices

7.3.2 Status Display


An indication of reception of a valid emergency alert acknowledgement from an LES following
transmission of an initial emergency alert by the SES shall be provided.

7.5 Ship Earth Station Memory Capacity Requirements

7.5.2 Non-Volatile Memory (DCE)


In addition to the information to be held in non-volatile memory described in Chapter 2, the following
information shall also be held in non-volatile memory:

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 2
Chapter 11 - Annex A: Technical Requirements for a Non-SOLAS LPSES with
Emergency Alert Calling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(c) Emergency alert parameters.

The parameters are the same as that for distress alert (see Annex A of Chapter 5, Section 8.2).

8 Emergency Calling
The emergency calling for Non-SOLAS LPSES adopts the same packet definition and protocol as
distress alert calling as Chapter 5 Annex A Section 8 except where indicated below.

8.1 Signalling Channel Priorities for Emergency Communication


Certain LESs and NCSs may be equipped with dedicated signalling channels for handling
emergency/distress alerts and distress priority From-Mobile message transfers. The priorities for
using these or other available channels for all live emergency/distress communications are as follows:

1- The selected LESs dedicated distress signalling channel(s) if available;

2- The selected LES low power C MES signalling channel(s) if available;

3- The selected LESs general signalling channels;

4- The NCSs dedicated distress signalling channel(s) if available;

5- The NCSs general signalling channels.

Note that dedicated emergency/distress signalling channels are channels for which only the maritime
distress bit has been set in the signalling channel descriptor.

When the Inmarsat-C NCS is operating under first generation satellite mode, the return link speed of
the NCS will fall back to 300 bps bit rate. Under this situation, an LPSES should send the emergency
alert packet (at 300 bps bit rate) to the NCS as the only choice. If the LPSES fails to receive a
Emergency Alert acknowledgement from the NCS after 2 MaxCD attempts, the operator will be
advised and the LPSES will scan and attempt to synchronise to an NCS in another ocean region .
The LPSES will make a number of attempts( MaxCD times for each of the other visible NCSs) to send
the distress alert before abandoning the call and informing the LPSES operator.

9 Testing Functions
As Chapter 5, Annex A, Section 9, except for the following:

9.5.1 Emergency Alarms


The inclusion of a common alarm and output is optional.

9.5.2 Other Alarms and Indications


The inclusion of a common alarm and output is optional.

10 Electromagnetic Compatibility
As Chapter 2, Section 10.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 3
Chapter 11 - Annex A: Technical Requirements for a Non-SOLAS LPSES with
Emergency Alert Calling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

11 Environmental Conditions
As Chapter 2, Section 11 and Chapter 5, Section 11.

Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 4
Chapter 11 - Annex A: Technical Requirements for a Non-SOLAS LPSES with
Emergency Alert Calling
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 1: Introduction and Overview

Contents

1 Introduction ............................................................................ 3
1.1 Document Structure ..........................................................................................3
1.2 NCS Site Interface ............................................................................................3

2 Functional Overview ................................................................ 4


2.1 Purpose of the NCS ..........................................................................................4
2.2 Scope of NCS ...................................................................................................4
2.2.1 MES Communications....................................................................................4
2.2.2 LES Communications.....................................................................................4
Figure 1: Block diagram of Network Coordination Station .......................................5
2.2.3 Coordination Functions ..................................................................................5
2.2.4 Frequency Allocation......................................................................................6
2.2.5 Network Administration ..................................................................................6
2.3 NCS Functions ..................................................................................................6
2.3.1 Access Control ...............................................................................................6
2.3.2 Network Coordination Functions ....................................................................6
2.3.3 Network Management Functions ...................................................................7
2.4 Communications Interfaces...............................................................................7
2.4.1 Satellite Channels ..........................................................................................7
2.4.2 Terrestrial Links .............................................................................................7
2.5 NCS Database ..................................................................................................8
2.6 Operational Facilities.........................................................................................8
2.6.1 Operator Interface ..........................................................................................8
2.6.2 Facilities Provided ..........................................................................................8
2.6.3 Interface with Inmarsat NOC ..........................................................................8
2.7 System Configuration and Reliability.................................................................8
2.8 System Design Considerations .........................................................................8

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 1


Chapter 1: Introduction and Overview
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.8.1 Number of LESs Supported ...........................................................................8


2.8.2 Number of Mobile Earth Station Supported....................................................9
2.8.3 Number of NCSs ............................................................................................9

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 2


Chapter 1: Introduction and Overview
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
Each Inmarsat ocean region is served by a Network Coordination Station (NCS) which manages
central resources. This technical specification provides a description of the functions to be performed
by the NCS and describes Inmarsat's operational requirements for the equipment and software
required to implement these functions.

1.1 Document Structure


The following information is provided in this part of the System Definition Manual:

This chapter provides an overview of the functions to be performed by the NCS and a summary of the
operational requirements.

Chapter 2 describes the functional requirements in more detail, including:

- the communication channels used by the NCS

- the functions performed in order to coordinate access to mobile earth stations (MESs)

- the functions performed in order to coordinate the allocation and utilization of Inmarsat-C
network resources

- the operator interface to be provided

- the database management functions performed by the NCS.

Chapter 3 describes the requirements to be met in order to ensure the continued satisfactory
operation of the NCS, including:

- requirements for the reliability of the equipment and software

- the maintenance facilities to be provided.

As well as complying with the requirements of this part of the System Definition Manual (Volume 3,
Part 4), an NCS operating in the Inmarsat-C system shall comply with all the relevant requirements of
the rest of the manual:

- Volume 1 System description

- Volume 2 User Services

- Volume 3 Earth station requirements

- Volume 4 Packet formats and usage

- Volume 5 Inmarsat-C SDL

The purpose of these technical requirements is to ensure that the NCSs providing Inmarsat-C
coordination services will perform adequately and will preserve the integrity of system operations.

1.2 NCS Site Interface


Each NCS will be installed at an earth station site that will contain an Inmarsat-C land earth station
(LES). The communications interfaces defined in this document infer that an IF interface with a
Inmarsat-A LES will be provided. It is not mandatory that the NCS be associated with an Inmarsat-A
LES, however the technical requirements pertaining to:

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 3


Chapter 1: Introduction and Overview
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(a) C-band,

(b) L-band, and

(c) AFC,

as described in "Technical Requirements for Inmarsat Standard-A Coast Earth Stations", Issue 5,
March 1989, will be provided at the NCS site.

2 Functional Overview
This section describes the purpose and scope of the NCS and provides an overview of its functions,
communications interfaces and operational requirements.

2.1 Purpose of the NCS


An NCS plays a key role within each ocean region and it is responsible for coordinating the access of
all LESs within the ocean region to individual MESs. The NCS performs its coordination activities for
all Inmarsat-C services. (Some of these services are optional for other operators as detailed in
Volume 1, Chapter 1, Section 1.)

In addition, the NCS shall coordinate the assignment of traffic channels to LESs. Inmarsat may
introduce demand assigned operation of LESs if operational conditions call for satellite power savings
to be made. The NCS shall, therefore, have the capability to perform all functions necessary to
support demand assigned operation.

2.2 Scope of NCS


Figure 1 is a block diagram of the NCS. It also illustrates the interfaces between the NCS and the
other Inmarsat-C network components within an ocean region.

The NCS consists of:

- Central Processing Unit (CPU). This runs all of the computer software necessary to implement
the functions specified for the NCS;

- Communications Interface. This consists of the modulators, demodulators and data modems
(DCEs) used for satellite and terrestrial communication.

- NCS Database. This contains all of the data structures required to perform the NCS functions;

- Operator Terminal Equipment. This consists of the workstation and terminal equipment
required to implement the operator interface.

2.2.1 MES Communications


The NCS communicates with the MESs within its ocean region by means of an NCS common channel
and signalling channels.

2.2.2 LES Communications


Each LES within a particular ocean region is linked to the NCS by means of an interstation signalling
link. This link also forwards distress alerts received by the NCS to destination LESs operating in a
demand assigned mode.

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 4


Chapter 1: Introduction and Overview
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: Block diagram of Network Coordination Station

IF Interface with associated


Earth Station

Control
C band MES Signalling
packets +
Channel Processing slot status

Control
See Note 1 Operator
terminals
Timing
L band LES TDM Generator
Demodulator
- Reference Tuning

NCS
L band Interstation Signalling Data DATABASE
Link Demodulator

C band Interstation Signalling Data


Link Modulator

Data NCS/NCS Link


C band LES TDM
Interfaces
Modulator

Tuning and timing NOC Link


Interface

Transmits the NCS


Common Channel

Note 1: See Volume 3, Part 1, Chapter 2, Section 3.3.6.2

2.2.3 Coordination Functions


The NCS shall maintain a database which records the status of all MESs registered for the Inmarsat-
C system. The NCS uses the database to coordinate the access of LESs to individual MESs by
monitoring the status of all MESs which are present in the ocean region which it controls. In particular
the NCS shall record whether the MES is logged into that ocean region and whether it is busy sending
or receiving a message. The Inmarsat-C access control protocols ensure that the NCS is always
informed of changes in the status of MESs.

LESs wishing to send a message to an MES use the NCS to broadcast an announcement to the MES
via the NCS common channel. When the NCS receives a request for an announcement from a LES it
uses the NCS database to determine the status of the destination MES. If the MES is in this ocean
region and it is not busy then the NCS broadcasts the announcement immediately. If the MES is busy
then the NCS queues the announcement for later transmission. Once the NCS is informed that the
MES has become idle it broadcasts the waiting announcement.

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 5


Chapter 1: Introduction and Overview
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

In order to maintain global coordination of MES access, each NCS is linked to each of the other NCSs
in the different ocean regions by means of an NCS – NCS signalling link.

2.2.4 Frequency Allocation


The NCS shall coordinate the allocation of TDM, message and signalling channels to individual LESs,
and in particular to LESs operating in the demand assigned mode. The NCS is required to assign
channels to LESs by means of TDM frequency assignments.

2.2.5 Network Administration


Whilst performing its coordination functions the NCS shall gather administrative information relating to
messages sent and received by MESs and statistics describing the loading placed on the NCS. This
information is periodically retrieved by the Inmarsat NOC.

2.3 NCS Functions


This section summarizes the main functions that shall be performed by the NCS.

2.3.1 Access Control


The NCS shall coordinate communication between LESs operating within an ocean region and
individual MESs, ensuring that LESs do not attempt to transmit messages to busy MESs.

This coordination role is performed for the following types of service:

(a) From-Mobile message transfer;

(b) To-Mobile message transfer;

(c) message delivery confirmation;

(d) data reporting and polling

(e) distress alerts; and

(f) EGC.

The Inmarsat-C access control protocols defined in Volume 1 ensure that each NCS is able to monitor
the status of all MESs operating in the Inmarsat-C network.

2.3.2 Network Coordination Functions


The NCS shall perform the following functions in order to coordinate the allocation of network
resources:

(a) receive all network logins and logouts;

(b) monitor the activity of individual MESs;

(c) bar individual MESs (that is, prevent them from sending or receiving any messages other than
distress messages);

(d) allocate communications channels to individual LESs;

(e) monitor the traffic loading of individual LESs;

(f) coordinate MES commissioning and performance verification procedures.

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 6


Chapter 1: Introduction and Overview
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.3.3 Network Management Functions


The NCS shall perform the following network management functions:

(a) gather call monitoring and network monitoring statistics and forward this information periodically
to the Inmarsat NOC;

(b) maintains a system log recording all significant events and all signalling traffic;

(c) maintains a separate distress log recording all distress related messages and events; and

(d) immediately notify the NCC whenever a distress alert has been sent within the ocean region.

2.4 Communications Interfaces


The NCS shall make use of the following communications interfaces:

2.4.1 Satellite Channels


The types of satellite channels used to perform the signalling and message transfer functions
associated with the Inmarsat-C and enhanced group call services are:

- NCS Common Channel

This provides the centralised resource of the Inmarsat-C system within an ocean region and it is
transmitted continuously by the NCS.

- Signalling Channels

These channels carry Inmarsat-C signalling information from MESs to the NCS where the destination
LES is operating in the demand assigned mode and for all MESs logging in or out of the network.

- Interstation Signalling Link

The NCS is linked to each of the LESs within the ocean region by means of separate NCS – LES and
LES – NCS signalling channels.

2.4.2 Terrestrial Links


The following terrestrial links shall be used to link each NCS with the Inmarsat NOC and with the
NCSs in other ocean regions:

- NCS – NCS Links

Each NCS shall be linked to every other NCS in the other ocean regions by means of an NCS – NCS
interstation signalling link.

- NOC link

Each NCS shall be linked to the Inmarsat NOC by a single physical communication link. This link
carries the following logical channels:

(a) Operator Console Channel;

(b) Database Channel; and

(c) Logging Channel.

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 7


Chapter 1: Introduction and Overview
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.5 NCS Database


Each NCS shall maintain a database containing, as a minimum, the following types of information:

(a) a list of all MESs registered for the Inmarsat-C service;

(b) a list of all LESs operating in the ocean region controlled by that NCS;

(c) a list of all NCSs operating in the Inmarsat-C network; and

(d) a list of all the TDM frequency and associated return channel assignments available for
allocation by that NCS.

2.6 Operational Facilities


This section provides a brief overview of the facilities provided for operational control of the NCS.
These facilities are described in detail in Chapter 2, Section 6.

2.6.1 Operator Interface


All operator interaction with the NCS shall be via a workstation acting as an operator console.

2.6.2 Facilities Provided


The operator interface shall enable authorized operations personnel to perform the following types of
function, depending on the level of privilege allocated to particular personnel:

- control the operation of the NCS;

- monitor and coordinate the operation of LESs and MESs within its particular ocean region;

- monitor and control the exchange of information with the Inmarsat NOC.

2.6.3 Interface with Inmarsat NOC


The Inmarsat NOC contains a remote operator console linked to each NCS.

The NOC shall send data to and receive data from an NCS by means of a remote file transfer link
which allows file transfer operations to be performed under NCS or NOC operator control.

Each NCS will send to the NOC, logging messages describing events at the NCS which have any
significance to overall Inmarsat-C network operation.

2.7 System Configuration and Reliability


The equipment and software required to implement the NCS shall be configured in a manner which
enables the NCS to achieve the reliability requirements specified in Chapter 2, Section 8 of this
document.

2.8 System Design Considerations


This section lists the Inmarsat-C and NCS network parameters which affect the NCS system design.
The performance requirements which affect the system design are described in Volume 1, Chapter 3,
Section 4.

2.8.1 Number of LESs Supported

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 8


Chapter 1: Introduction and Overview
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The NCS shall be able to coordinate a maximum of 64 LESs within an ocean region.

2.8.2 Number of Mobile Earth Station Supported


The NCS shall be capable of supporting a minimum of 100,000 MESs registered in all of the ocean
regions.

2.8.3 Number of NCSs


The Inmarsat-C system will operate in the four ocean regions managed by Inmarsat. At a later date
the number of ocean regions in the Inmarsat-C system may be expanded.

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 9


Chapter 1: Introduction and Overview
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Chapter 2: Functional Requirements

Contents

1 Introduction ............................................................................ 4

2 Inmarsat-C Services ................................................................ 4

3 Communications Interfaces ..................................................... 4


3.1 Satellite Channels .............................................................................................4
3.1.1 NCS Common Channel ..................................................................................4
3.1.1.1 General .................................................................................................................................. 4

3.1.1.2 Expansion .............................................................................................................................. 4

Figure 1: NCS Communications Interfaces .............................................................5


3.1.2 Signalling Channels .......................................................................................5
3.1.3 Interstation Links ............................................................................................5
3.1.4 L-Band Monitoring ..........................................................................................5
3.2 Terrestrial Links ................................................................................................6
3.2.1 NCS – NCS Links...........................................................................................6
3.2.2 NOC Link .......................................................................................................6

4 Access Control ....................................................................... 6


4.1 Channel Processing ..........................................................................................6
4.1.1 Overall Requirements ....................................................................................6
4.1.2 NCS Common Channel Control .....................................................................7
4.1.3 Signalling Channel Control .............................................................................7
4.1.3.1 General .................................................................................................................................. 7

4.1.3.2 Frequency Allocation ............................................................................................................. 7

4.1.4 LES – NCS Interstation Signalling Links ........................................................7


4.1.4.1 LES NCS Channel Processing ............................................................................................. 7

4.1.4.2 NCS – LES Channel Processing ........................................................................................... 8

4.1.5 NCS – NCS Link Processing ..........................................................................8


4.2 Call Processing .................................................................................................8

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 1


Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

4.2.1 To-Mobile Message Transfer .........................................................................8


4.2.2 From-Mobile Message Transfer .....................................................................8
4.2.2.1 Message Delivery Confirmation ............................................................................................. 8

4.2.3 Polling ............................................................................................................9


4.2.3.1 Individually Directed Polling ................................................................................................... 9

4.2.3.2 Group Directed Polling ........................................................................................................... 9

4.2.3.3 Area Directed Polling ............................................................................................................. 9

4.2.4 Data Reporting ...............................................................................................9


4.2.5 Distress Alerts ................................................................................................9
4.2.6 Enhanced Group Calls ................................................................................. 10
4.2.7 Access Queues ............................................................................................ 10
4.3 NCS – NCS Information Exchange ................................................................. 10
4.3.1 NCS Clock Synchronisation ......................................................................... 10
4.3.2 Information Exchange .................................................................................. 10

5 Network Coordination Functions ........................................... 11


5.1 Network Login/Logout ..................................................................................... 11
5.2 Mobile Earth Station Activity Monitoring .......................................................... 11
5.3 Barred MES .................................................................................................... 11
5.4 LES Call Monitoring ........................................................................................ 11
5.5 TDM Assignment ............................................................................................ 11
5.5.1 TDM Assignment to LESs Radiating Continuous TDM Channels ................ 12
5.5.2 TDM Assignment to LES Operating in Demand Assigned Mode ................. 12
5.6 MES Commissioning and Performance Verification ........................................ 12
5.6.1 MES Commissioning .................................................................................... 12
5.6.1.1 Commissioning Report......................................................................................................... 13

5.6.2 Performance Verification Testing ................................................................. 13

6 Operational Facilities ............................................................ 13


6.1 Operator Interface ........................................................................................... 13
6.2 Operational Control of NCS ............................................................................ 13
6.3 Network Management Functions .................................................................... 14

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 2


Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

6.4 Alarm Reporting .............................................................................................. 14


6.4.1 Categories of Alarm ..................................................................................... 14
6.4.2 Alarm Scheme.............................................................................................. 14
6.5 Distress Alert Procedures ............................................................................... 15
6.5.1 Distress Alert Notification ............................................................................. 15
6.5.2 Demand Assigned Operation ....................................................................... 15
6.6 Interface with Inmarsat NOC ........................................................................... 15
6.6.1 Operator Console Channel .......................................................................... 15
6.6.2 Database Channel ....................................................................................... 15
6.6.3 Logging Channel .......................................................................................... 16

7 Database Management Functions........................................... 16


7.1 NCS Database ................................................................................................ 16
7.1.1 Mobile Earth Station List .............................................................................. 16
7.1.1.1 Mobile Earth Station Status ................................................................................................. 17

7.1.2 LES List........................................................................................................ 17


7.1.3 NCS List ....................................................................................................... 18
7.1.4 TDM Assignment List ................................................................................... 18
7.2 Monitoring Information .................................................................................... 18
7.2.1 Call Monitoring ............................................................................................. 18
7.2.2 Network Monitoring ...................................................................................... 19
7.3 System Log ..................................................................................................... 19
7.3.1 System Log Format ...................................................................................... 20
7.3.2 System Log Maintenance ............................................................................. 20
7.4 Distress Log .................................................................................................... 20
7.4.1 Distress Log File Format .............................................................................. 20
7.4.2 Distress Log Maintenance............................................................................ 20
Annex 1: Year 2000 Compliance .......................................................................... 21

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 3


Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

1 Introduction
This chapter specifies the functional requirements of an Inmarsat-C Network Coordination Station
(NCS). The role of the NCS within the communications system is described in Volume 1.

2 Inmarsat-C Services
It is mandatory for the NCS to support all Inmarsat-C services:

- Message transfer on a store and forward basis

- Data reporting

- Polling

- Enhanced group calls

- Distress message handling

It is not mandatory, however, for all the earth stations that are under the control of the NCS to support
all these services. For more information, refer to Volume 1, Chapter 1.

3 Communications Interfaces
This section describes the satellite communications channels and terrestrial links that shall be used
by the NCS. They are shown schematically in Figure 1.

3.1 Satellite Channels


The satellite channels which the NCS shall use for signalling and message transfer purposes are
listed in the following paragraphs together with a brief summary of the types of information carried on
each channel. The link budgets and performance objectives of the channels are described in
Volume 1, Chapter 3, Sections 2 and 3.

3.1.1 NCS Common Channel


3.1.1.1 Ge n e r a l

The technical specification of this channel, which is identical to LES TDM channels, is described in
Part 1, Chapter 2, Section 3. The NCS common channel is continuously transmitted by the NCS and
is used to carry Inmarsat-C signalling and enhanced group-call messages. All MESs tune to the NCS
common channel when in the idle state. The NCS shall be capable of transmitting the NCS common
channel at an alternative frequency when requested by the Inmarsat NOC .

3.1.1.2 Expansion

Initially, only one NCS common channel will be transmitted. However, as traffic levels increase, the
NCS may be required to transmit additional NCS common channels. Additional and spare NCS
common channels will contain an NCS identity as defined in Part 1, Chapter 3.

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 4


Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Figure 1: NCS Communications Interfaces

NOC data
Links NCS/NCS Data Links

NOC NCSs
NCS 3

NCS Common Channel


Interstation
Signalling link Signalling
Channel

Signalling
Channel

Message SES
LESs channel
MESs
TDM
channel

Terrestrial
circuits

3.1.2 Signalling Channels


This channel conveys signalling information from MESs to the NCS where the destination LES is
operating in the demand assigned mode. Up to four signalling channels may be associated with each
NCS common channel transmitted. The technical specification of these channels is identical to the
signalling channel described in Part 1, Chapter 1, Section 3. In addition, this channel is used by all
MESs logging in or out of the network.

3.1.3 Interstation Links


The NCS is linked to each LES in its ocean region by an interstation link. These links are used for the
exchange of signalling information, the transfer of EGC messages and call data records between
LESs the NCS. The technical specifications of the links are described in Part 4 of this volume.

3.1.4 L-Band Monitoring


The NCS shall receive (one of) its own global TDM carriers to ensure that it is being transmitted within
specification, and to provide a reference for time slot generation.

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 5


Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

3.2 Terrestrial Links


The terrestrial links which the NCS uses for signalling and operations coordination purposes are listed
below together with a brief summary of the types of information carried on each link.

3.2.1 NCS – NCS Links


Each NCS within the Inmarsat-C network shall be linked to the NCS in each of the other ocean
regions by means of an NCS – NCS signalling link. The NCSs use these links to exchange
information about the status of MESs currently registered for the Inmarsat-C service. The technical
specifications of these links are described in Part 4 of this volume.

3.2.2 NOC Link


Each NCS shall be linked to the Inmarsat NOC.

Access to the NOC link shall be according to the CCITT Recommendation X.25 Level 3 (1984) with
LAPB at Level 2. Extended mode (modulo 128) sequence numbering will be employed. Address A will
be used by the NOC and address B by the NCS.

The link shall carry the following logical channels:

- Remote Operator Console Channel. This allows the NOC to operate as a remote operator
providing access to the standard NCS operator facilities.

- Data Base Channel. This channel provides a both-way link between the NCS and the NOC and
is used for the exchange of data files and reports.

- Logging Channel. The NCS uses this channel to send messages to the NOC for logging.

4 Access Control
The NCS shall coordinate the access of LESs operating within a particular ocean region to individual
MESs. This ensures that land earth stations do not attempt to transmit messages to MESs which are
already busy.

While performing these access control functions, the NCS must manage its internal resources in a
manner which ensures that it is able to handle distress priority traffic at all times.

4.1 Channel Processing

4.1.1 Overall Requirements


The NCS shall control:

- the transmission of signalling and enhanced group call message packets on the NCS common
channel(s);

- the access by MESs to the signalling channel(s);

- the transmission of signalling and enhanced group call message packets on the ISLs;

- the intercommunications with other NCSs; and

- the intercommunication with the NOC.

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 6


Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

The NCS shall have the capability to analyse the incoming packets from MESs, LESs, other NCSs
and the NOC, processing these messages and responding to them in accordance with the protocols
described in Volume 1.

4.1.2 NCS Common Channel Control


The NCS shall control the multiplexing of signalling packets and enhanced group call packets.
Packets having distress priority shall have precedence over all other levels of priority. Priority levels
are described in Volume 1, Chapter 4, Section 4.1.

Packet structure and individual packet formats are described in Volume 4, Chapter 3. An NCS will be
allocated one or more NCS common channel frequencies by Inmarsat.

4.1.3 Signalling Channel Control


4.1.3.1 Ge n e r a l

The NCS shall control the access of MESs to the signalling channels. The NCS will transmit
information related to each signalling channel associated with an NCS common channel in that
channel's bulletin board. A bulletin board is transmitted in each frame of the NCS common channel.

The contents of the bulletin board are described in Volume 4, Chapter 2.

The randomizing interval shall be adjustable to adapt to traffic conditions.

Slot state marker setting and randomizing interval control shall be in accordance with Section 4.3 of
Volume 1, Chapter 4.

When the network is operating through a spare 2nd generation satellite as a result of satellite
emergency, the signalling channel of the NCS shall be reverted back to 1st generation mode of
operation with a bit rate of 300 bps.

4.1.3.2 Frequency Allocation

An NCS will be allocated one or more signalling channel frequencies by Inmarsat. These may be
reviewed and changed by Inmarsat either periodically, for operational reasons, or at short notice such
as in the event of interference.

4.1.4 LES – NCS Interstation Signalling Links


4.1.4.1 LES NCS Channel Processing

In addition to the transfer of signalling and control packets, formatted EGC messages are transmitted
to the NCS for broadcasting via the NCS common channel. The transmission of packets on the LES –
NCS channel shall be on the following priority basis in descending order:

- SAR EGC messages;

- distress alert records;

- signalling and control packets; and

- call data records

Packet structure and individual packet formats are described in Volume 4, Chapter 6.

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 7


Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

4.1.4.2 NCS – LES Channel Processing

The transmission of packets on the NCS – LES interstation signalling link shall be in the following
priority basis in descending order:

- relayed distress alerts; and

- signalling and control packets.

The packet structure and individual packet formats are described in Volume 4, Chapter 6.

4.1.5 NCS – NCS Link Processing


The packet structure and individual packet formats are described in Volume 4, Chapter 7.

4.2 Call Processing


A full definition of the access control protocols and the timeouts which must be obeyed by the NCS
are provided in Volume 1 and in Volume 5, Chapter 4. The following sections provide additional
information describing the implementation of the protocols by the NCS.

4.2.1 To-Mobile Message Transfer


Since the NCS keeps a record of the current state of all MESs, all LESs wishing to send a message to
an MES use the NCS to broadcast the announcement. The NCS is aware at all times of those MESs
currently participating in message transfer, and it shall ensure that the announcement is not broadcast
while the destination MES is known to be tuned off the NCS common channel.

The NCS shall use an MES list to monitor the status of all MESs (see Section 7). The access and
control protocols ensure that the NCS is always informed of changes in the status of an MES. In
particular, the NCS is informed each time an LES establishes a logical channel with an MES and
when a logical channel is cleared by an LES.

When the NCS receives a request from an LES to broadcast an announcement, it does so only when
the MES list indicates that the MES is idle. If the LES has not specified the frequency assignment to
be used for the message transfer, the NCS allocates the frequency assignment to be used. Where the
NCS is unable to send the announcement immediately, because the MES is busy, then the
announcement shall be placed in a queue of announcements waiting to be sent. When the NCS is
informed that an MES has become idle, it shall scan the announcement queue and broadcast any
announcements waiting for transmission to that MES.

4.2.2 From-Mobile Message Transfer


From-Mobile message transfer does not require the active involvement of the NCS unless the
destination LES is operating in demand assigned mode.

In this case the MES first informs the NCS that it wishes to communicate with a particular LES. The
NCS, on receiving this request, relays it to the required LES. The LES then requests the NCS to
broadcast an announcement in the same manner as for To-Mobile traffic when it is ready to accept
the call from the MES.

4.2.2.1 Message Delivery Confirmation

An MES may request delivery confirmation from the LES. LESs send all delivery confirmation
messages via the NCS. When the NCS receives a call confirmation, it checks the status of the MES in
the MES list. If the MES is idle then the call confirmation is forwarded to the mobile immediately via
the NCS Common Channel, otherwise the confirmation is queued and transmitted when the MES
returns to the idle state. If the NCS receives an indication that the MES has initiated a new call within

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 8


Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

a certain time of transmitting the confirmation, the confirmation is re-transmitted when the MES
returns to the idle state.

4.2.3 Polling
Polling of individual MESs or groups of MESs is performed by the NCS on receipt of polling request
packets sent by LESs. The functions performed by the NCS vary depending on the type of polling
request received. See Volume 1, Chapter 4, Section 5 for complete details.

4.2.3.1 Individually Directed Polling

This is treated in the same manner as an LES request for a To-Mobile announcement.

If the MES is busy, the polling request is placed in a queue in the same way as a To-Mobile call
announcement, and an MES status packet is sent to the LES when the polling command is finally
sent.

It is permissible for multi-region LESs to transmit individual polls for alternate ocean regions. In such
cases the LES ID indicated in the individual poll will have a different 2-bit ocean region identifier than
the sending LES.

The NCS shall only accept and forward polls with the source and packet LES IDs consistent. The 2-bit
ocean region identifiers may differ, but must be consistent with ocean regions in which that LES
operates. Refer to Volume 3, Part 1, Chapter 3, Section 7.

4.2.3.2 Group Directed Polling

When the NCS receives a polling request for a group polling command, no MES status checks are
performed. The group polling command is immediately generated and transmitted on the NCS
common channel. The NCS confirms this action by sending a polling command status packet to the
LES.

It is permissible for multi-region LESs to transmit group (and area) polls for alternate ocean regions. In
such cases the LES ID indicated in the group or area poll will have a different 2-bit ocean region
identifier than the sending LES.

The NCS shall only accept and forward polls with the source and packet LES IDs consistent. The 2-bit
ocean region identifiers may differ, but must be consistent with ocean regions in which that LES
operates. Refer to Volume 3, Part 1, Chapter 3, Section 7.

4.2.3.3 Area Directed Polling

The action of the NCS on receiving a polling request specifying an area directed polling command is
identical to that for group directed polling.

4.2.4 Data Reporting


The NCS has no involvement in data reporting unless the data reporting is directed to an LES which
operates in demand assigned mode. In this case, the MES sends the data report to the NCS via the
NCS's signalling channel. The NCS then passes the data on to the designated LES via the NCS's
LES channel.

4.2.5 Distress Alerts


Mobile earth stations wishing to transmit distress alerts to an LES operating in the demand assigned
mode, initially send the distress alert to the NCS, designating a particular LES as the final destination
for the alert. The NCS then forwards the alert to the required LES. If the message cannot be

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 9


Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

forwarded by the NCS for any reason then it is the responsibility of the NCS to handle the distress
alert.

4.2.6 Enhanced Group Calls


All enhanced group call messages are passed to the NCS by LESs in packet form, for transmission
on the NCS common channel. When the NCS receives an EGC message, MES status checks are not
performed. When the message is subsequently broadcast, the status of the MES shown in the MES
list is not altered in any way.

4.2.7 Access Queues


In order to implement the access protocols, the NCS maintains queues for the following:

- all call announcements which are currently held waiting for transmission to MESs. The call
announcement may be held because the MES is currently busy or because no TDM
assignments are currently available for allocation to the LES;

- all call confirmations currently held waiting for MESs to return to the idle state;

- Poll Queue. This contains all individually directed polling commands which are currently held
waiting for MESs to return to the idle state.

When a particular MES returns to the idle state, any packets held in these queues waiting for
transmission to the MES are de-queued according to the priority scheme specified in Volume 1 for
NCS common channel access. Packets at the same priority level are de-queued on a first come, first
served basis.

Where entries in the announcement or poll queues specify that a TDM assignment is required, the
entries will only be de-queued and transmitted provided that a TDM assignment is available for
allocation. Whenever a TDM assignment becomes available, then the NCS will check the poll and
assignment queues to see whether any assignment or poll commands may now be sent. Again,
packets are de-queued according to the priority scheme specified in Volume 1, with packets of the
same priority level being de-queued on a first come, first served basis.

4.3 NCS – NCS Information Exchange


Each NCS within the Inmarsat-C network is linked to the NCSs in each of the other ocean regions via
an NCS – NCS signalling link. The NCSs shall use these communications links to ensure that all
NCSs maintain consistent and up-to-date MES lists and to enable them to monitor the availability of
MESs within each ocean region.

4.3.1 NCS Clock Synchronisation


In order to implement the NCS – NCS protocols specified in Volume 1 each NCS must maintain a real
time clock. The clocks in the NCS in each of the ocean regions must be synchronised to an accuracy
such that no NCS clock drifts from a universal reference time by more than four seconds.

4.3.2 Information Exchange


When an NCS detects that the status of an MES within its ocean region has changed, information
about the new MES's status shall be immediately sent to each of the other NCSs defined in the NCS
list.

The following events will cause MES status information to be sent to the other NCSs:

- commissioning/de-commissioning of an MES;

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 10


Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

- network login/logout; and

- barring/unbarring the MES.

5 Network Coordination Functions


This section describes the functions performed by the NCS in order to coordinate the allocation of
network resources and provide additional information regarding the implementation of the protocols
specified in Volume 1.

5.1 Network Login/Logout


All login and logout requests from MESs are handled by the NCS. The procedures for login and logout
by MESs are defined in Volume 1.

The NCS rejects all login requests from MESs which are listed in the NCS database as being barred.

When the NCS accepts a login or logout request, the status of the MES in the MES list is updated
accordingly (see Section 7). The NCS shall then notify all LESs in its ocean region and the NCSs in all
other ocean regions about the change in status of the MES.

5.2 Mobile Earth Station Activity Monitoring


The NCS uses the status information in the list to coordinate the transfer of To-Mobile messages from
LESs to MESs. This ensures that an LES is prevented from making a To-Mobile call to an MES that is
currently busy.

The Inmarsat-C access control protocols defined in Volume 1 ensure that the NCS is kept informed of
all changes in the status of MESs within an ocean region. As an additional safeguard, the NCS
monitors the activity of all MESs which are recorded as busy. Whenever an MES has been
continuously busy for more than the defined timeout period (as defined in Volume 1) the NCS solicits
information on its current status from the LES with which it is engaged in traffic. The NCS uses the
status information returned by the LES to check and if necessary update the status information held
for that MES in the MES list.

5.3 Barred MES


An MES in the MES list may have its status changed to "barred" by the NCS operator. A barred MES
is not permitted to send any messages other than distress alerts. The MES is prevented from logging
in to any ocean region and hence may not receive any messages. This facility shall not normally be
invoked other than for technical or system management purposes and only at the express wish of all
LES operators.

5.4 LES Call Monitoring


The NCS shall maintain a count of the number of calls in progress at each of the LESs in the ocean
region. This information shall be used to determine the LES to be used for MES commissioning and
performance verification tests.

5.5 TDM Assignment


The NCS manages the assignment of the following communications channels to all LESs:

- TDM channel;

- message channels; and

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 11


Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

- signalling channels.

Channels are allocated by the NCS to LESs, on request, and in blocks known as TDM assignments.
Each TDM assignment consists of a single TDM channel together with associated message channels
and signalling channels (see Volume 1, Chapter 2, Section 6.7). Assignments may be permanent or
demand assigned.

All channel assignment information is held in the TDM assignment list. This information is supplied by
the Inmarsat. The TDM assignment list is a single pool of channel assignments which may be
allocated to all LESs, including those operating pre-assigned channels and those operating in the
demand assigned mode. If no TDM assignment is available at the time the request is made, then the
request is held on the queue of assignments waiting to be sent.

TDM assignments released by LESs shall become immediately available for assignment to other
LESs.

5.5.1 TDM Assignment to LESs Radiating Continuous TDM Channels


Where an LES transmits continuous LES TDM channels, the channel pre-assignments are obtained
from the NCS.

5.5.2 TDM Assignment to LES Operating in Demand Assigned Mode


Where an LES operates in the demand assigned mode, it is granted its channel assignments by the
NCS as defined in Volume 1.

When the LES wishes to release the channel assignment, it informs the NCS by sending a TDM
Release packet on the interstation link. The channel assignment is then marked as available for
allocation to other LESs.

The method used for management of TDM assignments shall be such that flexible algorithms based
on traffic loadings and time allocations can be introduced at a future date.

5.6 MES Commissioning and Performance Verification


Automatic commissioning testing and periodic performance verification testing of MESs are
coordinated by the NCS, although the tests are actually performed by LESs. The procedures for
performing MES commissioning and performance verification are defined in Volume 1.

5.6.1 MES Commissioning


The NCS periodically receives from the Inmarsat NOC, a commissioning list giving information about
new MESs are to be added to the Inmarsat-C system. Each new MES listed in the commissioning list
generates an entry in the MES list with the status of the MES set to pre-commissioned.

Whenever the NCS receives a login request from an MES which has a pre-commissioned status, the
NCS initiates the commissioning testing procedure. The NCS selects an LES having a low level of
message activity to perform the actual commissioning testing and instructs the LES to perform the
commissioning tests. The LES's level of message activity is determined from the information held in
the LES list by the NCS (see Section 7.1.2).

When the LES has completed the commissioning testing procedure, the NCS is informed of the result.
If the testing was successful, the status of the MES is set to "commissioned" in the MES list. All LESs
within the ocean region and all NCSs within the other ocean regions are informed of the change in
status of the MES.

If the testing was not successful, the NCS leaves the status of these MESs in the MES list as pending
commissioning and marks the MES as having failed the commissioning tests.

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 12


Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Subsequent login attempts from that MES cause the commissioning procedure to be repeated. If,
after a number of unsuccessful tests (as specified in Volume 1), the NCS is informed that the MES
has once again failed the test then the status of that MES is set to barred in the MES list. Further login
requests are ignored and the MES is prevented from taking part in any other communication activity
other than distress priority.

5.6.1.1 Commissioning Report

The NCS periodically collects commissioning reports for the Inmarsat NOC giving information about
all commissioning tests which have been performed within its ocean region. The reports are sent to
the NOC under the control of the NOC operator.

Each time the NCS is notified of the result of a commissioning test, an entry is added to the current
commissioning report giving information about the results and the new status of the MES.

5.6.2 Performance Verification Testing


Performance verification testing may be initiated by LES, MES or the NCS as described in Volume 1.
In all cases, the functions performed by the NCS are the same.

When the NCS receives a request for performance verification for a particular MES either from an
LES, an MES or the NCS, it selects an LES and instructs it to perform the test. The actual test
procedure involves only the LES and the MES. On completion of the test, the LES informs the MES
and the NCS of the result. This information is used to update the entry in the MES list at the NCS.

6 Operational Facilities
This section describes the operational facilities which the NCS provides to enable NCS operations
personnel to control the operation of the NCS and coordinate the operation of the Inmarsat-C network
in its ocean region.

6.1 Operator Interface


There shall be two operator consoles per NCS. A printer shall be provided for a hard copy log of all
important system events and error messages. A second printer shall be provided for the production of
printed reports.

All operator interaction with the NCS shall be via an operator console. Access to the system shall be
controlled by an access control and security system.

The system allows the operator to perform a number of functions, each of which has a privilege level
associated with it. Each operator who is authorised to use the NCS shall be allocated a user identifier
and password together with a set of privileges which specify those functions that the individual
operator may perform.

6.2 Operational Control of NCS


As a minimum, the following functions may be performed by the NCS operator in order to control the
NCS:

- start the NCS;

- close down NCS;

- allocate/de-allocate particular hardware for communications channels and links;

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 13


Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

- interrogate the system log file;

- interrogate the distress log file; and

6.3 Network Management Functions


The following functions shall be performed by the NCS operator in order to manage the operation of
the Inmarsat-C network within the ocean region:

- inspect or modify entries in the MES list;

- inspect or modify entries in the NCS list;

- inspect or modify entries in the LES list;

- inspect or modify entries in the channel assignment list;

- bar particular MESs from transmitting or receiving messages;

- initiate performance verification tests for MESs.

6.4 Alarm Reporting


All error conditions which affect the operation of the NCS and other events which may have
operational significance shall cause an alarm to be generated. All alarm conditions cause a message
to be displayed on the operator console and the message is also logged to the hard copy log. In
addition the message is also logged to the system log and to the distress log where appropriate.
Those alarms which affect the ability of the NCS to perform its distress functions and other critical
functions shall cause an audible signal to be sounded continuously until cancelled by the operator. All
other alarms shall cause an audible signal to be sounded for a short period only.

6.4.1 Categories of Alarm


Three categories of alarm shall be provided:

(a) Urgent Alarm:

(1) equipment fault or loss of facility requiring immediate attention at all times; and

(2) power failure;

(b) Semi-Urgent Alarm-Equipment fault or loss of facility requiring attention as soon as possible
during working hours; and

(c) Minor (Deferred) Alarm - other failures, to be cleared when convenient.

6.4.2 Alarm Scheme


The alarm scheme shall provide the following facilities:

(a) visible signals-to enable rapid identification of the category of alarm;

(b) audible signals;

(c) the classification of alarms related to equipment and facilities, shall be such that it will be
possible to trace and clear faults before serious degradation of service or damage to equipment
occurs;

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 14


Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

(d) facilities to duplicate alarms at remote locations shall be provided; and

(e) provision for testing of alarms.

6.5 Distress Alert Procedures


Whenever the NCS receives notification that a distress alert is in progress within the ocean region, it
will perform the following functions:

- records details of the distress alert in the system and distress logs;

- logs notification of the alert to the Inmarsat NOC;

- displays a message on the operator console and on the hard copy log and sounds an audible
alarm continuously until acknowledgement by the NCS operator.

6.5.1 Distress Alert Notification


The NCS may receive notification of a distress alert in two ways:

(a) by receipt of the distress alert from the MES if the distress alert is to be forwarded to an LES
operating in the demand assignment mode; or

(b) by receipt of notification from an LES that it has received a distress alert sent directly to it by an
MES.

6.5.2 Demand Assigned Operation


When the NCS receives a distress alert for forwarding to an LES operating in demand assigned
mode, it shall immediately attempt to forward the alert, notifying NCS and NOC personnel in the
manner previously described. If the alert is forwarded successfully then the operator shall be informed
by a message on the console and hard copy log. The message shall also be logged to the system
and distress logs. If the NCS is unable to forward the alert for any reason then the NCS must take
responsibility for handling the alert. A message shall be displayed on the console and on the hard
copy log to inform the operator and the audible alarm sounded continuously until cancelled by the
operator. This event shall also be logged in the system and distress logs.

6.6 Interface with Inmarsat NOC


Each NCS is linked to the Inmarsat NOC by means of a single communications link providing three
logical channels:

(a) the Operator Console Channel;

(b) the Database Channel; and

(c) the Logging Channel.

6.6.1 Operator Console Channel


This channel enables NOC personnel to operate a remote operator's console with access to the
facilities provided on the local NCS console.

6.6.2 Database Channel


In addition to the facilities required by an NCS operator to coordinate, the network on a day to day
basis, the NOC has additional requirements.

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 15


Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

The NOC is responsible for adding pre- commissioned MESs to the MES list database, removing
entries on de-commissioning and for generating reports on various facets of the network's operation.

In order to allow formatting of reports, and to simplify updating of the NCS's database, a QUERY
language shall be implemented at the NCS. This language should allow personnel at the NOC to
obtain access to database fields in a straight-forward manner and allow flexible formatting of reports.

The NOC operator should be able to write procedures in the query language and to save developed
procedures at the NCS for later retrieval as required.

6.6.3 Logging Channel


This channel shall be used by the NCS to automatically send logging information to the NOC
describing events at the NCS which have significance to overall Inmarsat-C network operation. The
following items are required:

(a) distress alert notifications;

(b) LES outages; and

(c) NCS system failures (see Chapter 3, Section 2.4).

7 Database Management Functions


In order to maintain a record of Inmarsat-C network activity, significant NCS events and to provide
information for use by the Inmarsat NOC, the NCS shall perform the following functions:

- gather call record information detailing the traffic carried by the Inmarsat-C network within a
particular ocean region;

- maintain a system log file recording all significant events occurring at the NCS and all Inmarsat-
C network events and signalling traffic detected by the NCS, such as LES commissioning/de-
commissioning, MES status changes, and so on;

- maintain a distress log file recording all initial distress alerts received by the NCS and all
distress priority message and signalling traffic; and

- notify the NOC whenever a distress alert is received by the NCS or by an LES within that
ocean region.

7.1 NCS Database


This section describes the data structures which shall be maintained by each NCS.

7.1.1 Mobile Earth Station List


The MES list defines all those MESs which have been registered as users of the Inmarsat-C system.
The following information will be held as a minimum:

- the forward and return Inmarsat-C 24 bit binary MES identities as defined in Part 2;

- ITU MES identity (see Part 1, Chapter 3);

- MES status information. This is described in more detail below;

- current NCS (see Part 1, Chapter 3);

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 16


Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

- result of the last commissioning or performance verification test performed on the MES;

- date and time of the last login or logout;

- date and time of last call;

- MES type

Entries are added to, and removed from, the MES list by the Inmarsat NOC.

7.1.1.1 Mobile Earth Station Status

Each MES listed in the MES list shall have the following status information associated with it:

(a) Commissioning Status

This indicates whether or not a defined MES is currently in commission. Valid states are:

- pre-commissioned;

- commissioned.

In order to become commissioned, a mobile which is shown as pre-commissioned must


successfully pass the MES commissioning tests.

(b) Barred Status

This determines whether or not an MES may make calls. Valid states are:

Barred — the MES may make only distress priority calls;

Un-barred — the MES may make all categories of calls.

(c) Logged-in Status

This indicates whether or not the MES is logged-in to one of the ocean regions. Valid states
are:

Logged-in — the MES is logged-in to one of the ocean regions;

Logged-out — the MES is not recorded as logged-in in any ocean region.

(d) Busy Status

This indicates whether or not the MES is currently busy interacting with an LES. Valid states
are:

Busy — the MES is currently busy sending or receiving a message,

Idle — the MES is currently not sending or receiving a message.

7.1.2 LES List


The NCS shall maintain a list of all LESs that operate in the region. As a minimum, the following
information shall be held for each LES:

- LES identity;

- types of services provided by the LES;

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 17


Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

- Whether a continuous TDM channel is broadcast or whether demand assignment of LES TDMs
is in operation at that earth station;

- channel assignments currently allocated to the LES;

- number of messages in progress on each TDM channel; and

- number of TDMs the LES can transmit.

The entries in the LES list are updated by the Inmarsat NOC.

7.1.3 NCS List


Each NCS shall maintain a list of all other NCS active in the other ocean regions of the Inmarsat-C
network. As a minimum, the following information will be held for each NCS:

- NCS identity. For code see Part 1, Chapter 3;

- NCS status, i.e. whether the NCS is currently operational.

- NCS access information; for example, type of NCS – NCS link

The entries in the NCS list are updated by the Inmarsat NOC.

7.1.4 TDM Assignment List


The assignment list shall define the full set of TDMs, message and signalling channels which the NCS
has available for allocation to LESs within its ocean region. The available channels are grouped into
sets of assignments. Each assignment shall consist of a single TDM channel and a set of associated
message and signalling channels. As a minimum, each entry in the TDM assignment list shall contain
the following information:

- TDM channel identifier;

- message channels associated with the TDM;

- signalling channels associated with the TDM;

- status of frequency assignment; that is, whether it is allocated or not allocated;

- LES to which frequency assignment is currently allocated or was last allocated.

The information in the TDM assignment list is updated using information supplied by the Inmarsat
NOC.

7.2 Monitoring Information


Monitoring information accumulated by the NCS shall be forwarded periodically to the Inmarsat NOC
using the NOC data base channel. Forwarding of this information to the NOC will be carried out under
operator control by NOC personnel.

Two types of monitoring information are gathered by the NCS.

7.2.1 Call Monitoring


Individual network record are generated by each operational LES in an ocean region and are
transmitted to the NCS via the interstation links.

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 18


Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

One call record will normally be forwarded for each call completed by an LES (see Part 1, Chapter 2,
Section 8 and Volume 4, Chapter 6). The call monitoring will contain the following information:

(a) date and time of start of call defined by request for assignment or announcement; (call
commencement)

(b) LES identity;

(d) satellite frequency code;

(e) repeated packets;

(f) service type;

(g) delivery status;

(h) call volume, i.e. number of packets in call;

(i) spare;

(j) time of call completion;

(k) frame length; and

(l) destination.

In addition, the NCS shall add a six digit serial number to each record immediately on receipt. The
NCS is responsible for maintaining a single serial number sequence which it uses to uniquely identify
call monitoring records from all LESs.

7.2.2 Network Monitoring


Network monitoring data shall be generated periodically by the NCS and as a minimum shall consist
of the following information:

- peak NCS message queue size;

- peak loadings on interstation links; and

- number of logins/logouts per day.

7.3 System Log


The system log shall record all significant events occurring at the NCS, all signalling traffic handled by
the NCS and all significant network events reported to the NCS. The following events are logged:

- all errors in NCS hardware;

- all errors in NCS software;

- changes in the operational status of the NCS;

- changes in the status of the communications channels handled by the NCS;

- all protocol messages on the interstation signalling channels relating to allocation of LES TDM
assignments, logical channel establishment and channel clearing;

- distress alerts;

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 19


Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

- all message traffic at distress priority;

- changes in the operational status of LESs within that ocean region; and

- all operator interaction with the NCS.

7.3.1 System Log Format


The current system log shall always be maintained on-line on suitable magnetic media. Each entry in
the log shall now show the date and time of entry together with sufficient information to provide a
meaningful description of the event being logged.

All distress alerts directed to the NCS and all messages showing distress priority shall be logged in
full. In addition all operator actions which affect in any way the ability of the NCS to handle this
distress traffic shall be logged in full.

7.3.2 System Log Maintenance


The system log shall record all events occurring during a 24 hour operational day. A new log shall be
created at the beginning of each 24 hour period. Previous versions of the log shall be maintained on-
line for a period of seven days. At the end of this period, the log shall be archived and maintained off-
line for a further 30 day period.

7.4 Distress Log


The distress log shall be maintained as a back-up to the system log to provide a long term record of
all distress priority messages and associated events. All information written to the distress log shall be
simultaneously logged in identical format to the distress log shall be simultaneously logged in identical
format to the system log. The following events shall be logged to the distress log:

- initial distress alerts;

- all distress priority signalling and message traffic; and

- all operator actions which affect the ability of the NCS to handle distress priority traffic.

7.4.1 Distress Log File Format


The distress log shall be maintained on suitable magnetic media. The format of entries in the distress
log is identical to that specified for the system log.

7.4.2 Distress Log Maintenance


The distress log shall record events occurring during during a 24 hour operational day. A new log
shall be created at the beginning of each 24 hour period. Old versions of the distress log file shall be
immediately archived and maintained off-line for a period of six months.

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 20


Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Annex 1: Year 2000 Compliance

The Inmarsat-C NCS shall be compliant with the year 2000 date change so that it can:

- handle date information before, during and after 1 January 2000, including but not limited to
accepting date input and performing calculations on dates or portions of dates

- function accurately and without interruption before, during and after 1 January 2000 without
changes in operation associated with the advent of the new century

- respond to two-digit year date input in a way that resolves the ambiguity as to the century in a
disclosed, defined and pre-determined manner

- store and provide output of date information in ways that are unambiguous as to century

- manage the leap year occurring in the year 2000 following the quad-centennial rule.

In addition, GPS receivers used in conjunction with the Inmarsat-C NCS shall be able to manage the
rollover occurring in that system at midnight on 21 August 1999.

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 21


Chapter 2: Functional Requirements
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 3: System Integrity

Contents

1 Introduction ............................................................................ 2

2 System Reliability ................................................................... 2


2.1 Overall Reliability Requirement .........................................................................2
2.2 System Failure and Recovery ...........................................................................2
2.3 System Configuration ........................................................................................2
2.4 Categories of System Failure ............................................................................2
2.4.1 NCS Communications Failure ........................................................................3
2.4.2 Temporary Loss of Service ............................................................................3
2.4.3 NCS Failure ...................................................................................................3
2.5 Functional Reliability .........................................................................................3
2.5.1 Central Processing Unit .................................................................................3
2.5.2 Communications Interface .............................................................................3
2.5.3 NCS Database ...............................................................................................3
2.5.4 Operator Terminal Equipment ........................................................................3

3 Maintenance ............................................................................ 3
3.1 Processor Diagnostics ......................................................................................3
3.1.1 Processor Maintenance .................................................................................4
3.2 Communications Equipment Diagnostics ..........................................................4
3.2.1 Communications Equipment Maintenance .....................................................4
Annex 1: Year 2000 Compliance ............................................................................4

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 1


Chapter 3: System Integrity
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
The operational integrity of the Network Coordination Station is crucial to the continued satisfactory
operation of the Inmarsat-C communications system within its ocean region. The NCS must comply
with the requirements described in this chapter in order to ensure that failures, and their effects, are
minimised and that any which do occur are rectified swiftly.

2 System Reliability
This section describes the reliability criteria which must be met by the hardware and software used to
perform the functions of the NCS. These requirements are described in terms of an idealized
hardware and software configuration with no preference for a particular technical solution.

2.1 Overall Reliability Requirement


During the first two years of Inmarsat-C network operation the entire NCS configuration must have a
minimum reliability of 99.95%. No single failure should persist for more than one hour and no more
than three failures should occur in any six month period.

For the third, and all subsequent years of operation a minimum reliability of 99.99% is required. No
single failure should persist for more than thirty minutes and no more than two failures are allowed in
any six month period.

The term failure as used in this section means NCS failure as defined in section 2.4.3. Events
classified as temporary Loss of Service as defined in Section 2.4.2 do not count towards the system
reliability requirements specified in this section.

2.2 System Failure and Recovery


In the event of an NCS hardware or software failure which prevents the NCS performing any of its
access control or network coordination functions, normal service must be resumed within three
minutes of such a failure being reported at the NCS. Recovery from such a failure may be by manual
or automatic means provided that service is resumed within the specified period. Failure of the NCS
should not result in loss of data already received by the NCS nor in corruption to the NCS database
and other maintained lists.

2.3 System Configuration


For the purpose of specifying NCS reliability the NCS can be considered to consist of the components
shown in Chapter 1, Figure 1-1. These are:

- Central Processing Unit (CPU). This runs all of the computer software necessary to implement
the functions specified for the NCS;

- Communications Interface. This consists of the modulators, demodulators and data modems
(DCEs) used for satellite and terrestrial communication as described in Chapter 2, Section 3;

- NCS Database. This contains all of the data structures required to perform the NCS functions;

- Operator Terminal Equipment. This consists of equipment required to implement the operator
interface specified in Chapter 2, Section 6.

2.4 Categories of System Failure


Three different categories of NCS failure are defined for the purpose of specifying NCS reliability and
recovery requirements.

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 2


Chapter 3: System Integrity
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.4.1 NCS Communications Failure


This is defined as a failure of any of the components which form part of the NCS communications
interface which prevents the NCS from using a satellite channel or critical terrestrial link. In order to
prevent transient problems causing unnecessary switchover of equipment, errors associated with this
equipment must persist for more than ten seconds before an NCS communications failure is declared
and recovery procedures are initiated.

2.4.2 Temporary Loss of Service


This is defined as any equipment or software fault which prevents the NCS from performing its access
control or network coordination functions for a period of less than three minutes. Temporary loss of
service may be caused by NCS communications failure, other NCS equipment failure or software
failure.

2.4.3 NCS Failure


NCS failure is defined as a loss of service which persists for more than three minutes.

2.5 Functional Reliability


This section defines special reliability requirements which must be met by the NCS components
defined in Section 2.2.

2.5.1 Central Processing Unit


Any failure of the NCS caused by the failure of computer equipment or software must cause no more
than Temporary Loss of Service. No particular hardware or software solution is specified by Inmarsat.

2.5.2 Communications Interface


Modulators, demodulators and DCEs which form the communications interface must be duplicated to
the extent that failure of a single channel unit should not cause an NCS failure condition (as defined in
Section 2.4.3) to arise.

2.5.3 NCS Database


The NCS database shall be held on any suitable media. It must be organized in a manner so that
failure of a single peripheral does not result in loss of data.

2.5.4 Operator Terminal Equipment


At all times the following terminal equipment should be available for use:

- two operator consoles;

- one printer providing hard copy log.

3 Maintenance
The NCS shall provide a comprehensive fault logging system capable of producing a hard copy
output of all faults that occur.

3.1 Processor Diagnostics


It shall be possible to locate a fault to p.c.b. level within a malfunctioning system hardware module.

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 3


Chapter 3: System Integrity
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.1.1 Processor Maintenance


Any faulty CPU shall be taken out of service and logged out until maintenance procedures have been
carried out and the CPU returned to service manually by the maintenance technician.

A partially disabled processor shall not be taken out of service, however, if no other processor is
available to take over its workload.

It shall be possible to perform a re-allocation of the faulty processor's work load, including all calls
being processed at the time of the malfunction.

3.2 Communications Equipment Diagnostics


It shall be possible to locate a fault to unit level with any communication interface unit such as
modulators, demodulators and modems.

3.2.1 Communications Equipment Maintenance


Any faulty communications equipment shall be taken out of service and logged out until maintenance
procedures have been carried out and the equipment returned to service manually by the
maintenance technician.

Annex 1: Year 2000 Compliance

The Inmarsat-C NCS shall be compliant with the year 2000 date change so that it can:

- handle date information before, during and after 1 January 2000, including but not limited to
accepting date input and performing calculations on dates or portions of dates

- function accurately and without interruption before, during and after 1 January 2000 without
changes in operation associated with the advent of the new century

- respond to two-digit year date input in a way that resolves the ambiguity as to the century in a
disclosed, defined and pre-determined manner

- store and provide output of date information in ways that are unambiguous as to century

- manage the leap year occurring in the year 2000 following the quad-centennial rule.

In addition, GPS receivers used in conjunction with the Inmarsat-C NCS shall be able to manage the
rollover occurring in that system at midnight on 21 August 1999.

Volume 3: Earth Station Requirements, Part 3: Network Coordination Station Page: 4


Chapter 3: System Integrity
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 1: Interstation Signalling Links

Contents

1 Introduction ............................................................................ 2

2 Interstation Network ................................................................ 2


Figure 1: Interstation Signalling Links .....................................................................3

3 NCS – NCS and NCS – NOC Interstation Signalling Links ......... 3


3.1 Physical Network ..............................................................................................3
3.1.1 Primary Interface ............................................................................................3
3.1.2 Secondary Interface .......................................................................................3
3.2 Transport Layer .................................................................................................3
Figure 2: NCS – NOC Wide Area Network..............................................................4

4 LES - NCS Interstation Signalling Links ................................... 4


4.1 Physical Layer ...................................................................................................4
4.2 Link Level Protocol ............................................................................................4
Table 1: LAPB Parameters .....................................................................................6
4.3 Failure of the Interstation Signalling Link ..........................................................6

Volume 3: Earth Station Requirements, Part 4: Interstation Signalling Links Page: 1


Chapter 1: Interstation Signalling Links
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
This chapter contains the technical requirements for the following communications network:

• NCS to NCS;

• NCSs and the NOC ; and

• NCS and the LESs in the same ocean region.

A link between any two of these fixed stations is called an Interstation Signalling Link (ISL). These
ISLs allow information to be transferred between stations, providing an integrated and coordinated
service to Inmarsat-C users. In particular, the links are used to transfer MES registration information
between ocean regions.

All links between an NCS and LESs are provided by satellite channels. The NCS – NCS and NCS –
NOC links use the terrestrial networks.

This chapter should be read in conjunction with Parts 1 and 3 of this volume, which define the
requirements for LESs and NCSs. Reference should also be made to Volume 1 of the System
Definition Manual which provides an overview of the Inmarsat-C communications system, clarifying
the purpose of each type of earth station. Volume 1 also describes the message protocols for the
links; more detailed information about packet formats and protocols can be found in Volumes 4 and 5.

The purpose of these technical requirements is to ensure that all fixed stations (NCSs and LESS)
providing Inmarsat-C services will perform adequately and will preserve the integrity of system
operations.

2 Interstation Network
Interstation Signalling Links (ISLs) are required for the following purposes:

(a) to carry Inmarsat-C signalling packets between the NCS and each LES;

(b) to carry EGC traffic from LES to NCS, for broadcast on the NCS common channel;

(c) to carry network information between the NCSs in the different ocean regions; and

(d) to carry commissioning data from the NOC to the NCSs.

Figure 1 illustrates the logical connectivity which is established between fixed stations in the
Inmarsat-C network. (For the sake of clarity, only three ocean regions are depicted.)

Each LES in a particular region is connected by a satellite link to that region's NCS. Each NCS is
connected to the NOC and also, to each of the other NCSs;

Volume 3: Earth Station Requirements, Part 4: Interstation Signalling Links Page: 2


Chapter 1: Interstation Signalling Links
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: Interstation Signalling Links

NCS NCS

LES LES LES LES LES LES


NCC

LES-NCS ISL
NCS NCS-NCS ISL
NCS-NOC ISL

LES LES LES

3 NCS – NCS and NCS – NOC Interstation Signalling Links


Connections will be supplied by Inmarsat between each of the NCS sites and the NOC . The NOC
will act as a routing node allowing full connectivity between NCSs. Figure 2 indicates the wide area
network requirements for the NCSs and the NOC .

3.1 Physical Network

3.1.1 Primary Interface


At each NCS site, Inmarsat will make available a data communications interface providing a
permanent connection for Data Termination Equipment (DTE). This interface will provide a connection
between the NCS and the NOC and shall be used by the NCS equipment for NCS to NCS and NCS
to NOC communications.

The link supplied by Inmarsat will have a minimum speed of 1200 baud.

3.1.2 Secondary Interface


Each NCS equipment shall have the necessary modem equipment to allow a dialup connection to be
established over the PSTN to the NOC . This link will be used if the primary link has failed.

Inmarsat will supply the connection to the PSTN at each of the NCS sites.

3.2 Transport Layer


A suitable protocol shall be provided for the NCS equipment which allows full connectivity between
NCSs and the NOC. The protocol shall provide for the establishment of multiple concurrent logical
channels between nodes.

Volume 3: Earth Station Requirements, Part 4: Interstation Signalling Links Page: 3


Chapter 1: Interstation Signalling Links
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 2: NCS – NOC Wide Area Network

NCS
AOR(E)

PSTN

PSTN

NCS NCS
NOC
AOR(W) POR

Permanent data channel


PSTN PSTN supplied by INMARSAT

Fallback Dial-up Connections


to the PSTN
NCS
IOR AOR(W) Atlantic Ocean Region (West)
AOR(E) Atlantic Ocean Region (East)
IOR Indian Ocean Region
POR Pacific Ocean Region

4 LES - NCS Interstation Signalling Links

4.1 Physical Layer


A full duplex channel between an LES and an NCS shall be implemented by two simplex (SCPC)
channels operating using the Inmarsat space segment.

Each simplex channel shall conform to the following requirements:

Speed 1200bps

Encoding Differentially encoded BPSK

Transmission Frequency C band as for TDM transmission


(See Part 1, Chapter 2, Section 3.2.1)

Receive Frequency L Band as in Part 1, Chapter 2, Section 3.3.1

The modulators and demodulators for these channels shall meet the requirements for Inmarsat-A LES
TDM modems as given in Section 5.2.1 of the document "Technical Requirements for Inmarsat
Standard-A Coast Earth Stations", Issue 5, March 1989, and Sections 2.1.1 (a), (b) and (c) and 2.1.2
(a), (b), (c) and (d) of the document "Technical Requirements for Inmarsat Standard-A Ship Earth
Stations", Issue 3, May 1988. These documents are available from Inmarsat.

4.2 Link Level Protocol


The CCITT recommendation X.25 (1984) LAPB link level protocol for a single physical circuit shall be
used between an LES and its region's NCS. The following provides details of the necessary LAPB
parameters and clarifies points which are implementation defined or are unclear within the CCITT
recommendation:

Volume 3: Earth Station Requirements, Part 4: Interstation Signalling Links Page: 4


Chapter 1: Interstation Signalling Links
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

a) Extended modulo 128 sequence numbering shall be adopted.

b) The following shall not be supported:

• asynchronous response mode (LAP);

• MLP;

• normal response mode; and

• Modulo 8 sequence numbering.

c) the NCS shall be the DCE (address B) and an LES the DTE (address A)

d) The NCS shall recognize any string of more than 6 contiguous 1's as an abort.

It shall not recognize a string of more than 15 contiguous 1s as idle channel state and the Idle
Channel State timer T3 will not be implemented.

e) X.25 allows two methods for recovering from a T1 timeout:

• retransmit the oldest unacknowledged I frame with the poll bit set; or

• send an RR or RNR command with the poll bit set.

To conserve transmission time, the NCS shall always recover by sending a polling RR or RNR.
However, it shall be compatible with LES peers which recover by sending the oldest
unacknowledged I frame or a polling RR or RNR. It is recommended that LESs recover using a
polling RR or RNR.

f) The NCS shall send an RR (or an RNR if in busy state) command with the poll bit set and shall
start timer T1 if no frames have been sent or received by LAPB for a time Tidle. This procedure
allows the NCS to detect a failed peer relatively quickly even if there are long periods of no
traffic on the link.

g) Once the ISL link is configured, the NCS shall send a SABME frame to establish the Link Level
between the NCS and the LES. Whenever a link is down, the NCS shall send SABME frames
to try and re-establish the link.

h) The NCS will follow these procedures:

• when a polling REJ is sent, all frames shall be ignored until the final RR or RNR is
received, and,

• T1 shall be restarted when any REJ is sent.

It is recommended that LESs also follow these procedures which help prevent the following
FRMR situations:

A polling REJ may be sent because the original REJ frame was lost. The other side of the link
may also be timing out (T1) on the transmission of the 1-frame which was lost (the reason for
the original REJ). If the other side of the link recovers by retransmission of that I-frame, the
polling REJ frame and the retransmitted I-frame may cross on the link. This will look like the
REJ has been satisfied, according to CCITT rules. However, the transmitter of the I-frame will
see the polling REJ, respond with a final RR or RNR, then transmit that I-frame again. In high
throughput situations, the sides may get out of synchronization and an FRMR may result.

i) The NCS will follow this procedure:

Volume 3: Earth Station Requirements, Part 4: Interstation Signalling Links Page: 5


Chapter 1: Interstation Signalling Links
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

• when a REJ is received, T1 will be stopped. T1 is restarted when the NCS transmits the
I-
frame which responds to the REJ.

It is recommended that LESs also follow these procedures which help prevent the following
FRMR situation:

Receipt of an REJ causes the LAPB protocol to retransmit outstanding I-frames. T1 gets
started when an I-frame is transmitted and T1 is not already running. As there are frames
outstanding when an REJ is received, T1 will be running. Since T1 may have been started due to the
previous transmission of one of the frames to be retransmitted, T1 should be stopped to let the
error recovery take place. (If T1 were to expire during the retransmission of these frames, the
remote end will not have had enough time to respond. This could cause an FRMR). When the
first I-frame is transmitted in response to the REJ, T1 will be restarted.

j) LAPB parameters shall be configurable within the ranges defined in Table 1 below.

Table 1: LAPB Parameters

Incremen
Item Description Range Default
t
K Maximum number of outstanding frames 1 to 40 1 frame 32
2400 bits
N1 Max number of bits in I frame Fixed
(300 Bytes)
N2 Max number of retransmissions 3 to 20 1 10
T1 Retransmission Timer 3 to 40 s 1s 5s
T2 Response Timer 0.5 to 20.0 s 0.1 s 2s
Tidle Idle Link Timer 5 to 120 s 1s 30 s

4.3 Failure of the Interstation Signalling Link


In the event that the Interstation Signalling Link fails, the LES operator should be informed. The link
should continue automatically to try to re-establish itself indefinitely and it should be an operator
action to mark the ISL down. It will not be possible for the LES to determine whether the failure is just
in the link, or whether the NCS has failed. In the latter case, the NOC may request the LES to start
operation in Restoration mode. Under no circumstances should the LES automatically switch into
Restoration Mode. The decision to switch to Restoration Mode will be taken by Inmarsat, which will
co-ordinate all stations. If the LES is demand assigned, there is virtually no service that the LES can
offer with the exception of continuing with any calls in progress. It is essential that the ISL be restored
as soon as possible. MES Status report packets should be discarded during the outage. An LES
operating with demand assigned TDMs should complete any calls in progress; not accept any new
ones and should stop transmission of demand assigned TDMs as soon as possible. When the ISL is
restored all such TDMs should be released using the TDM Release packet.

Volume 3: Earth Station Requirements, Part 4: Interstation Signalling Links Page: 6


Chapter 1: Interstation Signalling Links
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 1: Introduction

Contents

1 Introduction ............................................................................ 2
1.1 Inmarsat C Services ..........................................................................................2

2 Packet Formats ....................................................................... 2


2.1 General Packet Structure ..................................................................................3
2.1.1 Packet Descriptor ...........................................................................................3
2.1.2 Type Dependent Fields ..................................................................................3
2.1.3 Checksum (16 Bits) ........................................................................................3
2.2 TDM and ISL Packet Descriptors ......................................................................3
2.2.1 Short Packet Descriptor .................................................................................3
2.2.1.1 Short Packet (1 Bit) ................................................................................................................ 3

2.2.1.2 Type (3 Bits) ........................................................................................................................... 4

2.2.1.3 Length (4 Bits) ........................................................................................................................ 4

2.2.2 Medium Packet Descriptor .............................................................................4


2.2.2.1 Medium Packet (2 Bits) .......................................................................................................... 4

2.2.2.2 Type (6 Bits) ........................................................................................................................... 4

2.2.2.3 Length (8 Bits) ........................................................................................................................ 4

2.2.3 Long Packet Descriptor ..................................................................................4


2.2.3.1 Long Packet (2 Bits) ............................................................................................................... 4

2.2.3.2 Type (6 Bits) ........................................................................................................................... 4

2.2.3.3 Length (16 Bits) ...................................................................................................................... 4

2.3 ISL Packets Carrying TDM or Signalling Traffic ................................................4


Figure 1: Error Detection Coding Algorithm ............................................................5
Figure 2: TDM and ISL Packet Structures ..............................................................6

Volume 4: Packet Formats and Usage, Page: 1


Chapter 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
Volume 1 of the System Definition Manual describes the protocols used with the Inmarsat-C access
control and signalling system: it discusses the channel structure and the procedures that must be
followed to send and receive messages.

This volume provides detailed formats of the packets used in the system: where practicable, it follows
the same general structure as Volume 1 so as to make it easier to cross-refer between the two
volumes.

The packets are described in Chapters 2 to 10; Chapter 12 describes their purpose and the way they
are used.

SDL diagrams for the protocols can be found in Volume 5.

1.1 Inmarsat C Services


The system provides:

- message transfer on a store and forward basis

- distress alerts and distress messages

- optional services, including one way data reporting, polling, and enhanced group calls

Some of the services supported by the Inmarsat-C system are mandatory: all operators and
equipment manufacturers are required to make provision for them. Other services are optional for
some manufacturers and service providers as indicated in the following table.

SES SES (non- MES


SES SES (non-
Service LES (SOLAS SOLAS (land-
(SOLAS with SOLAS with
without without
distress)
distress)
distress)
distress)
based)

S&F
Messaging Mandatory Mandatory Mandatory Mandatory Mandatory Mandatory

Distress
alerting Mandatory Mandatory N/A Mandatory N/A Not allowed

Land
Mobile
alerting Optional N/A N/A N/A N/A Optional

Data
reporting Optional Optional Optional Optional Optional Optional

Polling Optional Optional Optional Optional Optional Optional


EGC Mandatory Mandatory Optional Optional Optional Optional

2 Packet Formats
The packet formats are described in Chapters 2 to 10. Most have a similar general structure which is
described here.

Volume 4: Packet Formats and Usage, Page: 2


Chapter 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.1 General Packet Structure


The packets transmitted on the various Inmarsat-C channels have a general format as follows:

[Packet] ::= [Packet Descriptor]


[Type dependent fields]
[Checksum]

2.1.1 Packet Descriptor


The packet descriptor is defined for each channel in the relevant chapter. It contains such information
as packet type (where a variety of types are transmitted on the channel) and length information where
this is necessary. Where a length is given it represents a byte count of all the following fields including
a two-byte final Checksum.

2.1.2 Type Dependent Fields


This is the body of the packet.

There are occasions where a packet has to be split into Continuation packets for transmission on a
TDM channel. There are also occasions where a packet received on a Signalling channel has to be
transmitted on an Interstation Link. In both of these cases the packet or part packet is included as
type dependent fields of another packet. In such cases the Checksum of the original packet is
removed, since otherwise two Checksums would appear. Where present, however, the length
information of the included packet is not modified and continues to indicate the length of the original
packet.

2.1.3 Checksum (16 Bits)


This is a checksum of the [Packet Descriptor] and [Type Dependent Fields]. The algorithm is given in
Figure 1.

2.2 TDM and ISL Packet Descriptors


The Inmarsat-C packets transmitted on the TDM channels and on the Interstation Link share a
common packet structure. This general structure is described below and illustrated in Figure 2.

[TDM or ISL] ::= [Packet Descriptor]


[Type dependent fields]
[Checksum]

The packet descriptor is used to define the type of packet and its length. Three descriptors are
defined providing three packet formats — short, medium and long.

[Packet Descriptor] ::= [Short Packet Descriptor] or


[Medium Packet Descriptor] or
[Long Packet Descriptor]

2.2.1 Short Packet Descriptor


[Short Packet Descriptor] ::= [Short] [Type] [Length]

2.2.1.1 Short Packet (1 Bit)

0B a short packet

Volume 4: Packet Formats and Usage, Page: 3


Chapter 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1B not a short packet

2.2.1.2 Type (3 Bits)

Defines the type of the packet.

2.2.1.3 Length (4 Bits)

An unsigned binary number giving the number of bytes from the end of the [Length] field.

2.2.2 Medium Packet Descriptor


[Medium Packet Descriptor] ::= [Medium] [Type] [Length]

2.2.2.1 Medium Packet (2 Bits)

10B a medium packet format

2.2.2.2 Type (6 Bits)

Defines the type of the packet.

2.2.2.3 Length (8 Bits)

An unsigned binary number giving the number of bytes from the end of the [Length] field.

2.2.3 Long Packet Descriptor


[Long Packet Descriptor] ::= [Long] [Type] [Length]

2.2.3.1 Long Packet (2 Bits)

11B a long packet format

2.2.3.2 Type (6 Bits)

Defines the type of the packet.

2.2.3.3 Length (16 Bits)

An unsigned binary number giving the number of bytes from the end of the [Length] field.

2.3 ISL Packets Carrying TDM or Signalling Traffic


ISL packets used to carry packets to be transmitted on a TDM channel, are simply the TDM packets
and therefore have identical format.

Packets received on a Signalling channel and re-transmitted over an Interstation Signalling Link (ISL)
are treated according to the following rules:

1) Continuation packets are combined into a single packet.

2) All checksums from the original packets are removed.

3) Only the packet descriptor from the first (or only) packet is retained, all others are removed.

4) The resulting packet is enveloped in a special ISL packet, with type 04H. This envelope has its
own newly computed checksum.

Volume 4: Packet Formats and Usage, Page: 4


Chapter 1: Introduction
FIG. 1-1 Error Detection Coding Algorithm

GENERATOR CHECKER
C0=0, C1=0 C0=0, C1=0
Inmarsat Confidential

Chapter 1: Introduction
B = First Byte B = First Byte

Volume 4: Packet Formats and Usage,


C0 = C0 + B B = Next Byte C0 = C0 + B B = Next Byte
Figure 1: Error Detection Coding Algorithm

C1 = C1 + C0 C1 = C1 + C0

More More
Bytes Bytes
? ?

Notes:
CB1 = C0 - C1 1. Arithmetic is Modulo 256 C0
CB2 = C1 - 2C0 2. Perform Encoding on Data + and C1 = 0 DATA IN ERROR
Zeros in Checksum Field ?
3. Perform Checker on all Data
Place CB1 & CB2 in Bytes including Checksum
Checksum Field 4. CB2 forms last byte of packet.
DATA CORRECT

D1/3-15/cfh

Page: 5
(Version Release CD004, CN000)
C SDM
FIG. 1-2 TDM and ISL Packet Structures

Bits
Inmarsat Confidential

Chapter 1: Introduction
8 7 6 5 4 3 2 1

Bits 1 1 Type
8 7 6 5 4 3 2 1
Bits Length
1 0 Type
8 7 6 5 4 3 2 1 Length

Volume 4: Packet Formats and Usage,


0 Type Length
Figure 2: TDM and ISL Packet Structures

Information Information Information

Checksum 1 Checksum 1 Checksum 1


2 2 2

Short Packet Structure Medium Packet Structure Large Packet Structure

D1/3-22/cfh

Page: 6
(Version Release CD004, CN000)
C SDM
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Chapter 2: Bulletin Board and Signalling Channel


Descriptors

Contents

1 General Structure .................................................................... 3

2 Packet Types ........................................................................... 3

3 Specific Packet Format............................................................ 3


3.1 Bulletin Board ....................................................................................................3
3.1.1 Packet Descriptor ...........................................................................................3
3.1.2 Network Version (8 Bits) ................................................................................3
3.1.3 Frame Descriptor ...........................................................................................3
3.1.3.1 Frame Number (16 Bits)........................................................................................................ 3

3.1.3.2 Signalling Channels (6 Bits) .................................................................................................. 4

3.1.3.3 2-Frame Count (6 Bits).......................................................................................................... 4

3.1.3.4 Empty Frame (1 Bit) .............................................................................................................. 4

3.1.3.5 Spare (3 Bits) ........................................................................................................................ 4

3.1.4 TDM Descriptor ..............................................................................................4


3.1.4.1 Channel Type (3 bits) ............................................................................................................ 4

3.1.4.2 Local ID (3 bits) ..................................................................................................................... 4

3.1.4.3 Spare (2 Bits) ........................................................................................................................ 4

3.1.4.4 Origin ID (8 bits) .................................................................................................................... 4

3.1.4.5 Status (8 bits) ........................................................................................................................ 5

3.1.4.6 Services (16 bits) .................................................................................................................. 5

3.1.4.7 Randomizing Interval (8 bits) ................................................................................................ 6

3.1.5 Checksum (16 bits) ........................................................................................6


3.2 Signalling Channel Descriptor Packet ...............................................................6
3.2.1 Packet Descriptor ...........................................................................................6
3.2.2 Available (1 Bit) ..............................................................................................7
3.2.3 CUG (1 Bit) ....................................................................................................7
3.2.4 Maritime Distress (1 Bit) .................................................................................7

Volume 4: Packet Formats and Usage, Page: 1


Chapter 2: Bulletin Board and Signalling Channel Descriptors
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.2.5 Slotted (1 Bit) .................................................................................................7


3.2.6 Land Mobile Alerting (1 Bit) ............................................................................7
3.2.7 Aero-C (1 bit) .................................................................................................7
3.2.8 Low Power C.................................................................................................7
3.2.9 Spare (1 Bit) ...................................................................................................7
3.2.10 Satellite Frequency Code (16 bits) ...............................................................8
3.2.11 Slot State Markers (56 bits—or 28 bits for First Generation Satellites) ........8
3.2.10.1 MES Burst Rxd (1 Bit) .......................................................................................................... 8

3.2.10.2 Reserved (1 Bit) ................................................................................................................... 8

3.2.11 Checksum (16 bits) ......................................................................................8


Figure 1: TDM Bulletin Board and Signalling Channel Descriptor Formats .............9

Volume 4: Packet Formats and Usage, Page: 2


Chapter 2: Bulletin Board and Signalling Channel Descriptors
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

1 General Structure
The packets described in this table conform to the general structure of TDM packets as described in
Chapter 1, Section 1.

2 Packet Types
The bulletin board and the signalling packet descriptor can both be accommodated in a short packet.
Therefore they have both been given short packet codes.

Code Packet Origin

06H Signalling Channel Descriptor LES & NCS


07H Bulletin Board LES & NCS

3 Specific Packet Format

3.1 Bulletin Board


A diagram showing the overall bulletin board format is given in Figure 1. The bulletin board structure
is applicable to a TDM or an NCS common channel.

[Bulletin Board] ::= [Packet Descriptor] [Network Version]


[Frame Descriptor]
[TDM Descriptor]
[Checksum]

3.1.1 Packet Descriptor


The Packet Descriptor conforms to the general structure for TDM packets described in Chapter 1.

3.1.2 Network Version (8 Bits)


This field is used only on NCS common channels. It contains the current network configuration
number which is used by MESs to confirm that no changes have occurred to the network since they
were last tuned to the common channel.

For LES TDMs, this field is set to zero.

3.1.3 Frame Descriptor


This descriptor contains information specific to the frame being received.

[Frame Descriptor] ::= [Frame Number] [Signalling Channels]


[2-Frame Slot Count] [Empty Frame]
[Spare]

3.1.3.1 Frame Number (16 Bits)

This field contains an unsigned binary number which represents the sequential frame count modulo
10000, i.e. the first frame is frame 0 and the last frame is 9999 decimal.

For the NCS common channel, the beginning of frame 0 will be synchronized with midnight UTC (note
that there are 10000 frames in twenty four hours).

Volume 4: Packet Formats and Usage, Page: 3


Chapter 2: Bulletin Board and Signalling Channel Descriptors
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

It is recommended that the LES keep frame numbers in synchronisation with real time—that is, as if
transmission never ceased.

3.1.3.2 Signalling Channels (6 Bits)

An unsigned binary number indicating the number of MES signalling channels associated with this
TDM and hence the number of signalling channel descriptor packets following the bulletin board. The
maximum number of signalling channels associated with any TDM is 40.

3.1.3.3 2-Frame Count (6 Bits)

Indicates the number of 2-Frame slots available in each of the MES signalling channels. A value of
zero would indicate that all slots were 3-Frame slots.

3.1.3.4 Empty Frame (1 Bit)

Indicates whether there are any packets aside from the bulletin board and signalling channel
descriptors in this frame.

1B Frame contains other packets


0B Only bulletin board and signalling channel descriptors

3.1.3.5 Spare (3 Bits)

Unused and set to zero.

3.1.4 TDM Descriptor


The fields contained in this descriptor provide details specific to a station and the TDM being
transmitted.

[TDM Descriptor] ::= [Channel Type] [Local ID] [Spare]


[Origin Id] [Status] [Services]
[Randomizing Interval]

3.1.4.1 Channel Type (3 bits)

This identifies the type of channel and is coded as follows:

0H Reserved
1H NCS Common Channel
2H LES TDM Channel
3H Joint Common and TDM
4H Standby NCS Common Channel
5H-7H Reserved

3.1.4.2 Local ID (3 bits)

Used to give a sequence number to multiple TDMs being transmitted by a particular NCS or LES. Set
to 0 for the first TDM transmitted, 1 for the second, etc.

3.1.4.3 Spare (2 Bits)

Unused, set to zero.

3.1.4.4 Origin ID (8 bits)

This uniquely identifies the ground-based station originating the bulletin board (see Volume 3, Part 1,
Chapter 3).

Volume 4: Packet Formats and Usage, Page: 4


Chapter 2: Bulletin Board and Signalling Channel Descriptors
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.1.4.5 Status (8 bits)

B8 return link speed


1 = 600 bps return link operation
0 = 300 bps return link operation

B7 operational or spare satellite operation


1 = operational
0 = spare

B6 1 = in service
0 = out of service

B5 1 = clear
0 = congested

B4 used only by land earth stations


1 = terrestrial links open
0 = terrestrial links closed

B3-B2 Spare

B1 used to indicate Security/Covert alert supported


1 = Security/Covert alerting supported
0 = Security/Covert alerting not supported

3.1.4.6 Services (16 bits)

Byte 1

B8 1 = Maritime Distress Alerting


0 = No Maritime Distress Alerting

B7 1 = SafetyNETSM Traffic
0 = No SafetyNETSM Traffic

B6 1 = Inmarsat-C Traffic
0 = No Inmarsat-C Traffic

B5 1 = Store and Forward


0 = No Store and Forward

B4 Spare, set to zero.

B3 1 = Enhanced Data Reporting


0 = No Enhanced Data Reporting

B2 1 = Closed Network
0 = No Closed Network

B1 1 = FleetNETSM Traffic
0 = No FleetNETSM Traffic

Volume 4: Packet Formats and Usage, Page: 5


Chapter 2: Bulletin Board and Signalling Channel Descriptors
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Byte 2

B8 1 = Prefixed Store and Forward Message supported


0 = Prefixed Store and Forward Message not supported

B7 1 = Land mobile alerting


0 = No land mobile alerting

B6 1 = Aero-C service supported


0 = Aero-C not supported

B5 1 = ITA2 transmission supported


0 = ITA2 transmission not supported

B4 1 = Data transmission supported


0 = Data transmission not supported

B3 1 = Basic X.400 supported


0 = Basic X.400 not supported

B2 1 = Enhanced X.400 supported


0 = Enhanced X.400 not supported

B1 = 1 Low Power C MES supported


= 0 Low Power C MES not supported

3.1.4.7 Randomizing Interval (8 bits)

A binary value giving the number of frames, in the range 1 to 255, over which a mobile earth station
that has received a collision marker must randomize its delay before attempting retransmission.

3.1.5 Checksum (16 bits)


This is a checksum of all the fields in the bulletin board. The algorithm used is given in Chapter 1,
Figure 1-1.

3.2 Signalling Channel Descriptor Packet


Each TDM has associated with it one or more signalling channels. For each signalling channel, a
signalling channel descriptor packet describes the frequency for that channel and the state of the
slots.

Signalling Channel Descriptor] ::= [Packet Descriptor]


[Available] [CUG] [Maritime Distress] [Slotted]
[Land Mobile Alerting] [Aero-C] [Low Power C]
[Spare][Satellite Frequency Code]
[Slot State Markers]
[Checksum]

3.2.1 Packet Descriptor


The Packet Descriptor conforms to the general structure for TDM packets described in Chapter 1.

Volume 4: Packet Formats and Usage, Page: 6


Chapter 2: Bulletin Board and Signalling Channel Descriptors
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.2.2 Available (1 Bit)


Indicates whether the signalling channel described by this packet is available for Store and Forward
messaging. The flag is coded as follows:

1B Available for the Store and Forward Message service,


0B Not available for the Store and Forward Message service.

3.2.3 CUG (1 Bit)


The CUG flag indicates whether this signalling channel is available for use by Closed User Groups.
Allocation of Closed User Groups and MES assignment to signalling channels is undertaken by the
LES concerned. The flag is coded as follows:

1B Signalling channel available for Closed User Group use,


0B Signalling channel not available for Closed User Group use.

3.2.4 Maritime Distress (1 Bit)


The Maritime Distress flag informs MESs whether this signalling channel is available for Maritime
Distress traffic. The flag is coded as follows:

1B Signalling channel available for Maritime Distress traffic,


0B Signalling channel not available for Maritime Distress traffic.

3.2.5 Slotted (1 Bit)


Indicates that the signalling channel is for slotted Aloha access. The flag is coded as follows:

1B Slotted Aloha access


0B Pure Aloha Access

3.2.6 Land Mobile Alerting (1 Bit)


The Land Mobile Alerting flag informs MESs whether this signalling channel is available for Land
Mobile Alerting traffic. The flag is coded as follows:

1B Signalling channel available for Land Mobile Alerting traffic,


0B Signalling channel not available for Land Mobile Alerting traffic.

3.2.7 Aero-C (1 bit)


Indicates that the signalling channel is available for Aero-C traffic. The flag is coded as follows:

1B Signalling channel available for Aero-C traffic,


0B Signalling channel not available for Aero-C traffic.

3.2.8 Low Power C


1B Signalling Channel available exclusively for all types of unreserved signalling from a Low
Power C MES (to enable this feature all other bits related to other services must be set to
zero)

0B Signalling Channel is available NOT exclusively for the Low power C MES signalling.

3.2.9 Spare (1 Bit)

Volume 4: Packet Formats and Usage, Page: 7


Chapter 2: Bulletin Board and Signalling Channel Descriptors
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Unused and set to zero

3.2.10 Satellite Frequency Code (16 bits)


A binary number indicating the 5kHz channel of the signalling channel being described. FFFFH is
reserved to indicate that the channel record is unused.

3.2.11 Slot State Markers (56 bits—or 28 bits for First Generation Satellites)
Each slot has two bits associated with it. The first bit indicates whether or not a transmission has been
successfully received in the same slot of the previous multiframe, and the second bit indicates
whether the current slot is reserved or unreserved.

[Slot State Markers] ::= [Slot State]28 or 14

[Slot State] ::= [MES Burst Rxd] [Reserved]

3.2.10.1 MES Burst Rxd (1 Bit)

1B= MES signalling channel packet received and correctly decoded.


0B= No MES signalling channel packet was received, or burst(s) received in error;

3.2.10.2 Reserved (1 Bit)

1B= Slot reserved


0B= Slot unreserved

3.2.11 Checksum (16 bits)


This is a checksum of all the fields in the signalling packet descriptor. The algorithm used is given in
Figure 1.

Volume 4: Packet Formats and Usage, Page: 8


Chapter 2: Bulletin Board and Signalling Channel Descriptors
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 1: TDM Bulletin Board and Signalling Channel Descriptor Formats

Figure 1: TDM Bulletin Board and


Signalling Channel Descriptor Formats

Bit No.
8 7 6 5 4 3 2 1
0 Type Length Packet Descriptor
Network Version

Frame Number

Sig Channels 2-F


Count E Spare
Channel Local Spare
Origin ID
Status

Services

Rnd Interval

Checksum

BULLETIN BOARD

0 Type Length 0 Type Length


A C D S L Æ Lp Sp A C D S L Æ Lp Sp
Satellite Frequency Satellite Frequency
Code Code
14 x 2 bit
Slot State
Markers
28 x 2 bit
Spare Slot State
Markers
Checksum

Checksum

SIGNALLING CHANNEL SIGNALLING CHANNEL


DESCRIPTOR PACKET DESCRIPTOR PACKET
- 1st GENERATION - 2nd GENERATION

Volume 4: Packet Formats and Usage, Page: 9


Chapter 2: Bulletin Board and Signalling Channel Descriptors
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Chapter 3: TDM Packet Formats

Contents

1 General Structure .................................................................... 5

2 Packet Types ........................................................................... 5

3 Specific Packet Format............................................................ 6


3.1 Acknowledgement .............................................................................................6
3.1.1 Errored Packet Numbers (8*N bits) ................................................................6
3.1.2 Spare (2 Bits) .................................................................................................6
3.2 Acknowledgement Request ..............................................................................6
3.2.1 Spare (2 Bits) .................................................................................................6
3.3 Announcement ..................................................................................................6
3.3.1 Priority (2 Bits) ...............................................................................................6
3.3.2 To-Mobile Assignment ...................................................................................7
3.3.2.1 Performance Verification Assignment .................................................................................... 7

3.4 LES Forced Clear .............................................................................................7


3.4.1 Reason for Clear (8 Bits)................................................................................7
3.5 Clear .................................................................................................................7
3.6 Confirmation......................................................................................................8
3.7 Continued Packet A & B....................................................................................8
3.7.1 Original Packet Descriptor .............................................................................8
3.7.2 First Part of Information..................................................................................8
3.7.3 Second Part of Information ............................................................................8
3.8 Distress Alert Acknowledgement ......................................................................8
3.9 Distress Test Request .......................................................................................8
3.10 EGC Packet ....................................................................................................8
3.10.1 EGC - Single Header ...................................................................................8
3.10.1.1 Single EGC Header.............................................................................................................. 9

3.10.1.1.1 Service Code (8 Bits) ........................................................................................................ 9

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 1
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.10.1.1.2 Continuation (1 Bit) ........................................................................................................... 9

3.10.1.1.3 Priority (2 Bits) ................................................................................................................... 9

3.10.1.1.4 Repetition Number (5 Bits) ................................................................................................ 9

3.10.1.1.5 Message Sequence Number (16 Bits) ............................................................................ 10

3.10.1.1.6 Packet Sequence Number (8 Bits).................................................................................. 10

3.10.1.1.7 Address ........................................................................................................................... 10

3.10.1.1.8 EGC Checksum (16 Bits) ................................................................................................ 12

3.10.1.2 Information ......................................................................................................................... 12

3.10.2 EGC — Double Header.............................................................................. 12


3.11 Logical Channel Assignment ......................................................................... 12
3.11.1 Service Dependent Assignment ................................................................. 12
3.11.1.1 From-Mobile S&F Message Assignment ........................................................................... 13

3.11.2 Spare (2 Bits) ............................................................................................. 13


3.12 Login Acknowledgment ................................................................................. 13
3.12.1 Common Channel (16 Bits) ........................................................................ 13
3.12.2 Network Version (8 Bits) ............................................................................ 13
3.13 Logout Acknowledgement ............................................................................. 13
3.14 Message Data ............................................................................................... 13
3.14.1 Packet Sequence Number (8 Bits) ............................................................. 13
3.14.2 Data (Up to 1024 Bits) ............................................................................... 13
3.15 Message Status ............................................................................................ 14
3.16 Network Update ............................................................................................ 14
3.16.1 Network Version (8 Bits) ............................................................................ 14
3.17 Request Status ............................................................................................. 14
3.17.1 Pending / Reject Flag (1 Bit) ...................................................................... 14
3.17.2 Request Status Code (7 Bits)..................................................................... 14
3.18 Test Result .................................................................................................... 15
3.18.1 Test Results (24 Bits) ................................................................................. 15
3.18.1.1 Attempts (2 Bits) ................................................................................................................. 15

3.18.1.2 BBER (2 bits) ..................................................................................................................... 15

3.18.1.3 Forward Attempts (2 Bits) .................................................................................................. 15

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 2
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.18.1.4 Return Attempts (2 Bits) ..................................................................................................... 15

3.18.1.5 Distress Alert Test (4 bits) .................................................................................................. 16

3.18.1.6 Signal Strength (4 Bits) ...................................................................................................... 16

3.18.1.7 Overall Result (4 bits)......................................................................................................... 16

3.18.1.8 Spare (4 Bits) ..................................................................................................................... 17

3.18.1.9 Spare (2 Bits) ..................................................................................................................... 17

3.19 Network Monitor ............................................................................................ 17


3.19.1 Service Dependant Descriptor (8bits) ........................................................ 17
3.19.2 Presentation Control (8bits) ....................................................................... 17
3.19.3 Last Count (8bits) ....................................................................................... 17
3.19.4 Type (4 bits) ............................................................................................... 17
3.19.5 Spare (4bits) .............................................................................................. 17
3.20 LES TDM Channel Descriptor ....................................................................... 17
3.20.1 LES TDM ................................................................................................... 17
3.21 Enhanced Data Report Acknowledgement ................................................... 18
3.21.1 Enhanced Data Report Descriptor (32 bits) ............................................... 18
3.21.1.1 Sequence (2 bits) ............................................................................................................... 18

3.21.1.2 Length (6 bits) .................................................................................................................... 18

4 Common Field Descriptions ................................................... 18


4.1 AM PM Bit (1 Bit) ............................................................................................ 18
4.2 LES Descriptor ................................................................................................ 18
4.2.1 LES Status (8 Bits) ....................................................................................... 18
4.2.2 LES Services (16 Bits) ................................................................................. 18
4.2.3 LES TDM ..................................................................................................... 19
4.2.3.1 Demand Assigned (16 Bits) ................................................................................................. 19

4.3 LES ID (8 Bits) ................................................................................................ 19


4.4 LES Total (8 Bits) ............................................................................................ 19
4.5 Direction (2 Bits) ............................................................................................. 19
4.6 Duration (8 Bits) .............................................................................................. 19
4.7 Frame Length (8 Bits) ..................................................................................... 19
4.8 Frame Offset (8 Bits) ....................................................................................... 19

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 3
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

4.9 Logical Channel Number (8 Bits) .................................................................... 20


4.10 Message Reference Number (24 Bits) .......................................................... 20
4.11 Message Status Descriptor ........................................................................... 20
4.11.1 Length (8 Bits)............................................................................................ 20
4.11.2 Status (1 Bit) .............................................................................................. 20
4.11.3 Attempts (7 Bits) ........................................................................................ 20
4.11.4 Non-Delivery Code (24 Bits) ...................................................................... 20
4.11.5 Address Information ................................................................................... 20
4.12 Presentation (8 Bits) ..................................................................................... 21
4.13 Satellite Frequency Code (16 Bits) ............................................................... 21
4.14 Service (4 Bits) .............................................................................................. 21
4.15 MES ID (24 Bits) ........................................................................................... 21
4.16 Message Channel (16 Bits) ........................................................................... 21
4.17 Signalling Channel (16 Bits) .......................................................................... 21
4.18 Slot Number (5 Bits) ...................................................................................... 21
4.19 To-Mobile S&F Message Assignment ........................................................... 22
4.19.1 Packets (8 Bits) .......................................................................................... 22
4.19.2 Last Count (8 Bits) ..................................................................................... 22
4.20 Sub-Address (8 Bits) ..................................................................................... 22
4.21 Text (Variable Length, Byte Aligned)............................................................. 22
Figure 1: TDM Packet Body Formats, Sheet 1 of 8............................................... 23
Figure 1: TDM Packet Body Formats, Sheet 2 of 8............................................... 24
Figure 1: TDM Packet Body Formats, Sheet 3 of 8............................................... 25
Figure 1: TDM Packet Body Formats, Sheet 4 of 8............................................... 26
Figure 1: TDM Packet Body Formats, Sheet 5 of 8............................................... 27
Figure 1: TDM Packet Body Formats, Sheet 6 of 8............................................... 28
Figure 1: TDM Packet Body Formats, Sheet 7 of 8............................................... 29
Figure 1: TDM Packet Body Formats, Sheet 8 of 8............................................... 30

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 4
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

1 General Structure
The Inmarsat-C packets transmitted on the To-Mobile TDM channels share a common packet
structure. The packet formats conform to the Inmarsat-C packet format described in Chapter 1.

2 Packet Types
The following table gives the encoding of the type field for the packets defined for the Inmarsat-C
system. Packets with codes 0H to 7H may be short packets if the information field is small enough.
The remainder may use either the medium or long packet format as appropriate.

Code Meaning Origin


00H Acknowledgement Request LES
01H Announcement NCS
02H Clear LES
03H Logical Channel Assignment LES
04H LES TDM Channel Descriptor Packet LES
05H Network Monitor Packet LES
06H Signalling Channel Descriptor LES & NCS
07H Bulletin Board LES & NCS

10H Acknowledgement LES


11H Distress Alert Acknowledgement LES & NCS
12H Login Acknowledgement NCS
13H Logout Acknowledgement NCS
19H Forced Clear LES & NCS
1AH Enhanced Data Report Acknowledgement LES

20H Distress Test Request LES


21H Area Poll NCS
22H Group Poll NCS
23H Individual Poll NCS
24H Mobile to Base Station Poll LES (Chapter 13)
25H Mobile to Mobile Poll LES (Chapter 13)
28H Confirmation NCS
29H Message Status NCS
2AH Message Data LES
2BH Network Update NCS
2CH Request Status LES & NCS
2DH Test Result LES
30H EGC Packet (Single Header) NCS
31H EGC Packet (First of Double Header) NCS
32H EGC Packet (Second of Double Header) NCS
3DH Continued Packet A LES & NCS
3EH Continued Packet B LES & NCS

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 5
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3 Specific Packet Format


The packet formats for each packet type are given here and illustrated in Figure 1. Any field used by
more than one packet is described in Section 4 of this chapter. Also the packet descriptors and
checksums, common to all packets, are not included in the following definitions or in Figure 1.

3.1 Acknowledgement
[Acknowledgement] ::= [LES ID]
[Logical Channel Number] [Frame Length]
[Duration]
[Message Channel]
[Frame Offset] [AM PM Bit][Spare][Slot number]
[Errored Packet No]... [Errored Packet No]

3.1.1 Errored Packet Numbers (8*N bits)


The sequence numbers in ascending order of the N packets received in error. The number of items
can be deduced from the packet length field.

3.1.2 Spare (2 Bits)


Unused at present and set to zero.

3.2 Acknowledgement Request


[Acknowledgement Request] ::= [LES ID]
[Logical Channel Number]
[Signalling Channel]
[Frame Offset] [AM PM Bit][Spare][Slot Number]

3.2.1 Spare (2 Bits)


Unused at present and set to zero.

3.3 Announcement
[Announcement] ::= [MES ID] [LES ID] [LES TDM]
Service] [Direction] [Priority]
or
[MES ID] [LES ID] [LES TDM]
[Service] [Direction] [Priority]
[To-Mobile Assignment]

3.3.1 Priority (2 Bits)


Coded as follows:

00B Routine
01B SPARE
10B SPARE
11B Distress

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 6
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.3.2 To-Mobile Assignment


This field is only present when the [Direction] field indicates a To-Mobile message transfer is being
announced.

[To-Mobile Assignment] ::= [To-Mobile S&F Message Assignment]


or
[Performance Verification Assignment]

3.3.2.1 Performance Verification Assignment

[Performance Verification Assignment] ::= [To-Mobile S&F Message Assignment]

3.4 LES Forced Clear


[LES Forced Clear] ::= [MES ID] [LES ID]
[Logical Channel Number]
[Reason for Clear]

3.4.1 Reason for Clear (8 Bits)


Coded as follows:

01H LES Timeout


02H MES Protocol Error Detected
03H LES Hardware Error Detected
04H Operator Forced Clear
05H MES Forced Clear
06H LES Protocol Error detected
07H MES Hardware Error detected
08H MES Timeout
09H Unrecognised Presentation code
0DH Requested service temporarily unavailable
0EH Access to requested service denied
0FH Invalid service
10H Invalid address
11H Destination MES not commissioned
12H Destination MES not logged in
13H Destination MES barred
14H Requested service not provided
0AH Unable to decode: specified dictionary version not available
0BH IWU number is invalid
0C MES has not subscribed to this service
15H protocol version not supported
16H Unrecognised PDU type
17H-FFH Spare

3.5 Clear
[Clear] ::= [MES ID] [LES ID] [Logical Channel Number]
or
[MES ID] [LES ID] [Logical Channel Number]
[Message Reference Number]

The Message Reference Number is included for From-Mobile Store and Forward Message transfers.
For To-Mobile it is not included.

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 7
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.6 Confirmation
The confirmation packet contains delivery information about the From-Mobile messages. For multiple
destination messages, one confirmation may be used to convey information concerning more than
one destination. Each destination's delivery details is given in a [Message Status Descriptor].

[Confirmation] ::= [MES ID] [LES ID]


[Message Reference Number]
[Message Status Descriptor]n

3.7 Continued Packet A & B


If the NCS or LES determines to use any remaining space in a frame by splitting a packet across the
frame boundary, then the overlapping packet is divided into two packets as follows:

[Continued Packet A] ::= [Original Packet Descriptor]


[First Part of Information]

[Continued Packet B] ::= [Second part of Information]

The split must be made after the Original Packet Descriptor. Note that the Checksum of the original
packet is removed before the packet is split. The length field in the Original Packet Descriptor,
however, is copied unchanged. Thus the original packet can be reconstructed by concatenating the
Type dependent fields of Continued Packets A and B and then re-computing a new Checksum to
append.

3.7.1 Original Packet Descriptor


The [Packet Descriptor] of the packet being split across the frame boundary.

3.7.2 First Part of Information


The [Type Dependent Fields] field of the original packet is divided into two parts. The first part is
placed in the current frame in Continued Packet A.

3.7.3 Second Part of Information


The remainder of the [Type Dependent Fields] field is placed in the next frame in the Continued
Packet B.

3.8 Distress Alert Acknowledgement


[Distress Alert Ack] ::= [MES ID] [LES ID]

3.9 Distress Test Request


[Distress Test Request] ::= [MES ID][LES ID]

3.10 EGC Packet


There are two formats of EGC packets. The simplest uses a single header per block of information.
For information requiring greater protection, a double header implementation has been used.

3.10.1 EGC - Single Header


[EGC] ::= [Single EGC Header]
[Information]

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 8
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.10.1.1 Single EGC Header

[Single EGC Header] ::= [Service Code] [Continuation] [Priority]


[Repetition Number]
[Message Sequence Number]
[Packet Sequence Number]
[Presentation]
[LES ID] [Address] EGC Checksum]

3.10.1.1.1 Service Code (8 Bits)

This field contains the type of EGC service. The least significant four bits indicate the length of the
[Address] field (in bytes) for the given service. The field is coded as follows:

Code EGC Service

00H General Call


02H Group Call
04H Urgency Message, NAV Warnings to Rectangular Areas
11H INMARSAT System Message
13H Coastal Warning
14H Shore-to-Ship Distress Alert to circular area
23H EGC System Message
24H Urgency Message, MET/NAV Warnings to Circular Area
31H MET Navarea Warnings or MET Forecast
33H Download Group Identity (ENID)
34H SAR Coordination to rectangular area
44H SAR Coordination to circular area
72H Chart Correction Service
73H Chart Correction Service for fixed areas

3.10.1.1.2 Continuation (1 Bit)

Any message longer than 256 characters will be transmitted in multiple packets. The continuation bit
is set in every packet except the last packet of a message.

3.10.1.1.3 Priority (2 Bits)

This field contains the priority of the message transmission and is coded:

00B Routine
01B Safety
10B Urgency
11B Distress

3.10.1.1.4 Repetition Number (5 Bits)

An unsigned binary number which is set to zero for the first transmission of a message, and is
incremented by one for each repetition. The repetition number shall not be incremented for echo
transmissions.

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 9
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.10.1.1.5 Message Sequence Number (16 Bits)

Each message issued under a particular service code will have a message sequence number given to
it by the LES. This sequence number, when associated with the [LES ID] value and the service code,
provides a unique message number within a certain time frame. The time before a number repeats
should be at least one month.

The LES shall assign a sequence number for transmission in the EGC packet(s). The message
identity shall comprise LES ID, service code and sequence number. For repeat EGC messages the
same message identity shall be used as for the first transmission.

3.10.1.1.6 Packet Sequence Number (8 Bits)

An unsigned binary number giving the sequence number of the packet in the EGC message. The first
packet is given the number 1, and the number incremented by 1 for each subsequent packet in the
message. Note that the two headers in the two packets of a double header message will have the
same packet sequence number.

3.10.1.1.7 Address

The address field contains addressing information appropriate to the EGC service in the packet. The
length of this field is given in the least significant four bits of the [Service Code] field.

The address coding used for the different EGC services are:

(a) EGC Network Identity (16 Bits)

Used for service code 02H and 72H, the address field contains the binary EGC network identity
(ENID);

(b) Rectangular Areas (32 Bits)

Rectangular areas are used for service codes 04H and 34H.

[Rectangular Area] ::= [N/S] [Latitude] [longitude] [E/W]


[Latitude Extent] Longitude Extent]
N/S (1 Bit)

0B North
1B South

Latitude (7 Bits)

Unsigned binary number giving the latitude of the point in degrees (the [N/S] field indicating the
hemisphere).

Longitude (8 Bits)

Unsigned binary number giving the longitude of the point in degrees (the [E/W field indicates
east or west of the Greenwich Meridian).

E/W (1 Bit)

0B East
1B West

Latitude Extent (7 Bits)

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 10
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Extent of the rectangle in degrees to the North.

Longitude Extent (8 Bits)

Extent of the rectangle to the East

(c) Circular Areas (32 Bits)

Circular areas are used for service codes 14H, 24H and 44H.

[Circular Area] ::= [N/S] [Latitude] [Longitude] [E/W]


[Radius]
N/S (1 Bit)

0B North
1B South

Latitude (7 Bits)

An unsigned binary number giving the latitude of the circle's centre in degrees (the [N/S] field
provides the hemisphere).

Longitude (8 Bits)

An unsigned binary number giving the longitude of the circle's centre in degrees (the [E/W] field
indicates whether east or west of the Greenwich Meridian).

E/W (1 Bit)

0B East
1B West

Radius (15 Bits)

An unsigned binary number giving the radius of the circle in nautical miles.

(d) Inmarsat System Message Address (8 Bits)

This address is used for service code 11H and is a binary code indicating the type of system
message. It is coded as follows:

00H All mobiles


01H AOR (East)
02H AOR (West)
03H POR
04H IOR
05H Inmarsat-A MESs
06H Inmarsat-C MESs
07H Inmarsat-B MESs
08H Inmarsat-M MESs
09H Inmarsat-B/M MESs
0AH Inmarsat Aero-C AMESs
0BH-FFH Spare

(e) Coastal warning Address (24 Bits)

Used for service code 13H, this address contains the Navarea as an unsigned binary number.
The following two bytes are a copy of the two characters B1 and B2 given in the message
received by the LES. (Alphabet IA5 is used with odd parity for characters B1 and B2.)

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 11
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

(f) Navareas (8 Bits)

An unsigned binary number giving the Navarea. This addressing is used for service code 31H.

(g) EGC Receiver Identity (24 Bits)

Used in service code 23H and 33H, this address field contains an EGC receiver's forward MES
identity number.

(h) Fixed Area (24 Bits)

Used with service code 73H. This address field contains a Chart Correction Service Fixed Area
number.

3.10.1.1.8 EGC Checksum (16 Bits)

This uses the algorithm given in Figure 1-1. The checksum is taken over the contents of the [Single
EGC Header] and the [Packet Descriptor].

3.10.1.2 Information

The information field comprises 1 to 256 bytes of user data (medium packets only).

3.10.2 EGC — Double Header


In the case where the double header format is used, the information field is split across two packets
which are sent immediately adjacent on the NCS common channel. The first packet contains an EGC
header and the first 16 bytes of the information field. The second packet contains a copy of the
header together with the remainder of the information field. The following pair of packets in the same
EGC message with the same EGC headers does not have to be adjacent to the previous pair.
If there are 16 or less information bytes to transmit in the last pair of packets, the information field of
the first packet shall contain just these information bytes and will therefore be 16 or less bytes long. In
this case, the second packet will contain no information bytes, but shall contain the header and must
still be transmitted.
In EGC transmission to the NCS single and double header packets may be used; double header
packets giving greater security. All packets containing more than 64 bytes of information shall use the
double header format. In addition all SafetyNETSM traffic containing more than 16 bytes of information
shall use double headers.

3.11 Logical Channel Assignment


[Logical Channel Assignment] ::= [MES ID] [LES ID]
[Service] [Direction] [Spare]
[Service Dependent Assignment]

3.11.1 Service Dependent Assignment


[Service Dependent Assignment] ::= [From-Mobile S&F Message Assignment]
[Frame Offset] [AM PM Bit] [Spare] [Slot number]
or
[To-Mobile S&F Message Assignment]
[Signalling Channel]
[Frame Offset] [AM PM bit] [Spare] [Slot Number]

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 12
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.11.1.1 From-Mobile S&F Message Assignment

[From-Mobile S&F Message Assignment] ::= [Logical Channel Number]


[Frame Length] [Duration]
[LES TDM]
[Message Channel]

3.11.2 Spare (2 Bits)


Unused and set to zero.

3.12 Login Acknowledgment


For each land earth station in the region, the login acknowledgement packet will contain one LES
descriptor.

[Login Acknowledgement] ::= [MES ID] [Common Channel]


[Network Version] [LES Total]
[LES Descriptor]LES Total
or
[MES ID] [Common Channel]

3.12.1 Common Channel (16 Bits)


This field contains a satellite frequency code of an NCS common channel being used in the ocean
region.

3.12.2 Network Version (8 Bits)


The version number of the ocean region's network configuration expressed as an unsigned binary
number. The value zero is reserved for use by mobile earth stations.

3.13 Logout Acknowledgement


[Logout Acknowledgement] ::= [MES ID]

3.14 Message Data


[Message Data] ::= [LES ID] [Logical Channel Number]
[Packet Sequence Number]
[Data]

3.14.1 Packet Sequence Number (8 Bits)


An unsigned binary number giving the sequence number of the packet in the message. The first
packet is given the number 1, and the number is incremented by 1 for each subsequent packet in the
message.

3.14.2 Data (Up to 1024 Bits)


The part of the message data contained in the packet.

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 13
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.15 Message Status


This packet follows the same format as the confirmation packet.

[Message Status] ::= [MES ID] [LES ID]


[Message Reference Number]
[Message Status Descriptor]n

3.16 Network Update


For each land earth station in the region, the network update packet will contain one LES descriptor.

[Network Update] ::= [Network Version]


[LES Total]
[LES Descriptor]LES Total

3.16.1 Network Version (8 Bits)


The version number of the ocean region's network configuration expressed as an unsigned binary
number. The value zero is reserved for use by mobile earth stations.

3.17 Request Status


[Request Status] ::= [MES ID] [LES ID]
[Pending/Reject Flag]
[Request status Code]

3.17.1 Pending / Reject Flag (1 Bit)


This flag indicates whether the request is permanently rejected or whether an announcement will
follow. It is coded as:

0B Pending
1B Rejected

3.17.2 Request Status Code (7 Bits)


Gives the status of an assignment request attempt by a mobile earth station. It is coded as follows:

01H LES Message Store Full


02H Requested Destination not Served
03H Satellite Congestion
04H Terrestrial Congestion
05H Requested Service not provided
06H Request in queue
07H Request Barred
08H MES not logged in
09H MES not Commissioned
0AH Waiting TDM Assignment
0BH Illegal Request
0CH LES not in service
0DH Requested service temporarily unavailable
0EH Access to requested service denied
0FH Invalid service
10H Invalid address (in assignment request)
15H PSTN modem type not supported
11H Unable to decode: specified dictionary version not available

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 14
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

12H IWU number is invalid


13H MES has not subscribed to this service
14H Protocol version not supported
16H Unrecognised PDU type
17H-7FH Spare

3.18 Test Result


Returns the results of either a commissioning or a performance verification to the mobile earth station.

[Test Result] ::= [MES ID] [LES ID]


[Test Results] [Signalling Channel]
[Frame Offset] [AM PM Bit] [Spare] [Slot Number]

3.18.1 Test Results (24 Bits)


[Test Results] ::= [Attempts] [BBER]
[Forward Attempts] [Return Attempts]
[Distress Alert Test] [Signal Strength]
[Overall Result] [Spare]

3.18.1.1 Attempts (2 Bits)

Contains the number of full attempts made at the test sequence including the attempt that was
successful, i.e. PV Counter + 1. The value zero implies that the sequence failed after the third
attempt.
Thus:

00B Third attempt failed


01B First attempt
10B Second attempt
11B Third attempt

3.18.1.2 BBER (2 bits)

This field contains the result of the Bulletin Board Error Rate assessment carried out over the last 100
bulletin boards received by the MES. It is coded as follows:

00B Not used


01B Pass
10B Fail
11B Not used

The threshold for Pass/Fail should be adjustable at the LES.

3.18.1.3 Forward Attempts (2 Bits)

This field contains the number of attempts required to successfully transfer the message from the LES
to the MES. A value of zero indicates that the message failed to be delivered.

3.18.1.4 Return Attempts (2 Bits)

This field contains the number of attempts required to successfully transfer the message from the
MES to the LES. A value of zero indicates that the message failed to be delivered.

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 15
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.18.1.5 Distress Alert Test (4 bits)

Code Meaning Test Result

0H No Response FAIL
1H Not Applicable PASS
2H Test OK PASS
3H Nature of Distress: not Default PASS
4H Null Data PASS
5H Incorrect Protocol FAIL
6H Invalid Data Format FAIL
7H Automatically Activated
8H-FH Spare

3.18.1.6 Signal Strength (4 Bits)

The apparent signal strength received at the LES coded as follows:

Code Definition Result

0H No response, unreadable FAIL


1H Less than X dB PASS
2H Greater than or equal to X dB PASS
3H Greater than X + 3 dB PASS
4H Greater than X + 6 dB PASS
5H Greater than X + 10 dB PASS
6H Greater than X + 13 dB PASS
7H Greater than X + 16 dB FAIL

3.18.1.7 Overall Result (4 bits)

Code Meaning Test Result

0H Applicable tests pass PASS


1H Applicable tests pass PASS
2H Applicable tests pass PASS
3H Applicable tests pass PASS
4H Forward message transfer fail FAIL
5H Return message transfer fail FAIL
6H Signal unreadable FAIL
7H Signal level excessive FAIL
8H Distress alert test fail FAIL
9H Unspecified fail FAIL
AH-FH Spare

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 16
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.18.1.8 Spare (4 Bits)

Unused, set to zero.

3.18.1.9 Spare (2 Bits)

Unused, set to zero.

3.19 Network Monitor


[Network monitor] ::= [Type][Spare]
[MES ID][LES ID][Logical Channel Number]
[Message Reference Number]
[Service Dependant Descriptor]
[Presentation Control][Last Count]

3.19.1 Service Dependant Descriptor (8bits)


[Service Dependent Descriptor] ::= [Message Length]

- Message Length (8 Bits)

An unsigned binary number giving the number of message packets to be transferred (up to 255).

3.19.2 Presentation Control (8bits)


This field indicates the manner in which the data field has been formatted for presentation. The coding
of this field is defined in Chapter 3, Section 4.12 The only valid codes for the mandatory Store and
Forward Telex service are ITA2 and IA5. For messages to be delivered to a PSDN, this field shall be
set to the DATA code; that is, no pre-defined alphabet to be assumed by earth stations.

3.19.3 Last Count (8bits)


An unsigned binary number giving the number of whole characters or bytes in the last packet of the
message. If the presentation code defines an alphabet, then this field indicates the number of whole
characters, otherwise it is the number of bytes.

3.19.4 Type (4 bits)


A hex code identifying digit which defines the use of the monitor packet.

00H From mobile message information packet.


01H – 0FH Spare.

3.19.5 Spare (4bits)


Unused set to zero.

3.20 LES TDM Channel Descriptor


The packet describes up to N TDM channels associated with that LES, where N ≤ 7 (primary TDM + 7
= 8 TDMs; the maximum allowable for a single LES). The packet is a short packet type if the number
of LES TDMs described is 6 or less.

3.20.1 LES TDM

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 17
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

This field indicates the satellite channel being used for an LES TDM.

[LES TDM] ::= [Satellite Frequency Code]


or
[Demand Assigned]

[Demand Assigned] is not applicable in this context.

Each additional TDM will have a unique Local ID (1 – 7).

3.21 Enhanced Data Report Acknowledgement


[Enhanced data report acknowledgement] ::=[EDR descriptor]N

3.21.1 Enhanced Data Report Descriptor (32 bits)


[EDR descriptor] ::= [MES ID] [Sequence] [Length]

The sequence and length fields (8 bits) are simply copied from the received enhanced data report for
which the acknowledgement refers.

3.21.1.1 Sequence (2 bits)

Each time a new enhanced data report is sent, the Sequence number is incremented, modulo-4.
Repeats of previously sent, but unacknowledged, data reports have the same Sequence number (and
length field). The sequence number and length are the same as for the data report to which the
acknowledgement refers.

3.21.1.2 Length (6 bits)

Defines the length, in bytes, of the data contents of the data report to which the acknowledgement
refers.

4 Common Field Descriptions


The following describes the fields which are used by more than one packet.

4.1 AM PM Bit (1 Bit)


A flag to indicate whether the frame given to an MES in the [Frame Offset] field is before or after the
transition from frame 9999 to 0000. This bit resolves an ambiguity arising from the [Frame Offset] field
only containing the lower 8 bits of the frame number. The field is encoded as follows:

0B Frame to transmit is in range 0 – 4999;


1B Frame to transmit is in range 5000 – 9999.

4.2 LES Descriptor


[LES Descriptor] ::= [LES ID] [LES Status]
[LES Services] [LES TDM]

4.2.1 LES Status (8 Bits)


For the definition of this field see Chapter 2, Section 3.1.4.5.

4.2.2 LES Services (16 Bits)

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 18
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

or the definition of this field see Chapter 2, Section 3.1.4.6.

4.2.3 LES TDM


This field indicates the satellite channel being used for an LES primary TDM. When received by a
mobile earth station, the value gives the channel to be used in subsequent initial interactions with the
LES, until information regarding other permanent TDMs (if any) transmitted by that LES is available.

[LES TDM] ::= [Satellite Frequency Code]


or
[Demand Assigned]

4.2.3.1 Demand Assigned (16 Bits)

A value of FFFFH in the LES TDM field implies that the particular land earth station is operating with
demand assigned TDM carriers.

4.3 LES ID (8 Bits)


A number uniquely identifying a particular land earth station.

4.4 LES Total (8 Bits)


The total number of operating land earth stations in the region.

4.5 Direction (2 Bits)


Provides the direction of the message transfer. Coded as:

0H To-Mobile
1H From-Mobile
2H SPARE
3H Both directions

4.6 Duration (8 Bits)


An unsigned binary number corresponding to the number of frames (of length defined by the frame
length parameter) the the mobile earth station is being authorized to transfer.

4.7 Frame Length (8 Bits)


This field indicates the frame length that is to be used in the transfer from the mobile earth station
over the message channel. It is coded as follows:

01H 2048
02H 4096
03H 6144
04H 8192
05H 10240

The lengths are in terms of modulation symbols.

4.8 Frame Offset (8 Bits)


The least significant 8 bits of the number of the corresponding TDM frame in which the MES is
required to transmit.

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 19
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

4.9 Logical Channel Number (8 Bits)


A number assigned by the land earth station for a logical channel established with a particular mobile
earth station for the duration of a message. Uniquely identifies a particular message transfer while the
transfer process is active. Valid logical channel numbers (LCN) are in the range 1 to 255. LCN 0 is
used for forced clearing any attempted call setup which is not fully established and in situations where
no LCN is applicable; for example, during PVT. In the case of an LES returning a Forced Clear, the
LES shall use the same Logical channel number, if any, as given by the MES. During PVT, LCN 0 is
used as the last LCN for the last Clear of a valid PVT.

4.10 Message Reference Number (24 Bits)


A number assigned by the land earth station. The message reference number allows a land earth
station to refer to a message not active on a logical channel.

4.11 Message Status Descriptor


[Message Status Descriptor] ::= [Length] [Status] [Attempts]
[Address Information]
or
[Length] [Status] [Attempts] [Non-delivery Code]
[Address Information]

4.11.1 Length (8 Bits)


The length of the descriptor (including the [length] field itself).

4.11.2 Status (1 Bit)


This bit is set to one if the message has been successfully delivered. If it is zero, then the [Non-
delivery Code] field will be present indicating the reason for non-delivery. Note that if attempts to
deliver the message have not started, the [Attempts] count will be zero.

4.11.3 Attempts (7 Bits)


This field represents the number of delivery attempts that have been made. The value 7FH is used to
indicate that the message reference is invalid or has expired.

4.11.4 Non-Delivery Code (24 Bits)


This field will hold a failure code of up to three characters formatted as IA5 with odd parity. The
meaning of the codes are LES specific. The code 000 (zero, zero, zero) is reserved to indicate
unknown status; for example, when the Logical channel number is zero. It is recommended that the
CCITT codes as used, for example, in the Red Book recommendation X.28, Table A-3, should be
used. A code should also be included to indicate "Yet to be delivered".

4.11.5 Address Information


This is a variable length byte-aligned field containing message destination address information. It is
supplied by the land earth station servicing the call.

For single address messages, where the status bit is set to one, this field shall not be used. For all
destination networks, addresses will be in IA5 with odd parity and will contain the address (NOT the
address line) as defined in CCITT recommendation U.80.

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 20
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

4.12 Presentation (8 Bits)


This field indicates the manner in which the message data or EGC information fields have been
formatted for presentation. The following codes have been allocated:

00H IA number 5 (IRV version), odd parity


01H-05H Reserved
06H ITA 2
07H Data (no pre-defined alphabet to be assumed by earth stations)
08H-7FH Spare
80H Basic X.400 encoding
81H Unregistered MTA Service
82H Registered MTA Service
83H Mailbox Service
84H-FFH Spare

4.13 Satellite Frequency Code (16 Bits)


An unsigned binary number giving the specific 5kHz satellite channel to be used by a mobile earth
station for a given channel type. The channel coding is given in Volume 3, Part 1, Chapter 2,
Section 3.2.1.

4.14 Service (4 Bits)


This field gives the type of interaction between the MES and the LES. It is coded as follows:

0H Store-and-Forward (message)
1H Half-duplex data
2H Reserved for circuit switched data (bit transparent - no ARQ)
3H Reserved for circuit switched data (with ARQ)
4H-DH Spare
EH Message-Performance Verification
FH Reserved

4.15 MES ID (24 Bits)


A number allocated by INMARSAT for use in the forward direction, uniquely identifying a particular
mobile earth station.

4.16 Message Channel (16 Bits)


This field contains a satellite frequency code defining the channel to be used by the MES for the
transmission of a message.

4.17 Signalling Channel (16 Bits)


This field contains a satellite frequency code defining the satellite channel to be used by the MES for
the transmission of a signalling channel burst.

4.18 Slot Number (5 Bits)


An unsigned binary number giving the number of the slot in the signalling channel that a mobile earth
station will use to begin its transmission.

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 21
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

4.19 To-Mobile S&F Message Assignment


[To-Mobile S&F Message Assignment] ::= [Logical Channel Number]
[Message Reference Number]
[Sub-address] [Presentation]
[Packets] [Last Count]

4.19.1 Packets (8 Bits)


An unsigned binary number giving the number of packets to be transferred on the land earth station's
TDM.

4.19.2 Last Count (8 Bits)


An unsigned binary number giving the number of whole characters or bytes in the last packet of the
message. If the presentation code defines an alphabet, then this field is the number of whole
characters, otherwise it is the number of bytes.

4.20 Sub-Address (8 Bits)


This field is used to address different ports attached to the DCE of the mobile earth station. The main
DTE is designated 00H.

4.21 Text (Variable Length, Byte Aligned)


A variable length field containing information specific to a particular closed network identity.

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 22
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 1: TDM Packet Body Formats, Sheet 1 of 8

Figure 1: TDM Packet Body Formats


Sheet 1 of 8

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
LES ID LES ID
Logical Channel No. Logical Channel No.
Frame Length
Signalling
Duration Channel
Message Frame Offset
Channel A Spare Slot No
Frame Offset
A Spare Slot No Acknowledgement Request
Errored Packet No.
Errored Packet No.

Errored Packet No.

Acknowledgement
Bit No. Bit No.
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

MES ID MES ID

LES ID LES ID

LES TDM LES TDM

Service D P Service D P
Logical Channel No.
Announcement
From- Mobile S&F Message Message Reference
Number

Sub-address
Presentation
Packets
Last Count

Announcement
(To Mobile S&F Message or
Performance Verification)

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 23
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 1: TDM Packet Body Formats, Sheet 2 of 8

Figure 2: TDM Packet Body Formats


Sheet 2 of 8

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

MES ID MES ID

LES ID LES ID
Logical Channel No.
Logical Channel No.
Reason for Clear
Message
Reference
Number LES Forced Clear

Clear (From-Mobile
message transfer)

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

MES ID MES ID

LES ID LES ID
Logical Channel No.
Message
Reference
Clear (To-Mobile Number
message transfer)

Message Status
Descriptor
1

Message Status
Descriptor
n

Confirmation

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 24
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 1: TDM Packet Body Formats, Sheet 3 of 8

Figure 1: TDM Packet Body Formats


Sheet 3 of 8

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

Original Packet
Descriptor MES ID
(1, 2 or 3 bytes)

LES ID
First Part
of
Information Distress Alert Acknowledgement

Bit No.
8 7 6 5 4 3 2 1

Second Part
of
Information

Continued Packet A (top)


& B (bottom)

Bit No.
8 7 6 5 4 3 2 1

MES ID

LES ID

Distress Test Request

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 25
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 1: TDM Packet Body Formats, Sheet 4 of 8

Figure 1: TDM Packet Body Formats


Sheet 4 of 8

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

MES ID MES ID

LES ID LES ID
Service D Spare Service D Spare
Logical Channel No. Logical Channel No.
Frame Length
Message Reference
Duration
Number
LES TDM
Sub-address
Message Presentation
Channel Packets
Frame Offset Last Count
A Spare Slot No. Signalling
Channel

Logical Channel Assignment Frame Offset


(Store & Forward, From Mobile) A Spare Slot No.

Logical Channel Assignment


(Store & Forward, To Mobile)

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 26
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 1: TDM Packet Body Formats, Sheet 5 of 8

Figure 1: TDM Packet Body Formats


Sheet 5 of 8

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

MES ID MES ID

Common Channel Common Channel

Network Version
LES Total Login Acknowledgement
LES ID (alternative)
LES Status
LES Descriptor
LES Services for
LES number 1

LES TDM

LES Descriptor
for
LES number
"LES Total"

Login Acknowledgement

Bit No.
8 7 6 5 4 3 2 1

MES ID

Logout Acknowledgement

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 27
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 1: TDM Packet Body Formats, Sheet 6 of 8

Figure 1: TDM Packet Body Formats


Sheet 6 of 8
Bit No.
Bit No.
8 7 6 5 4 3 2 1
8 7 6 5 4 3 2 1

LES ID
MES ID
Logical Channel No.
Packet Sequence Number
LES ID

Message
Reference Number

Data Message Status


(max 1024 Bits) Descriptor
1

Message Data
Message Status
Descriptor
n

Bit No. Message Status


8 7 6 5 4 3 2 1

Network Version Bit No.


LES Total 8 7 6 5 4 3 2 1
LES ID
LES Status TYPE SPARE
LES Descriptor
LES Services for
LES number 1 MES ID
LES TDM

LES ID
L.C.N

Message
Reference
Number
LES Descriptor
for
Service Dependant Descriptor
LES number "LES Total"
Presentation
Last Count

Network Update Network Monitor

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 28
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 1: TDM Packet Body Formats, Sheet 7 of 8

Figure 1: TDM Packet Body Formats


Sheet 7 of 8

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

MES ID MES ID

LES ID LES ID
PR Request Status
Test Results
Request Status

Signalling
Channel
Frame Offset
A Spare Slot No.

Bit No. Test Result

8 7 6 5 4 3 2 1

Enhanced
MES ID Data Report Bit No.
descriptor
8 7 6 5 4 3 2 1
Seq Length (MES 1)

LES TDM 1

Enhanced Data
Report LES TDM N
descriptor
(MES N)

LES TDM channel


descriptor
Enhanced Data Report
Acknowledgement

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 29
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 1: TDM Packet Body Formats, Sheet 8 of 8

Figure 1: TDM Packet


Body Formats, Sheet 8 of 8

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
Service Code
Message Sequence No. C P Repetition
RS Spare Message Sequence
Number
EGC Acknowledgement Packet Sequence No.
Presentation
LES ID

Address
Information

CRC

Information

EGC, Single Header

Bit No.
Bit No. 8 7 6 5 4 3 2 1
8 7 6 5 4 3 2 1
Service Code
Service Code
C P Repetition
C P Repetition
Message Sequence Message Sequence
Number Number
Packet Sequence No.
Packet Sequence No.
Presentation
Presentation
LES ID LES ID

Address Address
Information Information

CRC CRC

Information
16 Bytes Information

EGC, First Header EGC, Second Header

Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 30
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Chapter 4: Signalling Channel Formats

Contents

1 General Structure .................................................................... 4


1.1 Signalling Channel Packet ................................................................................4
1.1.1 Signalling Packet Descriptor ..........................................................................4
1.1.1.1 Priority (1 bit) .......................................................................................................................... 4

1.1.1.2 Continuation (1 bit) ................................................................................................................. 4

1.1.1.3 Type (6 Bits) ........................................................................................................................... 4

1.1.2 Type Dependent Fields ..................................................................................4


1.1.3 Checksum (16 Bits) ........................................................................................4
1.1.4 Fill ..................................................................................................................4

2 Packet Types ........................................................................... 5

3 Specific Packet Formats .......................................................... 5


3.1 Acknowledgement .............................................................................................5
3.1.1 Errored Packet No. (8 Bits) ............................................................................5
3.2 Announcement Response .................................................................................5
3.3 Assignment Request .........................................................................................6
3.3.1 Protocol ..........................................................................................................6
3.3.2 Packet Body ...................................................................................................6
3.3.2.1 Service Dependent Descriptor ............................................................................................... 6

3.3.2.2 Destination Descriptor ............................................................................................................ 6

3.3.2.2.1 Destination Network (3 Bits) ............................................................................................... 7

3.3.2.2.2. Extension Length (2 Bits) ................................................................................................... 7

3.3.2.2.3. Address Location (3 Bits) ................................................................................................... 7

3.3.2.2.4 Destination Extension (0 to 24 Bits) .................................................................................... 9

3.3.2.2.5. Address .............................................................................................................................. 9

3.3.2.3 Examples.............................................................................................................................. 11

3.4 Assignment Response .................................................................................... 12


3.4.1 Packets (8 Bits) ............................................................................................ 12

Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 1
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.5 Clear ............................................................................................................... 12


3.6 Distress Alert................................................................................................... 12
3.6.1 Position (40 bits) .......................................................................................... 12
3.6.2 Protocol (2 bits) ............................................................................................ 12
3.6.3 Nature of Distress for Maritime Terminals (4 bits) ........................................ 13
3.6.4 Course (9 bits) ............................................................................................. 13
3.6.5 Speed (6 bits)............................................................................................... 13
3.6.6 Security / Covert Alert (1 Bit)........................................................................ 13
3.6.7 U1 - Position Update (1 Bit) ......................................................................... 13
3.6.8 U2 - Course / Speed Update (1 Bit) ............................................................. 13
3.7 Distress Alert Test ........................................................................................... 13
3.8 Login Request ................................................................................................. 13
3.8.1 Class (8 Bits)................................................................................................ 13
3.8.1.1 Options (5 Bits) .................................................................................................................... 14

3.8.1.2 Spare (1 Bit) ......................................................................................................................... 14

3.8.1.3 MES Class (2 Bits) ............................................................................................................... 14

3.8.2 Version Number (8 Bits) ............................................................................... 14


3.9 Logout Request ............................................................................................... 14
3.10 Message Status Request .............................................................................. 14
3.11 MES Forced Clear ........................................................................................ 14
3.11.1 Reason for Clear (8 Bits)............................................................................ 14
3.12 Test Request................................................................................................. 14
3.13 Test Result Acknowledgement ...................................................................... 14
3.14 Transfer Status Request ............................................................................... 15
3.14.1 Stage (8 Bits) ............................................................................................. 15

4 Common Field Descriptions ................................................... 15


4.1 LES ID (8 Bits) ................................................................................................ 15
4.2 Logical Channel Number (8 Bits) .................................................................... 15
4.3 Message Reference Number (24 Bits) ............................................................ 15
4.4 MES ID (24 Bits) ............................................................................................. 15

Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 2
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 1: Signalling Channel Packet Formats, Sheet 1 of 5 .................................. 16


Figure 1: Signalling Channel Packet Formats, Sheet 2 of 5 .................................. 17
Figure 1: Signalling Channel Packet Formats, Sheet 3 of 5 .................................. 18
Figure 1: Signalling Channel Packet Formats, Sheet 4 of 5 .................................. 19
Figure 1: Signalling Channel Packet Formats, Sheet 5 of 5 .................................. 20

Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 3
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

1 General Structure
The following structure is shared by all signalling channel packets.

1.1 Signalling Channel Packet


[Signalling Channel] ::= [Signalling Packet Descriptor]
[Type Dependent Fields]
[Checksum] [Fill]

1.1.1 Signalling Packet Descriptor


[Signalling Packet Descriptor] ::= [Priority] [Continuation]
[Type]

1.1.1.1 Priority (1 bit)

0B Normal priority
1B Distress priority

All packet types have normal priority except for the Assignment Request and Distress Alert packets
which may also have distress priority.

1.1.1.2 Continuation (1 bit)

0B Last packet in sequence


1B Another packet to follow

It should be noted that if the bit is set, then the [Checksum] field will always be at bytes 14 and 15.

1.1.1.3 Type (6 Bits)

The type field identifies the function of the associated packet. The list of assigned codes and
associated packet types is given in Section 2.

1.1.2 Type Dependent Fields


The content of the body of the packet is dependent on the [type] field. Descriptions of these fields for
each packet type is given in Section 3.

1.1.3 Checksum (16 Bits)


A Checksum is calculated as defined in Fig 1-1. The position of the [checksum] field depends on the
[type] and [continuation] fields. If the [continuation] field indicates that another packet is to follow, the
[checksum] field is at the end of the packet. If the packet is the last of the sequence and the amount of
information in the packet can be deduced from the [type] field, then the [checksum] field immediately
follows the information. Otherwise the [checksum] field is at the end of the packet.

1.1.4 Fill
A burst of 120 bits is always sent in a slot on the signalling channel. If the information of the packet
does not require the 120 bits, the bits after the checksum are set to zero. These fill bits are not taken
into account when the checksum is calculated.

Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 4
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

2 Packet Types
The type field for each packet is as follows:

Code Packet Destination

00H Acknowledgement LES


01H Announcement Response LES
02H Assignment Response LES
03H Clear LES
04H Data Report NCS & LES
05H Distress Alert NCS & LES
06H Distress Alert Test LES
07H MES Forced Clear NCS & LES
08H*** Data Report for Mobile to Mobile LES (see Chapter 13)
0AH Login Request NCS
0BH Logout Request NCS
0CH Message Status Request NCS & LES
0DH Test Request NCS
0EH Test Result Acknowledgement LES
0FH Transfer Status Request NCS & LES
10H-1FH Assignment Request NCS & LES
24H Enhanced Data Report LES
2FH Enhanced Data Report Status Request LES

3 Specific Packet Formats


Specific type dependent fields are described here and illustrated in Figure 1. The [Signalling Packet
Descriptor] and [Checksum] fields are present in every packet and are not shown in the following
definitions.

3.1 Acknowledgement
[Acknowledgement] ::= [Logical Channel Number]
[Errored Packet No]11

3.1.1 Errored Packet No. (8 Bits)


This gives the packet sequence number of any packet received in error by the mobile earth station. A
single acknowledgement may indicate up to 11 such errored packets. If less than 11 errored packets
are reported in an acknowledgement, the remaining fields shall be set to all zeros. If more than 11
packets have been received in error by the MES, it is not permitted to use continuation packets to
convey additional acknowledgements, instead additional complete acknowledgement cycles are
required.

3.2 Announcement Response

Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 5
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

[Announcement Response] ::= [MES ID]

3.3 Assignment Request

3.3.1 Protocol
The least significant four bits of the [Type] field for assignment request packets indicate the required
protocol as follows:

0H Store-and-Forward (message)
1H Prefixed Store-and-Forward (message)
2H Half-duplex Data
3H Reserved for circuit switched data (bit-transparent - no ARQ)
4H Reserved for circuit switched data (with ARQ)
5H-CH Spare
DH Reserved
EH Message-Performance Verification
FH Extension - further details to be supplied in [Service Dependent Descriptor] field.

3.3.2 Packet Body


The assignment request packet will always have the checksum in bytes 14 and 15, with any spare
bytes set to zero.

[Assignment Request] ::= [MES ID] [LES ID]


[Service Dependent Descriptor]
[Destination Descriptor]

3.3.2.1 Service Dependent Descriptor

The [Service Dependent Descriptor] field contains sub-fields relevant to the service as given in the
[Type] field as follows:

(a) Performance Verification Test

[Service Dependent Descriptor] ::= [Message Length]

- Message Length (8 Bits)

For PVT, this is set to the number of packets required to send the same message as received
during the To-Mobile stage.

(b) Store-and-Forward (message) and Prefixed Store-and-Forward (message)

[Service Dependent Descriptor] ::= [Message Length]

- Message Length (8 Bits)

An unsigned binary number giving the number of message packets to be transferred (up to
255).

3.3.2.2 Destination Descriptor

[Destination Descriptor] ::= [Destination Network] [Extension Length]


[Address Location]
[Destination Extension] [Address]

Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 6
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.3.2.2.1 Destination Network (3 Bits)

This field defines the type of destination address and is coded:

0H Telex
1H Public Switched Telephone Network (PSTN)
2H Circuit Switched Data Network (CSDN)
3H Packet Switched Data Network (PSDN)
4H X.400 Address
5H Closed Network
6H Special Access Code
7H Other - further information in the [Destination Extension] field

For the mandatory Store and Forward Telex service, and for PVT, this field is set to the value 0
(Telex).

3.3.2.2.2. Extension Length (2 Bits)

The length of the [Destination Extension] field given as an unsigned binary number.

Extension Length
Destination Network Comment
Value
Telex 0 [Destination Extension] is zero bytes long
PSTN 3 [Destination Extension] is three bytes long
PSDN 0 [Destination Extension] is zero bytes long
X.400 1 [Destination Extension] is one byte long
Closed Network 0 [Destination Extension] is zero bytes long
Special Access Code 0 [Destination Extension] is zero bytes long

For PVT, this field is set to the value 0 (Telex).

3.3.2.2.3. Address Location (3 Bits)

This field encodes the location of the addressing information.

The following tables show the use of these address location codes for the currently defined protocols
(see Section 3.3.1).

a) Address Location values for the store and forward (message) protocol

Destination Address
Comment
Network Location Value
The telex destination code, for the first address line, is in the
[Address] field of the Assignment Request packet and full
Telex 4H
international address line(s) for each of the destinations in the
message text.
The Country Code of the first address is placed in the [Address]
field of the Assignment Request packet and full international
PSTN 3H
addresses in the Additional Information field of the first message
packet.

Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 7
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

The DNIC1 of the first address is placed in the [Address] field of


the Assignment Request packet and full international addresses
PSDN 3H
for each of the destinations in the Additional Information field of the
first message packet.
The [Address] field in the Assignment Request packet is not used.
X.400 2H
All addressing is contained in the message text.
The Closed Network ID is contained in the [Address] field of the
Closed
0H Assignment Request packet and the Additional Information field of
Network
the first message packet is empty.
The Special Access Code is contained in the [Address] field of the
Special
0H Assignment Request packet and the Additional Information field of
Access Code
the first message packet is empty.

b) Address Location values for the Prefixed store and forward (message) protocol

Destination Address
Comment
Network Location Value
The two digit prefix (CCITT F.126), followed by the telex
destination code, if any, for the first address, is in the [Address]
field of the Assignment Request packet and the two digit prefix
Telex 3H
followed by the full international address for each of the
destinations is in the Additional Information field of the first
message packet.
The two digit prefix (CCITT E.216), followed by the Country Code,
if any, of the first address is placed in the [Address] field of the
PSTN 3H Assignment Request packet and the two digit prefix followed by
the full international address for each of the destinations is in the
Additional Information field of the first message packet.
The two digit prefix (CCITT X.350)3 , followed by the DNIC, if any,
of the first address is placed in the [Address] field of the
PSDN 3H Assignment Request packet and the two digit prefix followed by
the full international address for each of the destinations is in the
Additional Information field of the first message packet.
The [Address] field in the Assignment Request packet is not used.
X.400 2H
All addressing is contained in the message text.
The Closed Network ID is contained in the [Address] field of the
Closed
0H Assignment Request packet and the Additional Information field of
Network
the first message packet is empty.
Special
0H Same as normal Store and Forward.
Access Code

c) Address Location values for Message Performance Verification

Destination Address
Comment
Network Location Value
Telex 0H The [Address] field is empty

These codes are summarised in the table below, which shows where the addressing information is to
be found.

Address Location Code In Assignment Request In Additional Information In Message Text


0H YES - -
1H - YES -

1 The Data Network Identification Code.


3 For data calls through a public data network, a single digit (0) prefix is used.

Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 8
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

2H - - YES
3H YES YES -
4H YES - YES
5H - YES YES

0H full addressing is in the assignment request packet;

1H full addressing is in the [Additional Information] field of the message channel packet(s);

2H full addressing is in the message itself;

3H addressing information is both in the assignment packet and in the [Additional


Information] field of the first message packet;

4H addressing information is both in this assignment packet and in the message text
itself;and

5H addressing information is both in the [Additional Information] field and in the message
text of the message channel packets.

3.3.2.2.4 Destination Extension (0 to 24 Bits)

Certain services may require information in addition to that given in the [Destination Type] field (for
example, for circuit switched services, the data rate and modem type may be required). The
[Destination Extension] field provides up to three additional bytes of information related to the
destination type.

Destination Network Destination Extension Contents

Telex [Destination Extension] is zero bytes long


This field indicates the type of equipment the originator wishes to be
attached to the PSTN (e.g. a V.22 modem). Byte contents are:

Byte 1 - the CCITT series identifier coded in IA5 with odd parity
(e.g. "V")

PSTN Byte 2 - the relevant recommendation number coded in Binary


Coded Decimal (e.g. 22)

Byte 3 - additional character, if required, coded in IA5 with odd


parity - current valid characters are: "B" for bis; and "T" for
ter. If not used this byte shall set to the hexadecimal value
00H
PSDN [Destination Extension] is zero bytes long
The value for [Presentation] contained in the first message packet is
X.400
repeated in this field
Closed Network [Destination Extension] is zero bytes long

Special Access Code [Destination Extension] is zero bytes long

3.3.2.2.5. Address

This field contains any address information required in the assignment request for the type of service.
It is protocol and destination type dependent as given in the following tables:

Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 9
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

a) Address field contents and length for the store and forward (message) protocol

Destination Length
Address Field Contents
Network (Bits)
For the mandatory store-and-forward telex message service, full
international address lines are at the beginning of the message text
and conform to CCITT Rec. U.80 (See Table 4). The Address field in
the Assignment Request shall contain the telex destination code of
Telex 24 the first address, which is repeated in the message text (Annex A of
CCITT Recommendation F.69 (Red Book)). The code will be encoded
using IA5, International Reference version of CCITT Red Book
Recommendation T.50 with odd parity. Two digit F.69 codes will
follow a leading zero making the field always three bytes in length.

The CCITT E.163 Country Code of the first address shall be placed in
the [Address] field. It shall be encoded in Binary Coded Decimal. The
PSTN 12
field shall always be three BCD digits long, with shorter codes
following a leading zero(s).

The CCITT X.121 DNIC of the first address shall be placed in the
[Address] field. It shall be encoded in Binary Coded Decimal. The field
PSDN 16
shall always be four BCD digits long, with shorter codes following a
leading zero(s).
The [Address] field is not used for X.400 messages and is zero bytes
X.400 0
long.

Closed Where the destination is given as a closed network, the Address field
16
Network will contain a DNID that has been registered with an LES operator.

The characters of this code will be encoded using IA5. Codes with
less than 6 characters will be padded on the right with IA5 null
Special
<=48 characters, i.e. all zero bytes. If the Special Access Code sent is two
Access Code
digits, then this shall be interpreted to be a two Digit Prefix code as
defined in CCITT Recommendation F.126.

b) Address field contents and length for the Prefixed store and forward (message) protocol

Destination Length
Address Field Contents
Network (Bits)
The field contains the CCITT F.126 prefix and, if any further
Telex 40 international addressing is required, is followed by the F.69 code of
the first address. The field is coded in IA5.
The field contains the CCITT E.216 two digit prefix and, if any further
PSTN 20 international addressing is required, is followed by the CCITT E.163
Country Code. The field is coded in BCD.
The field contains the CCITT X.350 two digit prefix and is followed by
PSDN 24 the CCITT X.121 DNIC of the first address, if any further international
addressing is required. The field is coded in BCD.
The [Address] field is not used for X.400 messages and is zero bytes
X.400 0
long.
Closed
16 As for Store and Forward (message) Closed Network.
Network
As for Store and Forward (message) Special Access Code. Includes
Special
<= 48 use for access codes longer than 6-digits, and for access codes
Access Code
requiring that the destination network type be specified.

Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 10
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

The address field contents are formatted as follows for all destination networks requiring a prefix
followed by a country code / DNIC:

{pp000}/{pp00c}/{pp0cc}/{ppccc}

for five digit fields requiring country codes, where pp are the prefix digits and c is a country code digit
(leading digits 0 if less than a three digit code), and

{pp0000}/{pp0ddd}/{ppdddd}

for DNICs, where pp are the X.350 two digit prefix digits and d is a X.121 DNIC digit (leading digits 0
if less than a four digit code).

c) Address Field Contents and Length for Message Performance Verification

Destination Length
Address Field Contents
Network (Bits)
Telex 0 The [Address] field is empty

3.3.2.3 Examples

The table below presents some examples of the complete [Destination Descriptor] field for various
types of Destination Network. The examples are:

a) Telex A telex to the Republic of Vanuatu.


b) PSTN PSTN connection via a V22bis modem to a UK address.
c) FAX PSTN connection for a Facsimile transmission.
d) PSDN X.25 connection to DataNet 1 in Holland.
e) Closed Network Access to the pre-registered CNID 4321H.
f) Special Access Access to the private service defined by the Special
Access code CA5798.
g) Special Access Access to the F.126 Medical Advice service.
h) Mobile-mobile message
i) Mobile-mobile data
j) X.400 A message submitted to the X.400 MHS.

Example Protocol Destinatio Extension Address Destination Address


n Network Length Location Extension
a) Telex 0 0 4 (empty) 771
b) PSTN 1 3 3 V22B 044
c) FAX 1 3 3 T30N4 001
d) PSDN 3 0 3 (empty) 2041
e) Closed Network 5 0 0 (empty) 4321
f) Special Access 6 0 0 (empty) CA5798
g) Special Access 6 0 0 (empty) 32
h) Mobile - Mobile message 0 0 4 (empty) 58S5
i) Mobile - Mobile data 3 0 3 (empty) 111S5
j) X.400 4 1 2 [presentation] (empty)

4 N in this example stands for the null code 00H.


5 S is the Inmarsat-C Ocean Region

Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 11
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.4 Assignment Response


[Assignment Response] ::= [MES ID]
[Logical Channel Number]
[Packets]

3.4.1 Packets (8 Bits)


An unsigned binary number giving the number of packets that the forward message will be broken
into. It is echoed to the land earth station to validate correct reception of logical channel assignment
information.

3.5 Clear
[Clear] ::= [MES ID] [LES ID] [Logical Channel Number]

3.6 Distress Alert


[Distress Alert] ::= [MES ID] [LES ID] [Position] [Protocol]
[Nature of Distress] [Course] [Speed]
[Security/covert alert][Position Update]
[Course/Speed Update]

3.6.1 Position (40 bits)


This is divided into sub-fields as follows:

- latitude degrees (7 bits)


- latitude minutes (6 bits)
- N/S hemisphere flag (0=N, 1=S) (1 bit)
- longitude degrees (8 bits)
- longitude minutes (6 bits)
- E/W hemisphere flag (0=E, 1=W) (1 bit)
- hour of last update (UTC) (5 bits) -derived from NCS bulletin board frame number
- minute of last update (6 bits)

3.6.2 Protocol (2 bits)


Coded as:

0 Maritime
1 Land mobile
2-3 Reserved

Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 12
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.6.3 Nature of Distress for Maritime Terminals (4 bits)


Coded as:

0H undesignated (default setting)


1H fire/explosion
2H flooding
3H collision
4H grounding
5H listing
6H sinking
7H disabled and adrift
8H abandoning ship
9H further assistance required
AH piracy/armed attack
BH-FH Spare

3.6.4 Course (9 bits)


An unsigned binary number representing degrees from true north. Set to all 1s if the course is not
known.

3.6.5 Speed (6 bits)


An unsigned binary number representing speed in knots. Set to all 0s if the speed is not known.

3.6.6 Security / Covert Alert (1 Bit)


set to 1 if security/covert alert

3.6.7 U1 - Position Update (1 Bit)


Set to 1 if the position field (bytes 6 to 10 inclusive) has not been updated within the last 24 hours.

3.6.8 U2 - Course / Speed Update (1 Bit)


Set to 1 if the course and/or speed fields have not been updated within the last 60 minutes.

3.7 Distress Alert Test


This packet contains the same fields as the Distress Alert Packet.

3.8 Login Request


[Login Request;] ::= [MES ID] [Class] [Version Number]

3.8.1 Class (8 Bits)


[Class] ::= [Options][Spare][MES Class]

Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 13
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.8.1.1 Options (5 Bits)

This field indicates optional capabilities supported by an MES. It is bit oriented field, with a value one
indicating option is supported by the MES.

B8 ITA2 transmission supported


B7 Data transmission supported
B6 Basic X.400 supported
B5 Enhanced X.400 (MTA Unregistered Services) supported
B4 Lower Power C MES

3.8.1.2 Spare (1 Bit)

This field is reserved for future use, presently unused and set to zero.

3.8.1.3 MES Class (2 Bits)

This field indicates the class of the MES as defined in Volume 3, Part 2. It is coded as follows:

00 B Class 0
01 B Class 1
10 B Class 2
11 B Class 3

3.8.2 Version Number (8 Bits)


The version number of the network configuration currently stored in the MES. A value of zero
indicates that the MES has no valid configuration.

3.9 Logout Request


[Logout Request] ::= [MES ID]

3.10 Message Status Request


[Message Status Request] ::= [MES ID] [LES ID]
[Message Reference Number]

3.11 MES Forced Clear


[MES Forced Clear] ::= [MES ID] [LES ID]
[Logical Channel Number]
[Reason for Clear]

3.11.1 Reason for Clear (8 Bits)


See Chapter 3, Section 3.4.1 for coding of this field.

3.12 Test Request


[Test Request] ::= [MES ID]

3.13 Test Result Acknowledgement


[Test Result Acknowledgement] ::= [MES ID]

Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 14
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

3.14 Transfer Status Request


[Transfer Status Request] ::= [MES ID]
[Logical Channel Number]
[Stage]

3.14.1 Stage (8 Bits)


This number references the transfer stage that the mobile earth station had reached before a timeout
had occurred. The coding of the states is as follows:

01H waiting for Acknowledgement


02H waiting for Message
03H Spare
04H waiting for Clear
05H waiting for Distress Test request (LCN 0)
06H waiting for Test Results (LCN 0)
07H Spare

4 Common Field Descriptions


The following describes fields which are used by more than one packet.

4.1 LES ID (8 Bits)


A number uniquely identifying a particular land earth station.

4.2 Logical Channel Number (8 Bits)


A number assigned by the land earth station for a logical channel established with a particular mobile
earth station for the duration of a message transfer. It uniquely identifies a particular message transfer
while the transfer process is active. Valid logical channel numbers are in the range 1 through 255.
Logical channel number 0 is used for force clearing any attempted call setup which is not fully
established.

4.3 Message Reference Number (24 Bits)


A number given by a land earth station for referencing a particular message transfer which is not
active on a logical channel.

4.4 MES ID (24 Bits)


The number allocated by INMARSAT for use in the return direction, uniquely identifying a particular
mobile earth station.

Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 15
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 1: Signalling Channel Packet Formats, Sheet 1 of 5

Figure 1: Signalling Channel


Packet Formats, Sheet 1 of 5

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

P C Type 1 P C Type 1
Logical Channel No. 2 2
Errored Packet No. 3 MES ID 3
Errored Packet No. 4 4
Errored Packet No. 5 5
Checksum
Errored Packet No. 6 6
Errored Packet No. 7 7
Byt Byt
Errored Packet No. 8 8e
e
Errored Packet No. 9 9
Errored Packet No. 10 10
FILL
Errored Packet No. 11 11
Errored Packet No. 12 12
Errored Packet No. 13 13
14 14
Checksum
15 15

Acknowledgement Announcement Response

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

P C Type 1 P C Type 1
2 2
MES ID 3 MES ID 3
4 4
LES ID 5 LES ID 5
Service Depen't Descriptor 6 Message Length 6
7 7
Byt Destination Descriptor
8 Byt
e 8
e
9 9
Destination
Descriptors 10 10
11 FILL 11
12 12
13 13
14 14
Checksum Checksum
15 15

Assignment Request Assignment Request


for the PVT protocol

Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 16
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 1: Signalling Channel Packet Formats, Sheet 2 of 5

Figure 1: Signalling Channel


Packet Formats, Sheet 2 of 5

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

P C Type 1 P C Type 1
2 2
MES ID 3 3
MES ID
4 4
Logical Channel No. 5 LES ID 5
Packets 6 Logical Channel No. 6
7 7
Checksum Byt Checksum Byt
8e 8
e
9 9
10 10
11 FILL 11
FILL
12 12
13 13
14 14
15 15

Assignment Response Clear

Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 17
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 1: Signalling Channel Packet Formats, Sheet 3 of 5

Figure 1: Signalling Channel


Packet Formats, Sheet 3 of 5

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

P C Type 1 P C Type 1
2 2
MES ID 3 MES ID 3
4 4
LES ID 5 LES ID 5
6 6
7 7
Position Position
8 8
Byte Byte
9 9
10 10
P Nature 11 P Nature 11
Course 12 Course 12
Speed SA PU CU 13 Speed SA PU CU 13
14 14
Checksum Checksum
15 15

Distress Alert Distress Alert Test

Bit No.
8 7 6 5 4 3 2 1

P C Type 1
2
MES ID 3
4
Class 5
Version Number 6
7
Checksum
8
Byte
9
10
FILL 11
12
13
14
15

Login Request

Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 18
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 1: Signalling Channel Packet Formats, Sheet 4 of 5

Figure 1: Signalling Channel


Packet Formats, Sheet 4 of 5

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

P C Type 1 P C Type 1
2 2
MES ID 3 MES ID 3
4 4
5 LES ID 5
Checksum
6 6
Message Reference
7 7
Number Byt
Byt
8 8e
e
9 9
Checksum
10 10
FILL
11 11
12 12
13 FILL 13
14 14
15 15

Logout Request Message Status Request

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

P C Type 1 P C Type 1
2 2
MES ID MES ID
3 3
4 4
LES ID 5 5
Checksum
Logical Channel No 6 6
Reason 7 7
Byt Byt
8e 8
Checksum e
9 9
10 FILL 10
11 11
FILL
12 12
13 13
14 14
15 15

MES Forced Clear Test Request

Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 19
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 1: Signalling Channel Packet Formats, Sheet 5 of 5

Figure 1: Signalling Channel


Packet Formats, Sheet 5 of 5

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

P C Type 1 P C Type 1
2 2
MES ID 3 MES ID 3
4 4
5 Logical Channel No. 5
Checksum
6 Stage 6
7 7
Byt Checksum Byt
8e 8
e
9 9
10 10
FILL
11 FILL 11
12 12
13 13
14 14
15 15

Test Result Acknowledgement Transfer Status Request

Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 20
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 5: Message Channel Packet Formats

Contents

1 General Structure .................................................................... 2

2 Packet Types ........................................................................... 2

3 Specific Packet Formats .......................................................... 2


3.1 Message Packet ...............................................................................................2
3.1.1 Packet Number (8 bits) ..................................................................................2
3.1.2 Message Header ............................................................................................2
3.1.2.1 Delivery Class (1 bit) .............................................................................................................. 2

3.1.2.2 Confirmation Request (1 bit) .................................................................................................. 2

3.1.2.4 Logical Channel Number (8 Bits) ........................................................................................... 3

3.1.2.5 Presentation (8 bits) ............................................................................................................... 3

3.1.2.6 Last Count (8 Bits) ................................................................................................................. 3

3.1.2.7 Additional Information (Up to 472 Bits) .................................................................................. 3

3.1.3 Data ...............................................................................................................5


3.1.4 Checksum (16 bits) ........................................................................................5
Figure 1: Message Channel Packet Formats ..........................................................6
Figure 2: Example for From-Mobile Message Transfer ...........................................7

Volume 4: Packet Formats and Usage, Page: 1


Chapter 5: Message Channel Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 General Structure
All packets on the message channel are 127 byte fixed size packets. The first byte contains the
sequential packet number beginning at 1. The last two bytes of the packet contain the checksum
which uses the algorithm given in Figure 1.

2 Packet Types
The first packet of a message sent on the message channel contains an extra field with additional
control information. The remainder of the packets of a message are sent without this field. Figure 1
illustrates the packet contents.

3 Specific Packet Formats

3.1 Message Packet


An example of a one packet message is given in Figure 2.

[Message Channel Packet] ::= [Packet Number] [Message Header]


[Data]
[Checksum] or
[Packet Number] [Data] [Checksum]

3.1.1 Packet Number (8 bits)


This field contains an unsigned binary integer giving the number of the packet within the message.
The first packet contains 1 and the value is incremented by 1 for each following packet.

3.1.2 Message Header


This field is sent in the first packet of a message only and contains further details of the message. For
the mandatory store-and forward service this field contains the following subfields:

[Message Header] ::= [Delivery Class] [Confirmation]


[Length] [Logical Channel Number]
[Presentation] [Last Count] [Additional Information]

3.1.2.1 Delivery Class (1 bit)

Coded as:

0 Immediate delivery

1 Deferred delivery

3.1.2.2 Confirmation Request (1 bit)

Coded as:

0 No delivery confirmation required

1 Delivery confirmation required

Volume 4: Packet Formats and Usage, Page: 2


Chapter 5: Message Channel Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.1.2.3 Length (6 bits)

This is an unsigned number giving the length in bytes of the [Message Header] field (first packet only).
For the mandatory Store and Forward Telex service this length is 4 bytes, since the additional
information field is empty for this service.

3.1.2.4 Logical Channel Number (8 Bits)

A number assigned by the participating land earth station for a logical channel established with the
mobile earth station for the duration of a message.

3.1.2.5 Presentation (8 bits)

This field indicates the manner in which the data field has been formatted for presentation. The coding
of this field is defined in Chapter 3, Section 4.13. The only valid codes for the mandatory Store and
Forward Telex service are ITA2 and IA5.

For messages to be delivered to a PSDN, this field shall be set to the DATA code; that is, no pre-
defined alphabet to be assumed by earth stations.

3.1.2.6 Last Count (8 Bits)

An unsigned binary number giving the number of whole characters or bytes in the last packet of the
message. If the presentation code defines an alphabet, then this field indicates the number of whole
characters, otherwise it is the number of bytes.

3.1.2.7 Additional Information (Up to 472 Bits)

This is additional information (answerback, validation codes etc) to be used by the land earth station
in establishing the terrestrial link. This field is empty for the mandatory store and forward telex service.

Protocol Destination Network Additional Information Field Contents

Store and
Forward Telex This field is empty, i.e. zero bits in length.
(message)
This field is used to specify the destination international
number(s). Each number, consisting of the country code
followed by the national number, in a fixed length 15 digit
field. Each digit is coded in Binary Coded Decimal (BCD)
and packed two digits to a byte. Addresses less than 15
digits are padded to the right (left justified) with the fill
PSTN digit hexadecimal F. Up to 7 addresses may be included,
but the length of the [Additional Information] field shall be
set as to just contain the required addresses, e.g. for one
address, eight bytes are required, therefore [Additional
Information] is eight bytes in length, and [Length] is equal
to 12. Any unused "digits" at the end of the last address
shall contain hexadecimal F.
The field contains one or more X.25 destination
addresses; a maximum of eight addresses. Each
address may consist of up to 14 digits. Addresses that
are fewer than 14 digits are padded to the right using fill
PSDN digits. The addresses are coded in Binary Coded
Decimal (BCD) and packed two digits to a byte. The fill
digit should be set to hexadecimal F. The length of the
additional Information field should be exactly the length
required to hold the set of addresses.

Volume 4: Packet Formats and Usage, Page: 3


Chapter 5: Message Channel Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

X.400 This field is empty, i.e. zero bits in length.


Closed Network This field is empty, i.e. zero bits in length.
Special Access Code This field is empty, i.e. zero bits in length.

Protocol Destination Network Additional Information Field Contents

This field contains one or more Telex addresses


encoded in IA5 with odd parity and formatted as follows:

1) each address shall be prefixed with a CCITT F.126


two digit prefix code. (For normal telex addressing
this prefix is "00".)

2) the prefix shall be followed by any internationally


significant digits required. (For normal telex
addressing the internationally significant digits are
the F.69 telex destination code.)

Prefixed 3) the internationally significant digits shall be


Store and followed by any further addressing required. (For
Telex normal telex addressing, this would be the
Forward
(message) destination subscriber's telex number. The
answerback may be added after a "/" character.
For example: 0051888152/888152 C AOR G/,
where prefix="00"; telex destination code="51"
(UK); subscriber address="888152";
answerback="888152 C AOR G".

4) each address shall be terminated by either the


carriage return character or carriage return
followed by the line feed character. If there is only
one address, this address terminator is optional.

5) additional subfields shall be delimited by a "/"


character.
The same formatting convention as defined for Telex
shall be used in PSTN addressing. The two digit prefix
codes are contained in E.216. It should be noted that the
PSTN
Country Code for the first address which is in the
assignment request packet, must also be included as
part of the address in this field.
The same formatting convention as defined for Telex
shall be used in PSDN addressing. The two digit prefix
codes are contained in CCITT X.350. It should be noted
PSDN
that the DNIC for the first address which is in the
assignment request packet, must also be included as
part of the address in this field
X.400 This field is empty, i.e. zero bits in length.
Closed Network This field is empty, i.e. zero bits in length.
Special Access Code Reserved for future use.

Volume 4: Packet Formats and Usage, Page: 4


Chapter 5: Message Channel Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Message-
Performance Telex This field is empty, i.e. zero bits in length.
Verification

3.1.3 Data
This is the message data. Unused bytes are filled with 00H.

For non 8-bit codes, bit 1 of the first character will be stored in bit 1 of the first byte. Bytes in the [Data]
field are sequentially filled from bit 1 to bit 8 wrapping around to bit 1.

For the mandatory Store and Forward Telex service, the address input should be at the head of this
field and should conform to CCITT Rec. U.80, paragraph 4.7 with the following exceptions:

i) when using the IA5 alphabet, the EOA signal defined in paragraph 4.7.4 should be replaced
with the IA5 'STX' character; and

ii) paragraph 4.7.3 is not applicable.

3.1.4 Checksum (16 bits)


This is a checksum of the fields from the packet number to the data inclusive.

Volume 4: Packet Formats and Usage, Page: 5


Chapter 5: Message Channel Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: Message Channel Packet Formats

FIG. 1 Message Channel


Packet Formats

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
Packet No. 1 Packet No. 1
Byt 2
C R Length 2
e
Logical Channel Number 3 3
Byt
Presentation Control 4 e
Last Count 5
6
Additional
Information 7
8
Data

Data

Checksum Checksum
127 127

First Packet of Message Format for Remaining


Packets in Message

Volume 4: Packet Formats and Usage, Page: 6


Chapter 5: Message Channel Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 2: Example for From-Mobile Message Transfer

FIG. 2 Example for From-Mobile


Message Transfer
Bit No.
8 7 6 5 4 3 2 1

1
1
0 0 4
2
Logical Channel Number
Presentation Control 3 Byte
0
(IA5)
21 4
'7'
'7'
'8'
'4'
Address '6'
Line '2'
'5'
'0'
'0'
'0'
'+'
Start of Text 'STX'

'C'
'O'
'M'
Message 'E'
Input ''
'H'
'O'
'M'
'E'

Not used
(set to zero)

Checksum
127

Message Packet

Volume 4: Packet Formats and Usage, Page: 7


Chapter 5: Message Channel Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 6: Interstation Packet Formats

Contents

1 General Structure .................................................................... 5

2 Packet Types ........................................................................... 5

3 Specific Packet Formats .......................................................... 6


3.1 Area Poll Status ................................................................................................6
3.2 Block Update End .............................................................................................6
3.2.1 Last Sequence Number (8 Bits) .....................................................................6
3.2.2 Latest Time ....................................................................................................6
3.3 Block Update Start ............................................................................................6
3.3.1 Update Request Time ....................................................................................6
3.4 Cancel Announcement ......................................................................................6
3.5 Commission Request ........................................................................................6
3.5.1 Class (8 Bits)..................................................................................................7
3.6 EGC Acknowledgement ....................................................................................7
3.6.1 Message Sequence Number (16 Bits) ...........................................................7
3.6.2 Receive Status (1 Bit) ....................................................................................7
3.6.3 Spare (7 Bits) .................................................................................................7
3.7 Group Poll Status ..............................................................................................7
3.8 Network Record ................................................................................................7
3.8.1 Call Commencement (32 Bits) .......................................................................7
3.8.2 Call Volume (16 Bits) .....................................................................................7
3.8.2.1 Frame Length ......................................................................................................................... 7

3.8.2.2 Packets (8 Bits) ...................................................................................................................... 8

3.8.2.3 Packet Size (8 Bits) ................................................................................................................ 8

3.8.3 Delivery Status (1 Bit) ....................................................................................8


3.8.5 Satellite Frequency Code (16 Bits) ................................................................8
3.8.6 Service (4 Bits) ...............................................................................................8

Volume 4: Packet Formats and Usage, Page: 1


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.8.7 Spare (9 Bits) .................................................................................................8


3.8.8 Time Complete (32 Bits) ................................................................................8
3.9 Registration .......................................................................................................8
3.9.1 Spare 1 (4 3 Bits) ...........................................................................................8
3.9.2 I (1 bit) ............................................................................................................8
3.9.3 Spare 2 (8 Bits) ..............................................................................................9
3.10 MES Status .....................................................................................................9
3.10.1 Call Status (4 Bits) .......................................................................................9
3.11 MES Status Request .......................................................................................9
3.12 MES Status Request + Announcement...........................................................9
3.12.1 Priority (8 Bits) .............................................................................................9
3.12.1.1 Network Priority (4 Bits) ....................................................................................................... 9

3.12.1.2 Service Grade (4 Bits) ........................................................................................................ 10

3.12.2 To-Mobile Assignment ............................................................................... 10


3.12.2.1 To-Mobile S&F Message Assignment................................................................................ 10

3.12.2.1.1 Packets (8 Bits) ............................................................................................................... 10

3.12.2.1.2 Last Count (8 Bits) .......................................................................................................... 10

3.12.2.2 Performance Verification Assignment ................................................................................ 10

3.12.3 Spare (2 Bits) ............................................................................................. 10


3.13 Signalling Packet Envelope ........................................................................... 10
3.14 System Message .......................................................................................... 11
3.14.1 Text (Maximum 256 Bytes) ........................................................................ 11
3.15 TDM Release ................................................................................................ 11
3.16 TDM Release Acknowledgement .................................................................. 11
3.17 TDM Release Request .................................................................................. 11
3.18 TDM Request ................................................................................................ 11
3.18.1 Permanent (1 Bit) ....................................................................................... 11
3.18.2 Request Priority (1 Bit) ............................................................................... 11
3.18.3 Number Return Channels (6 Bits) .............................................................. 12
3.18.4 Spare (2 Bits) ............................................................................................. 12
3.19 TDM Request Response ............................................................................... 12

Volume 4: Packet Formats and Usage, Page: 2


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.19.1 Hold Time (16 Bits) .................................................................................... 12


3.19.2 Return Channel (16 Bits)............................................................................ 12
3.19.3 TDM Status (2 Bits) .................................................................................... 12
3.20 Update Request ............................................................................................ 12
3.20.1 Last Update Time ....................................................................................... 12
3.21 Enhanced Registration .................................................................................. 13
3.21.1 Spare 1 (4 Bits) .......................................................................................... 13
3.21.2 Current NCS / LES ..................................................................................... 13
3.21.3 MES Network Version No .......................................................................... 13
3.21.4 Registration Data Units .............................................................................. 13
3.21.4.1 Registration Data Type [Rtype] (3 bits) .............................................................................. 13

3.21.4.2 Registration Data Length [Rlength] (5 bits) ........................................................................ 13

3.21.4.3 Registration Data Type Depending Fields ......................................................................... 13

3.21.4.3.1 AA_Code (32 Bits) .......................................................................................................... 14

3.21.4.3.2 ISP_Code (16 Bits) ........................................................................................................ 14

3.22 Registration Update Request .......................................................................... 14


3.22.1 Query type (8 Bits) ........................................................................................ 14

4 Common Field Descriptions ................................................... 14


4.1 Announcement Reference (8 Bits) .................................................................. 14
4.2 LES ID (8 BITS) .............................................................................................. 14
4.3 LES TDM (16 BITS) ........................................................................................ 15
4.4 Data Network ID (16 BITS) ............................................................................. 15
4.5 Current NCS (8 BITS) ..................................................................................... 15
4.6 Date-Time Format ........................................................................................... 15
4.6.1 Day of Year (9 Bits) ...................................................................................... 15
4.6.2 Hours (5 Bits) ............................................................................................... 15
4.6.3 Minutes (6 Bits) ............................................................................................ 15
4.6.4 Second (6 Bits) ............................................................................................ 15
4.6.5 Spare (6 Bit) ................................................................................................. 15
4.7 Direction (2 Bits) ............................................................................................. 15

Volume 4: Packet Formats and Usage, Page: 3


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.8 Forward MES ID (24 Bits) ............................................................................... 15


4.9 Return MES ID (24 Bits).................................................................................. 16
4.10 NCS ID(8 Bits) .............................................................................................. 16
4.11 Request Number (6 Bits)............................................................................... 16
4.12 Sequence Number (8 Bits) ............................................................................ 16
4.13 Service (4 Bits) .............................................................................................. 16
4.14 MES Status (4 Bits) ....................................................................................... 16
4.15 Spot ID (8 Bits).............................................................................................. 16
4.16 Sub-Address (8 Bits) ..................................................................................... 16
4.17 TDM (16 Bits) ................................................................................................ 16
4.18 Answerback (32 Bits) .................................................................................... 17
4.19 Class (8 Bits)................................................................................................. 17
4.20 Inmarsat Mobile Number (32 Bits) ................................................................ 17
4.21 Update Time ................................................................................................. 17
Figure 1: Interstation Packet Body Formats, Sheet 1 of 8 ..................................... 18
Figure 1: Interstation Packet Body Formats, Sheet 2 of 8 ..................................... 19
Figure 1: Interstation Packet Body Formats, Sheet 3 of 8 ..................................... 20
Figure 1: Interstation Packet Body Formats, Sheet 4 of 8 ..................................... 21
Figure 1: Interstation Packet Body Formats, Sheet 5 of 8 ..................................... 22
Figure 1: Interstation Packet Body Formats, Sheet 6 of 8 ..................................... 23
Figure 1: Interstation Packet Body Formats, Sheet 7 of 8 ..................................... 24
Figure 1: Interstation Packet Body Formats, Sheet 8 of 8 ..................................... 25

Volume 4: Packet Formats and Usage, Page: 4


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 General Structure
This chapter describes the Inmarsat-C packets which are conveyed on the Interstation Signalling
Links (ISLs) between the NCS and the LESs in a particular region. Volume 3, Part 4 of the System
Definition Manual defines the lower level protocols for the ISLs. A limit of 300 bytes is imposed on any
packet sent across the ISL.

The packet formats conform to the general structure which is described in Chapter 1 of this volume.
As many of the packets conveyed on the ISL are the same as those transmitted on the TDM
channels, the details of those packets are not repeated in this chapter. The chapter references given
in the table in Section 2 which follows, indicate where the appropriate details may be found.

2 Packet Types
The [Type] field for each packet on the ISL is as follows:

Cod
Signalling Packet Origin Reference
e
04H Signalling Packet Envelope LES or NCS Vol. 4, Chap. 6
08H Area Poll Status NCS Vol. 4, Chap. 6
09H Group Poll Status NCS Vol. 4, Chap. 6
0AH Block Update Start NCS Vol. 4, Chap. 6
0BH Block Update End NCS Vol. 4, Chap. 6
0CH Commission Request NCS Vol. 4, Chap. 6
11H Distress Alert Acknowledgement NCS & LES Vol. 4, Chap. 3
19H LES Forced Clear LES Vol. 4, Chap. 3
1FH Enhanced Registration NCS Vol. 4, Chap. 6
21H Area Poll LES Vol. 4, Chap. 9
22H Group Poll LES Vol. 4, Chap. 9
23H Individual Poll LES Vol. 4, Chap. 9
24H Network Record LES Vol. 4, Chap. 6
25H Registration NCS Vol. 4, Chap. 6
26H Update Request LES Vol. 4, Chap. 6
27H System Message NCS & LES Vol. 4, Chap. 6
28H Confirmation LES Vol. 4, Chap. 3
29H Message Status LES Vol. 4, Chap. 3
2CH Request Status LES Vol. 4, Chap. 3
2DH Test Result LES Vol. 4, Chap. 3
2FH Registration Update Request LES Vol. 4, Chap. 6
30H EGC Packet (Single Header) LES Vol. 4, Chap. 3
31H EGC Packet (First of Double Header) LES Vol. 4, Chap. 3
32H EGC Packet (Second of Double Header) LES Vol. 4, Chap. 3
33H EGC Acknowledgement NCS Vol. 4, Chap. 6
34H MES Status NCS & LES Vol. 4, Chap. 6
35H MES Status Request NCS & LES Vol. 4, Chap. 6
36H MES Status Request + Announcement LES Vol. 4, Chap. 6

Volume 4: Packet Formats and Usage, Page: 5


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

37H Cancel Announcement LES Vol. 4, Chap. 6


38H TDM Release Acknowledgement NCS Vol. 4, Chap. 6
39H TDM Release LES Vol. 4, Chap. 6
3AH TDM Release Request NCS Vol. 4, Chap. 6
3BH TDM Request LES Vol. 4, Chap. 6
3CH TDM Request Response NCS Vol. 4, Chap. 6

Note: EGC packets (codes 30,31,32,33H) are constrained to use the medium format.

3 Specific Packet Formats


Only ISL signalling packets which appear only on the Interstation Signalling Links are described here
and are illustrated in Figure 1. Any field used by more than one packet is described in Section 4 of this
chapter.

3.1 Area Poll Status


[Area Poll Status] ::= [Data Network ID]

3.2 Block Update End


[Block Update End] ::= [NCS ID] [Last Sequence Number] [Latest Time]

3.2.1 Last Sequence Number (8 Bits)


The sequence number of the last registration packet sent by the NCS before the Block Update End
packet.

[Last Sequence Number] ::= [Sequence Number]

3.2.2 Latest Time


The time stored at the NCS being the last time the NCS Database was updated.

[Latest Time] ::= [Date-Time Format]

3.3 Block Update Start


[Block Update Start] ::= [NCS ID] [Update Request Time]

3.3.1 Update Request Time


A repeat of the contents of the [Last Update Time] contained in the Update Request packet sent by
the LES.

[Update Request Time] ::= [Date-Time Format]

3.4 Cancel Announcement


[Cancel Announcement] ::= [Announcement Reference]

3.5 Commission Request


[Commission Request] ::= [Forward MES ID] [Return MES ID]

Volume 4: Packet Formats and Usage, Page: 6


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

[Class] [Spot ID]

3.5.1 Class (8 Bits)


This field indicates the class of the MES as defined in Volume 3, Part 2. The coding is given in
Chapter 4, Section 3.8.1.

3.6 EGC Acknowledgement


[EGC Acknowledgement] ::= [Message Sequence Number] [Receive Status]
[Spare]

3.6.1 Message Sequence Number (16 Bits)


The message sequence number given to the particular EGC message by the LES.

3.6.2 Receive Status (1 Bit)


Indicates to the LES if the NCS received the whole EGC message, which may be multi-packet,
successfully.

1B EGC message received successfully by NCS

0B Error in reception of EGC message at NCS.

3.6.3 Spare (7 Bits)


Unused and set to zero.

3.7 Group Poll Status


[Group Poll Status] ::= [Data Network ID]

3.8 Network Record


[Network Record] ::= [LES ID]
[Call Commencement]
[Satellite Frequency Code]
[Repeated Packets] [Service] [Direction]
[Delivery Status] [Spare] [Call Volume]
[Time Complete]

3.8.1 Call Commencement (32 Bits)


[Call Commencement] ::= [Date-Time Format]

3.8.2 Call Volume (16 Bits)


For From-Mobile, this field is split as follows:

[Call Volume] ::= [Packets] [Frame Length]

For To-Mobile:

[Call Volume] ::= [Packets] [Packet Size]

3.8.2.1 Frame Length

Volume 4: Packet Formats and Usage, Page: 7


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Copy of the [Frame Length] field of the logical channel assignment packet sent to the MES by the
LES.

3.8.2.2 Packets (8 Bits)

An unsigned binary number representing the number of packets given in the assignment request
packet.

3.8.2.3 Packet Size (8 Bits)

An unsigned binary number representing the packet size in bytes.

3.8.3 Delivery Status (1 Bit)


A Boolean indicating whether or not a message has been completely delivered. It is coded as follows:

0B Failed

1B Completely delivered

3.8.4 Repeated Packets (8 Bits)

The count of the number of repeated packets in a message transfer.

3.8.5 Satellite Frequency Code (16 Bits)


An unsigned binary number giving the specific 5kHz channel. The same coding is used whether the
mobile earth station expects to transmit on the signalling channel or on the message channel.

3.8.6 Service (4 Bits)


The [Service] field of the LES TDM Assignment packet or the lower 4 bits of the [Type] field of the
MES Assignment Request as appropriate.

3.8.7 Spare (9 Bits)


Set to zero.

3.8.8 Time Complete (32 Bits)


[Time Complete] ::= [Date-Time Format]

3.9 Registration
[Registration] ::= [Forward MES ID] [Return MES ID]
[INMARSAT Mobile Number] [Answerback]
[Spare 1] [I] [MES Status] [Current NCS]
[SpotID]
[Class] [Spare 2]
[Sequence Number] [Update Time]

3.9.1 Spare 1 (4 3 Bits)


Unused and set to zero.

3.9.2 I (1 bit)

Volume 4: Packet Formats and Usage, Page: 8


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

This is a one bit flag defined as follows:

0B AA (Global activation and registration)

1B SP (Local activation and registration)

3.9.3 Spare 2 (8 Bits)


Unused and set to zero.

3.10 MES Status


[MES Status] ::= [Forward MES ID]
[Current NCS]
[MES Status] [Call Status]

3.10.1 Call Status (4 Bits)


This field is coded as follows:

0H No call

1H Announcing

2H Announcement in Queue

3H No TDM Assignment - request for announcement rejected

3.11 MES Status Request


[MES Status Request] ::= [Forward MES ID]

3.12 MES Status Request + Announcement


[MES Status Request + Announcement] ::= [Forward MES ID]
[Announcement Reference]
[Service] [Direction] [Spare]
[Priority]
[LES TDM]
or
[Forward MES ID]
[Announcement Reference]
[Service] [Direction] [Spare]
[Priority]
[LES TDM]
[To-Mobile Assignment]

3.12.1 Priority (8 Bits)


This field represents the service grade required and the absolute priority of the request (at present
only distress and normal).

[Priority] ::= [Network Priority] [Service Grade]

3.12.1.1 Network Priority (4 Bits)

0H Normal priority traffic

Volume 4: Packet Formats and Usage, Page: 9


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1H-EH Reserved for future use

FH Distress priority message

3.12.1.2 Service Grade (4 Bits)

This is an unsigned binary number whose representation is dependent on the [Service] field.
For store and forward telex the following coding applies:

0H Message to be transferred within five minutes

1H Message to be transferred within thirty minutes.

2H Message to be transferred within twelve hours.

3H-FH Reserved for future use.

3.12.2 To-Mobile Assignment


This field is only present when the [Direction] field indicates that a ground to mobile message
transfer is being announced.

[To-Mobile Assignment] ::= [To-Mobile S&F Message Assignment] or


[Performance Verification Assignment]

3.12.2.1 To-Mobile S&F Message Assignment

[To-Mobile S&F Message Assignment] ::= [Logical Channel Number]


[Message Reference Number]
[Sub-address] [Presentation]
[Packets] [Last Count]

3.12.2.1.1 Packets (8 Bits)

An unsigned binary number giving the number of packets to be transferred on the land earth station's
TDM.

3.12.2.1.2 Last Count (8 Bits)

An unsigned binary number giving the number of characters or bytes in the last packet of the
message. If the presentation code defines an alphabet, then this field is the number of characters,
otherwise it is the number of bytes.

3.12.2.2 Performance Verification Assignment

[Performance Verification Assignment] ::= [To-Mobile S&F Message Assignment]

3.12.3 Spare (2 Bits)


Unused and set to zero.

3.13 Signalling Packet Envelope


This packet is used to convey certain received Signalling packets from the NCS to the LES and in one
instance from the LES to the NCS. These are:

From NCS to LES: Assignment Request

Volume 4: Packet Formats and Usage, Page: 10


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Data Report
Distress Alert
Message Status Request
MES Forced Clear
Test Request

From LES to NCS: Distress Alert

The Signalling packet first has its Checksum removed and is then placed as the [Type Dependent
Fields] field of the Signalling Packet Envelope. A new Checksum is calculated for this Envelope.

Continuation packets are first combined into a single packet before insertion into the Signalling packet
envelope, according to the following rules:

1) All checksums from the original packets are removed.

2) Only the packet descriptor from the first (or only) packet is retained, all others are removed.

3.14 System Message


[System Message] ::= [Text]

3.14.1 Text (Maximum 256 Bytes)


A variable length field of text using IA5 (IRV), with odd parity. The message will be made available to
the receiving ground-based station's controller. May be used for communications between LESs and
their associated NCS.

3.15 TDM Release


[TDM Release] ::= [LES TDM] [Spot ID]

3.16 TDM Release Acknowledgement


[TDM Release Acknowledgement] ::= [LES TDM] [Spot ID]

3.17 TDM Release Request


[TDM Release Request] ::= [LES TDM] [Spot ID]

3.18 TDM Request


[TDM Request] ::= [Request Number] [Permanent]
[Request Priority]
[Spot ID]
[Number Return Channels] [Spare]

3.18.1 Permanent (1 Bit)


Indicates whether or not this is a request for a permanent TDM (i.e. one without time limit).

0B Request Permanent LES TDM

1B Request Demand Assigned LES TDM

3.18.2 Request Priority (1 Bit)

Volume 4: Packet Formats and Usage, Page: 11


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Indicates whether or not LES has distress traffic to process immediately.

0B Normal Priority

1B Distress Priority

3.18.3 Number Return Channels (6 Bits)


An unsigned binary number indicating the number of return channels (signalling or message
channels) the LES is requesting to be allocated with the TDM. The current range of this parameter is
0 to 40 decimal.

3.18.4 Spare (2 Bits)


Unused and set to zero.

3.19 TDM Request Response


[TDM Assignment] ::= [LES TDM]
[Request Number] [TDM Status]
or
[LES TDM]
[Request Number] [TDM Status]
[Hold Time]
[Return Channel]n

3.19.1 Hold Time (16 Bits)


Field present if LES has been assigned a TDM. An unsigned binary number giving the preferred
maximum hold time for the TDM in minutes. A value of zero indicates no maximum.

3.19.2 Return Channel (16 Bits)


Field present if LES has been assigned a TDM. A satellite frequency code defining a return channel
which may be used with the assigned LES TDM. The return channel can be used for either a
message or signalling channel. This field is repeated for the number of return channels assigned by
the NCS.

3.19.3 TDM Status (2 Bits)


This field indicates the status of the TDM assignment coded as follows:

0H TDM assignment rejected

1H TDM assignment successful

2H TDM assignment pending (placed in queue)

3H Reserved

3.20 Update Request


[Update Request] ::= [NCS ID] [Last Update TIme]

3.20.1 Last Update Time

Volume 4: Packet Formats and Usage, Page: 12


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The time contained in the last Registration packet to be received which caused an update to the MES
database at the LES.

[Last Update Time] ::= [Date-Time Format]

3.21 Enhanced Registration


[Enhanced Registration] ::= [Forward MES ID]
[Spare 1] [MES Status]
[Current NCS / LES] [SpotID]
[Class] [MES Network Version No]
[Sequence Number] [Update Time]
[Registration Data Unit]n

where n is the number of Registration Data Units, and may be a variable number, depending upon the
amount of registration data to be distributed during commissioning.

3.21.1 Spare 1 (4 Bits)


Unused, value unspecified.

3.21.2 Current NCS / LES


The NCS or LES via which the MES last performed a login process.

3.21.3 MES Network Version No


The network version number reported by the MES when it last performed a login process.

3.21.4 Registration Data Units


The Registration Data Units have the format:

[Registration Data Unit] ::= [Registration Data Type (1..7)]


[RDU Length (0..31)]
[Registration Data Type Dependent Fields]

3.21.4.1 Registration Data Type [Rtype] (3 bits)

This field is used to specify the information which is being transferred to the LES within the
[Registration Type Dependent Fields]. The field has valid values in the range (0..7).

The Registration Data Type field is encoded as follows:

0H Reserved

1H Accounting Authority Commissioning Information

2H Inmarsat Service Provider Commissiong Information

3H..7H Reserved

3.21.4.2 Registration Data Length [Rlength] (5 bits)

This field (when present) is used to specify the length of the [Registration Type Dependent Fields] in
bytes. The field has values in the range (0..31).

3.21.4.3 Registration Data Type Depending Fields

Volume 4: Packet Formats and Usage, Page: 13


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

These fields are defined according to Registration Data Types as shown below:-
i) Registration Data Type Code 1H Accounting Authority Commissioning Information
[Return MES ID][Inmarsat Mobile Number][Answerback][AA_Code] or

ii) Registration Data Type Code 2H Inmarsat Service Provider Commissioning Information
[Return MES ID][Inmarsat Mobile Number][Answerback][ISP_code]

3.21.4.3.1 AA_Code (32 Bits)

The AA_Code is unique reference to an authorised Accounting Authority published by ITU. AA_Code
is a mandatory data item for MES service activation/authorisation under ITU's D.90 framework.
Format: XXXX where XXXX is a valid alpha numeric string.

3.21.4.3.2 ISP_Code (16 Bits)

The ISP_Code is unique reference to an authorised Inmarsat Service Provider. The ISP_Code is
assigned at the ECS whenever a LESO informs the appointment of new Inmarsat Service Provider.
ISP_Code is mandatory in the case of MES service activation/authorisation under SP framework and
viewed as an equivalent of AA_Code under D.90 framework.

Format: SNNN where S equals to 9 or 8 only and


NNN is any value between 000 to 999

3.22 Registration Update Request


[Registration Update Request] ::= [Query type]
[Inmarsat Mobile Number] or [Forward/Return MES ID]

3.22.1 Query type (8 Bits)


This field specifies whether the registration update request is based on Inmarsat Mobile Number or
the MES return ID for the MES.

0H Reserved

1H Inmarsat Mobile Number of the MES is used for the registration update request

2H MES return ID is used

3H MES forward ID is used

4-7H Reserved

4 Common Field Descriptions


The following describes fields which are used by more than one packet.

4.1 Announcement Reference (8 Bits)


A number chosen by the LES in a strictly ascending sequence (modulo 256) to allow the LES to make
subsequent reference to the Announcement.

4.2 LES ID (8 BITS)


A number uniquely identifying a particular land earth station, see Volume 3, Part 1, Chapter 3.

Volume 4: Packet Formats and Usage, Page: 14


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.3 LES TDM (16 BITS)


A satellite frequency code assigned to an LES for use in the forward direction as a TDM.

This field is coded as follows:

0-16FFH Illegal

1700-36B0H A forward satellite frequency code.

4.4 Data Network ID (16 BITS)


Gives the network identity to be used when responding to a poll request.

4.5 Current NCS (8 BITS)


If the MES is logged into a region, this field will contain the NCS identity for the region. If the MES is
not logged into any region, then this field will be set to zero.

4.6 Date-Time Format


[Date-Time Format] ::= [Day of year] [Hours] [Minutes]
[Seconds]

4.6.1 Day of Year (9 Bits)


An unsigned binary number representing the Julian day.

4.6.2 Hours (5 Bits)


An unsigned binary number representing the hour (0 - 23)

4.6.3 Minutes (6 Bits)


An unsigned binary number representing the minute (0 - 59)

4.6.4 Second (6 Bits)


An unsigned binary number representing the second (0 - 59)

4.6.5 Spare (6 Bit)

4.7 Direction (2 Bits)


Provides the direction of the message transfer. Coded as:

0H To-Mobile

1H From-Mobile

2H Spare

3H Both directions

4.8 Forward MES ID (24 Bits)


The number allocated by INMARSAT for use by the MES in the forward direction.

Volume 4: Packet Formats and Usage, Page: 15


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.9 Return MES ID (24 Bits)


The number allocated by INMARSAT for use by the MES in the return direction.

4.10 NCS ID(8 Bits)


The unique identity as given by the Inmarsat-C numbering plan of the NCS connected to the LES, see
Volume 3, Part 1, Chapter 3.

4.11 Request Number (6 Bits)


An unsigned binary number. Each separate request from an LES for a TDM is given a sequential
number to allow the LES and NCS to differentiate between requests. An LES repeating a TDM
request will use the same request number.

4.12 Sequence Number (8 Bits)


The registration packets sent by the NCS will contain sequential numbers modulo 256. When a Block
Update is initiated, the sequence number is reset to 1.

4.13 Service (4 Bits)


This field describes the type of service being requested. The coding is given in Chapter 3, Section
4.17.

4.14 MES Status (4 Bits)


This field is coded as follows:

0H Not Commissioned

1H Barred

2H Not in OR

3H Idle

4H Busy

5H Decommissioned

4.15 Spot ID (8 Bits)


An unsigned binary number uniquely identifying a spot beam within a region. The global beam will
have Spot ID = 0.

4.16 Sub-Address (8 Bits)


Used to provide on-board device selection. The main DTE is designated 00H.

4.17 TDM (16 Bits)


The frequency channel to be used by the land earth station for the transmission of its TDM. It is coded
as a Satellite Frequency Code.

Volume 4: Packet Formats and Usage, Page: 16


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.18 Answerback (32 Bits)


The four character answerback assigned to this MES. Coded as IA5 characters, odd parity.

4.19 Class (8 Bits)


This field indicates the class of the mobile earth station as defined in Volume 3, Part 2. The coding is
given in Chapter 4, Section 3.8.1.

4.20 Inmarsat Mobile Number (32 Bits)


The INMARSAT Mobile Number for the MES encoded in binary.

4.21 Update Time


The time at which the update was applied to the MES database at the NCS.

[Update Time]:= [Date-Time Format]

Volume 4: Packet Formats and Usage, Page: 17


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: Interstation Packet Body Formats, Sheet 1 of 8

FIG. 6-1 Interstation Packet


Body Formats, Sheet 1 of 8

Bit No.
8 7 6 5 4 3 2 1

Closed Network ID

Area Poll Status

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

NCS ID NCS ID
Last Sequence Number
Update
Request
Latest time time

Block Update End Block Update Start

Volume 4: Packet Formats and Usage, Page: 18


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: Interstation Packet Body Formats, Sheet 2 of 8

FIG. 6-1 Interstation Packet


Body Formats, Sheet 2 of 8

Bit No. Bit No.


8 7 6 5 4 3 2 1
8 7 6 5 4 3 2 1
Announcement Reference
Forward MES ID

Return MES ID

Class
Spot ID

Cancel Announcement Commission Request

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

Closed Network ID Message Sequence No.

RS Spare

Group Poll Status EGC Acknowledgement

Volume 4: Packet Formats and Usage, Page: 19


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: Interstation Packet Body Formats, Sheet 3 of 8

FIG. 6-1 Interstation Packet


Body Formats, Sheet 3 of 8

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

Forward Forward MES ID


MES ID

Current NCS
MES Status Call Status Return MES ID

MES Status INMARSAT Mobile


Number
Bit No.
8 7 6 5 4 3 2 1

LES ID
Answerback

Call
Commencement
Spare 1 I MES Status
Current NCS
Satellite Frequency Spot ID
Code Class
Repeated packets Spare 2
Service Dir D Sequence number
Spare

Call Volume
Update time

Time Complete
Registration

Network Record

Volume 4: Packet Formats and Usage, Page: 20


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: Interstation Packet Body Formats, Sheet 4 of 8

FIG. 6-1 Interstation Packet


Body Formats, Sheet 4 of 8

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

MES ID Forward MES ID

Announcement Reference
Service D Spare
Priority

LES TDM

MES Status Request MES Status Request


+ Announce ment

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

Forward MES ID

Signalling
Announcement Reference
Packet
Service D Spare
Priority

LES TDM

Logical Channel No
Message
Reference
Number
Sub-address
Presentation
Packets
Last Count

MES Status Request Signalling Packet


+ Announce ment Envelope
(To-Mobile S&F or
Performance Verification)

Volume 4: Packet Formats and Usage, Page: 21


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: Interstation Packet Body Formats, Sheet 5 of 8

FIG. 6-1 Interstation Packet


Body Formats, Sheet 5 of 8

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

LES TDM

Spot ID
Text

Syste m Message TDM Release

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

LES TDM LES TDM

Spot ID Spot ID

TDM Release Acknowledge ment TDM Release Request

Volume 4: Packet Formats and Usage, Page: 22


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: Interstation Packet Body Formats, Sheet 6 of 8

FIG. 6-1 Interstation Packet


Body Formats, Sheet 6 of 8

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
Request number Pe Pr
LES TDM
Spot ID
No. Return Chans. Spare Request no. Status

Hold Time

Return
Channel 1

Return
Channel n

TDM Request TDM Request Response

Bit No.
8 7 6 5 4 3 2 1
NCS ID

Last Update time

Update Request

Volume 4: Packet Formats and Usage, Page: 23


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: Interstation Packet Body Formats, Sheet 7 of 8

FIG. 6-1 Interstation Packet


Body Formats, Sheet 7 of 8

Bit No. Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

MES ID MES ID MES ID

Spare 1 MES Status Spare 1 MES Status Spare 1 MES Status


Current NCS / LES Current NCS / LES Current NCS / LES
Spot ID Spot ID Spot ID
Class Class Class
MES Network Version MES Network Version MES Network Version
Sequence Number Sequence Number Sequence Number

Update Time Update Time Update Time

Rtype=1 RLength=15 Rtype=2 RLength=13

Return MES ID Return MES ID

Inmarsat Inmarsat
Mobile Number Mobile Number

Answerback Answerback

ISP_Code
AA_Code

Enhanced Registration Enhanced Registration Enhanced Registration


(AA_Code) (ISP_Code) (Update)

Volume 4: Packet Formats and Usage, Page: 24


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: Interstation Packet Body Formats, Sheet 8 of 8

FIG. 6-1 Interstation Packet


Body Formats, Sheet 8 of 8

8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

Query Type = 2/3 Query Type = 1

MES Return ID/ Inmarsat Mobile


MES Forward ID Number

Registration Update Request

Volume 4: Packet Formats and Usage, Page: 25


Chapter 6: Interstation Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 7: NCS – NCS Signalling Packet Formats

Contents

1 General Structure .................................................................... 2

2 Data Packet Types ................................................................... 2

3 Specific Formats ..................................................................... 2


3.1 Block Update End .............................................................................................2
3.1.1 Last Sequence Number .................................................................................2
3.1.2 Latest Time ....................................................................................................2
3.2 Block Update Start ............................................................................................2
3.2.1 Update Request Time ....................................................................................2
3.3 MES Status Change .........................................................................................3
3.3.1 Forward MES ID (24 bits)...............................................................................3
3.3.2 MES Status (4 bits) ........................................................................................3
3.3.3 Options (4 Bits) ..............................................................................................3
3.3.4 Update Time (32 bits).....................................................................................3
3.4 Update Request ................................................................................................3
3.4.1 Last Update Time ...........................................................................................3

4 Common Field Descriptions ..................................................... 5


4.1 NCS ID(8 bits) ...................................................................................................5
4.2 Sequence Number (8 bits) ................................................................................5
4.3 Date-Time Format (32 Bits)...............................................................................5
4.3.1 Day of Year (9 Bits) ........................................................................................5
4.3.2 Hours (5 Bits) .................................................................................................5
4.3.3 Minutes (6 Bits) ..............................................................................................5
4.3.4 Second (6 Bits) ..............................................................................................5
4.3.5 Spare (6 Bit) ...................................................................................................5
Figure 1: NCS – NCS Signalling Body Packet Formats ..........................................6

Volume 4: Packet Formats and Usage, Page: 1


Chapter 7: NCS – NCS Signalling Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 General Structure
The packets conform to the general structure given in Chapter 1.

[NCS/NCS Signalling Packet] ::= [Packet Descriptor] [Type Dependent Fields]


[Checksum]

2 Data Packet Types


Specific data packet types are identified by the contents of the [Type] field in the [Packet Descriptor]
as follows:

Code Packet Type


00H MES Status Change
0AH Block Update Start
0BH Block Update End
26H Update Request

3 Specific Formats
The following define the contents of the [Type Dependent Fields] for each of the packets used on the
NCS/NCS Signalling links. Figure 1 illustrates each of these packets.

3.1 Block Update End


As defined in Volume 4, Chapter 6, Section 3.2.

[Block Update End] ::= [NCS ID] [Last Sequence Number] [Latest Time]

3.1.1 Last Sequence Number


The sequence number of the last MES Status Change which is part of the current block update.

[Last Sequence Number] ::= [Sequence Number]

3.1.2 Latest Time


The time stored at the NCS sending the block update of the last update to its database.

[Latest Time] ::= [Date-Time Format]

3.2 Block Update Start


As defined in Volume 4, Chapter 6, Section 3.3.

[Block Update Start] ::= [NCS ID] [Update Request Time]

3.2.1 Update Request Time


A repeat of the contents of the [Last Update Time] contained in the Update Request packet.

[Update Request Time] ::= [Date-Time Format]

Volume 4: Packet Formats and Usage, Page: 2


Chapter 7: NCS – NCS Signalling Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.3 MES Status Change


[MES Status Change] ::= [Originating NCS] [Forward MES ID]
[MES Status] [Spare]
[Sequence Number] [Update Time]

3.3.1 Forward MES ID (24 bits)


A number allocated by INMARSAT for use in the forward direction uniquely identifying a particular
mobile earth station.

3.3.2 MES Status (4 bits)


B4 1 = Caused by mobile action
0 = Caused by NCS or NCC action (e.g. forced logout)

B3 1 = Not Barred
0 = Barred

B2 1 = Logged in
0 = Logged out

B1 1 = Commissioned
0 = Not commissioned

3.3.3 Options (4 Bits)


This field is unsed to indicate the optional capabilities supported by the MES.

B5 1 = ITA2 transmission supported


0 = ITA2 transmission not supported

B6 1 = Data transmission supported


0 = Data transmission not supported

B7 1 = Basic X.400 supported


0 = Basic X.400 not supported

B8 1 = Enhanced X.400 supported


0 = Enhanced X.400 not supported

3.3.4 Update Time (32 bits)


The time at which the update was applied to the sender's MES database.

[Update Time] ::= [Date-Time Format]

3.4 Update Request


[Update Request] ::= [NCS ID] [Last Update TIme]

3.4.1 Last Update Time


The time contained in the last MES Status Change packet to be received from the NCS being asked
for an update which caused an update in the sending NCS's database.

Volume 4: Packet Formats and Usage, Page: 3


Chapter 7: NCS – NCS Signalling Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

[Last Update::= [Date-Time Format]

Volume 4: Packet Formats and Usage, Page: 4


Chapter 7: NCS – NCS Signalling Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4 Common Field Descriptions

4.1 NCS ID(8 bits)


The unique identity as given by the Inmarsat-C numbering plan of the sending NCS (see Volume 3,
Part 1, Chapter 3).

4.2 Sequence Number (8 bits)


An unsigned binary number which is incremented by one for each MES Status Change packet sent.
The sequence will reset to one for the next packet following a count of FFH.

4.3 Date-Time Format (32 Bits)


Provides time and date.

[Date-Time Format] ::= [Day of Year] [Hours] [Minutes]


[Seconds]

4.3.1 Day of Year (9 Bits)


An unsigned binary number representing the day of the year.

4.3.2 Hours (5 Bits)


An unsigned binary number representing the hour (0 - 23).

4.3.3 Minutes (6 Bits)


An unsigned binary number representing the minute (0 - 59).

4.3.4 Second (6 Bits)


An unsigned binary number representing the second (0 - 59).

4.3.5 Spare (6 Bit)


Not used and set to zero.

Volume 4: Packet Formats and Usage, Page: 5


Chapter 7: NCS – NCS Signalling Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: NCS – NCS Signalling Body Packet Formats

FIG. 1 NCS–NCS Signalling


Body Packet Formats.

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

NCS ID NCS ID

MES ID Last Update Time

MES Status Options


Sequence Number

UpdateTime

MES Status Change Update Request

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
NCS ID NCS ID
Last Sequence Number
Update
Request
Latest time time

Block Update End Block Update Start

Volume 4: Packet Formats and Usage, Page: 6


Chapter 7: NCS – NCS Signalling Packet Formats
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 8: Packet Formats for the Data Reporting


Service

Contents

1 Introduction ............................................................................ 2

2 Packet Formats ....................................................................... 2


Figure 1: Data Report Packets ................................................................................2
2.1 Data Report.......................................................................................................2
2.1.1 LES ID (8 Bits) ...............................................................................................2
2.1.2 Data Network ID (16 Bits) ..............................................................................3
2.1.3 Member Number (8 Bits) ................................................................................3

Volume 4: Packet Formats and Usage, Page: 1


Chapter 8: Packet Formats for the Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
The Data Reporting service is intended for transferring small quantities of data from an MES to a pre-
determined terrestrial user. Data is transferred on a signalling channel using unreserved access. The
data may be deposited into a data reporting file at the LES and this file retrieved by the terrestrial user
or forwarded by the LES operator. The service depends on local arrangements between the terrestrial
user and the LES operator.

This chapter describes the packet formats used for Data Reporting. The message protocol used for
this service is described in Volume 1.

2 Packet Formats

Figure 1: Data Report Packets

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

P C Type 1 P C Type 1
2 2
DNID 3 3
LES ID 4 4

Member Number 5 5
6 Data 6
7 7

Byte
Byte

8 8
9 9
Data 10 10
11 11
12 12
13 13
14 14
Checksum Checksum
15 15

First Data Report Continuation Data Report

2.1 Data Report


See Figure 1.

[Data Report] ::= [Data Network ID] [LES ID] [Member Number]
[Data] or
[Data]

For the first packet in a Data Reporting sequence, the Data Network ID, LES ID and Member Number
are included. The remaining packet(s) in the sequence contain only the [Data] field.

2.1.1 LES ID (8 Bits)


A number uniquely identifying a particular land earth station.

Volume 4: Packet Formats and Usage, Page: 2


Chapter 8: Packet Formats for the Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.1.2 Data Network ID (16 Bits)


Gives the closed network address to be used when sending a Data Report.

2.1.3 Member Number (8 Bits)


A number uniquely identifying the MES within the group defined by the Data Network ID and LES ID.

Volume 4: Packet Formats and Usage, Page: 3


Chapter 8: Packet Formats for the Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Chapter 9: Packet Formats for the Polling Service

Contents

1 Introduction ............................................................................ 3

2 Packet Formats ....................................................................... 3


2.1 Individual Poll ....................................................................................................3
Figure 1: Individual Poll Packet ...............................................................................3
2.1.1 Spare (6 Bits) .................................................................................................3
2.2 Group Poll .........................................................................................................4
Figure 2: Group Poll Packet ....................................................................................4
2.2.1 Spare (6 bits) .................................................................................................4
2.3 Area Poll ...........................................................................................................4
Figure 3: Area Poll Packet ......................................................................................5
2.3.1 Area Type (3 Bits) ..........................................................................................5
2.3.2 Area Length (3 Bits) .......................................................................................5
2.3.3 Area ...............................................................................................................5
2.4 Common Field Descriptions ..............................................................................5
2.4.1 LES ID (8 Bits) ...............................................................................................5
2.4.2 LES TDM .......................................................................................................6
2.4.3 Data Network ID (16 Bits) ..............................................................................6
2.4.4 Command (8 bits)...........................................................................................6
2.4.4.1 Ack (1 bit) ............................................................................................................................... 6

2.4.4.1.1 Category (2 Bits) ................................................................................................................. 6

2.4.4.1.2 Sub-Category (6 Bits).......................................................................................................... 6

2.4.4.1.3 Command (8 Bits) ............................................................................................................... 7

2.4.4.1.4 Sequence Number (8 Bits) .................................................................................................. 7

2.4.4.1.5 Spare (16 Bits) .................................................................................................................... 7

2.4.4.2 Command type (7 bits) ........................................................................................................... 7

2.4.4.2.1 Send Report ........................................................................................................................ 7

2.4.4.2.2 Program Reserved Data Reporting..................................................................................... 7

Volume 4: Packet Formats and Usage, Page: 1


Chapter 9: Packet Formats for the Polling Service
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

2.4.4.2.3 Initiate Reserved Data Reporting ........................................................................................ 8

2.4.4.2.4 Stop Reserved Data Reporting ........................................................................................... 8

2.4.4.2.5 Program Unreserved Data Reporting ................................................................................. 8

2.4.4.2.5.1 Start Frame (16 Bits)........................................................................................................ 8

2.4.4.2.5.2 Interval (8 Bits) ................................................................................................................. 8

2.4.4.2.5.3 Free Field (Variable) ........................................................................................................ 8

2.4.4.2.6 Initiate Unreserved Data Reporting..................................................................................... 8

2.4.4.2.7 Stop Unreserved Data Reporting ........................................................................................ 9

2.4.4.2.8 Inmarsat Defined Application Support Commands ............................................................. 9

2.4.4.2.8.1 Define Macro Encoded Message..................................................................................... 9

2.4.4.2.8.1.1 MEM (8 Bits).................................................................................................................. 9

2.4.4.2.8.1.2 MEM Attribute (16 Bits) ................................................................................................. 9

2.4.4.2.8.1.3 MEM Length (8 Bits) ..................................................................................................... 9

2.4.4.2.8.1.4 Message (Variable) ....................................................................................................... 9

2.4.4.2.8.2 Macro Encoded Message ................................................................................................ 9

2.4.4.2.8.2.1 MEM (8 Bits).................................................................................................................. 9

2.4.4.2.8.2.2 Free Field (Variable) ..................................................................................................... 9

2.4.4.2.9 Data Transmission ............................................................................................................ 10

2.4.4.2.10 Download DNID .............................................................................................................. 10

2.4.4.2.10.1 Member Number (8 Bits).............................................................................................. 10

2.4.4.2.10.2 Free Field (Variable) .................................................................................................... 10

2.4.4.2.11 User Defined Commands ................................................................................................ 10

2.4.4.2.12 Delete DNID .................................................................................................................... 10

2.4.5 Sequence Number (8 bits) ........................................................................... 10


2.4.6 Randomizing Interval (8 Bits) ....................................................................... 11
2.4.7 Response (2 bits) ......................................................................................... 11
2.4.8 MES ID (24 Bits) .......................................................................................... 11
2.4.9 Sub-Address (8 Bits) .................................................................................... 11
2.4.10 Text (Variable Length, Byte Aligned) ......................................................... 11

Volume 4: Packet Formats and Usage, Page: 2


Chapter 9: Packet Formats for the Polling Service
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

1 Introduction
The polling protocol allows a terrestrial user to initiate some action by an MES or a group of MES(s).
This action may initiate a transfer of data by the MES to the terrestrial user. Data transfer may be
undertaken using Data Reporting, the Pre-assigned Data Reporting service or normal From-Mobile
message transfer.

Polling requests sent to MESs may contain text or data prepared by the terrestrial user. This allows,
for example, a group call facility with acknowledgement to be implemented.

The message protocol is described in Volume 1; SDL appears in Volume 5.

2 Packet Formats

2.1 Individual Poll


The format of the Individual Poll is defined below and illustrated in Figure 1.
[Individual Poll] ::= [MES ID][LES ID][Sub-address]
[Data Network ID]
[Response][Spare]
[Command][Sequence No]
[Text]

Figure 1: Individual Poll Packet

Bit No.
8 7 6 5 4 3 2 1

MES ID

LES ID
Sub-address

Data Network ID

Resp. Spare
Command
Sequence No.

Text

Individual Poll

2.1.1 Spare (6 Bits)


This field is not currently used and is set to zero.

Volume 4: Packet Formats and Usage, Page: 3


Chapter 9: Packet Formats for the Polling Service
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

2.2 Group Poll


The format of the Group Poll is defined below and illustrated in Figure 2.

[Group Poll] ::= [Data Network ID][LES ID]


[LES TDM][Sub-address]
[Randomizing Interval]
[Response][Spare]
[Command][Sequence No]
[Text]

Figure 2: Group Poll Packet

Bit No.
8 7 6 5 4 3 2 1

Data Network ID

LES ID

LES TDM

Sub-address
Randomising Interval
Resp. Spare
Command
Sequence No.

Text

Group Poll

2.2.1 Spare (6 bits)


This field is not currently used and is set to zero.

2.3 Area Poll


The format of the Area Poll is defined below and illustrated in Figure 3.

[Area Poll] ::= [Data Network ID][LES ID]


[LES TDM][Sub-address]
[Randomizing Interval]
[Response][Area Type][Area Length]
[Area]
[Command][Sequence No]
[Text]

Volume 4: Packet Formats and Usage, Page: 4


Chapter 9: Packet Formats for the Polling Service
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Figure 3: Area Poll Packet

Bit No.
8 7 6 5 4 3 2 1

Data Network ID

LES ID

LES TDM

Sub-address
Randomising Interval
Resp. Type Length

Area

Command
Sequence No.

Text

Area Poll

2.3.1 Area Type (3 Bits)


The same area addressing options available for EGC may be utilized for Area polling. (See Chapter 3,
Section 3.10.1.1.7). Support of the area types is optional. It is recommended that MESs should have
the capability of responding to absolute geographical address types (rectangular and circular areas).
Codes presently allocated are:

0H No address field, all group members polled.

1H NAVAREA address.

3H Rectangular Area.

4H Circular Area.

2.3.2 Area Length (3 Bits)


The length of the [Area] field in bytes.

2.3.3 Area
A variable length field depending on the [Area Type]. The contents conform to the EGC area
addressing definitions given in Chapter 3, Section 3.10.1.1.7.

2.4 Common Field Descriptions

2.4.1 LES ID (8 Bits)


A number uniquely identifying a particular land earth station.

Volume 4: Packet Formats and Usage, Page: 5


Chapter 9: Packet Formats for the Polling Service
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

For LESs serving multiple ocean regions it is permissible for the LES ID indicated in the poll to have a
different 2-bit ocean region identifier than the sending LES.

The NCS shall only accept and forward polls with the source and packet LES IDs consistent. The 2-bit
ocean region identifiers may differ, but must be consistent with ocean regions in which that LES
operates. Refer to Volume 3, Part 1, Chapter 3, Section 7.

2.4.2 LES TDM


This field indicates the satellite channel being used for an LES TDM.

2.4.3 Data Network ID (16 Bits)


Gives the closed network address to be used when responding to a poll. The Data Network IDs in the
range 32768 to 65535 decimal are reserved for future use. DNID 0 is not available for downloading.

2.4.4 Command (8 bits)


This field allows the Poll to be used to invoke a variety of actions/ responses. It is further subdivided
into two sub-fields:

[Command] ::= [Ack][Command Type]

2.4.4.1 Ack (1 bit)

If this bit is set the MES is required to send a pre-defined format Data Report acknowledging the
receipt of the Poll, before taking any further action; that is, before the Poll is passed on by the DCE
for action. If the Poll is either a group or area poll, the randomizing interval given in the Poll shall be
used for the acknowledgement as well as for any subsequent response.

The acknowledgement, which is not necessarily the same as the poll response, may be requested in
a poll to indicate to the poll originator that the poll has been received by the MES. The
acknowledgement is a data report packet having a predefined format as defined in Chapter 8, Section
2. This acknowledgement is always originated by the MES DCE and not the DTE/application.

The poll response may be originated by the DTE/application and may take the form of a data report or
message transfer to the DNID.

The application must be able to differentiate between the ack and the response. The ack should
include the DNID, LES ID, and poll sequence number. Other parameters may be included in the
remainder of the packet, but this is an application matter.

The format for the [Data] field of this acknowledgement Data Report is:

[Data] ::= [Category][Sub-Category]


[Command][Sequence Number]
[Spare]

It is recommended that this bit is set for the Download DNID and Delete DNID commands.

2.4.4.1.1 Category (2 Bits)

Set to 10B to indicate the extended category.

2.4.4.1.2 Sub-Category (6 Bits)

Set to 00H to indicate this data report is a Poll Acknowledge.

Volume 4: Packet Formats and Usage, Page: 6


Chapter 9: Packet Formats for the Polling Service
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

2.4.4.1.3 Command (8 Bits)

Set to the same value as the [Command] field received in the Poll.

2.4.4.1.4 Sequence Number (8 Bits)

Set to the same value as the [Sequence Number] field received in the Poll.

2.4.4.1.5 Spare (16 Bits)

Currently unused and set to zero.

2.4.4.2 Command type (7 bits)

Indicates the action, and format and content of the response expected if any. A number of command
types of general utility are defined here. Further command types are defined for specific services (see
Volume 2).

The basic commands are shown in the following table. The minimum subset of commands that an
LES and an MES should support in order to offer a polling service consists of commands 0AH and
0BH.

Cmd Type Meaning Poll Type

00H Send Unreserved Report as required in [Response] Any


01H Program Reserved Data Reporting Individual
02H Initiate Reserved Data Reporting Any
03H Stop Reserved Data Reporting Any
04H Program Unreserved Data Reporting Any
05H Initiate Unreserved Data Reporting Any
06H Stop Unreserved Data Reporting Any
07H Define Macro Encoded Message * Any
08H Macro Encoded Message * Any
09H Data Transmission Any
0AH Download DNID Individual
0BH Delete DNID Individual / Group
0C-3FH Reserved
40-7FH User defined Any

* These commands are available to support Inmarsat defined Applications. Refer to Section 2.4.4.2.8
below. Other commands may be implemented with codes from the User Defined subset. The user
defined commands should be passed to the DTE for interpretation.

It is permissible for a multi-region LES to send polls to MESs for ocean regions other than the one the
MES is currently operating in, and for which that LES also provides polling and data reporting service.

2.4.4.2.1 Send Report

This is the default command; it is used to request the MES to respond as defined in the [Response]
field. The content of the [Text] field is application specific.

2.4.4.2.2 Program Reserved Data Reporting

Used by the Pre-Assigned Data Reporting protocol, see Volume 1, Chapter 6.

Volume 4: Packet Formats and Usage, Page: 7


Chapter 9: Packet Formats for the Polling Service
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

2.4.4.2.3 Initiate Reserved Data Reporting

Used to initiate Data Reporting using the Pre-Assigned Data Reporting protocol, see Volume 1,
Chapter 7. An MES with programmed pre-assigned data reporting should restart its programming on
receipt of an "initiate" poll if it had previously received a "stop" Pre-Assigned Data Reporting poll.

2.4.4.2.4 Stop Reserved Data Reporting

Used to stop Pre-Assigned Data Reporting. The sub-address in the header indicates which device is
to stop reporting. If the sub-address is 0, all devices are to stop reporting.

2.4.4.2.5 Program Unreserved Data Reporting

Used to program regular reporting by means of the Unreserved Data Reporting protocol. The [Text]
field in the Group Poll is defined as follows:

[Text] ::= [Start Frame][Interval][Free Field]

2.4.4.2.5.1 Start Frame (16 Bits)

An integer encoded as an unsigned binary number with a decimal range of 0 to 9999. This number
defines the absolute frame number for the start of the assignment as referred to the frame number
given in the bulletin board. If the number received is greater than the frame number of the current
bulletin board, the assignment starts in the current day. If the received number is less, then the
assignment starts in the following day. Note that programmed data reporting will not commence until
an initiate command is received.

2.4.4.2.5.2 Interval (8 Bits)

This field defines the interval between data reporting transmissions as a frame count.

[Interval] ::= [x100 Multiplier] [x10 Multiplier] [Interval Units]

[Interval Units] is 6 bit unsigned binary number representing an interval of between 0 and 63 frames.
The two multiplier flags allow the interval to be extended with an accompanying loss in resolution.
Each flag is one bit and when set (i.e. =1), indicates that [Interval Units] should be multiplied by 10,
100 or 1000. For example, the binary value 10001010 would indicate an interval between reports of
1000 frames (approximately 2.4 hours).

For MESs which need to transfer messages or receive EGC transmissions, the minimum interval is
100 frames. This is considered to be an acceptable limit for MESs which support other services for
which time tuned to the NCS Common Channel is a consideration.

In some applications, 100 frames may be an unacceptable restriction: it is essential, however, that
MESs are tuned to the NCS Common Channel for at least some of the time. An MES that attempts to
send Data Reports at too short intervals, typically less than 100 intervals, may not provide an
adequate level of service.

Example: If the start frame number is 9521 and the interval is 100 frames, transmissions may occur in
frames 9521, 9621, 9721, 9821, 9921, 21, 121...

2.4.4.2.5.3 Free Field (Variable)

An optional field, which may convey any user data, binary or text. The length of this field is limited by
the maximum packet length of 300 bytes.

2.4.4.2.6 Initiate Unreserved Data Reporting

Volume 4: Packet Formats and Usage, Page: 8


Chapter 9: Packet Formats for the Polling Service
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Used to start programmed Unreserved Data Reporting.

2.4.4.2.7 Stop Unreserved Data Reporting

Used to stop programmed Unreserved Data Reporting. The sub-address in the header indicates
which device is to stop reporting. If the sub-address is 0, all devices are to stop reporting.

2.4.4.2.8 Inmarsat Defined Application Support Commands

The following field command types 07H - Define Macro Encoded Message and 08H Macro Encoded
Message covered under this sub-section are commands for special applications defined by Inmarsat
(e.g. Position Reporting Service; refer to Volume 2).

2.4.4.2.8.1 Define Macro Encoded Message

This command is used to update the list of Macro Encoded Messages. A Macro Encoded Message
(MEM) is a pre-defined text message represented by a unique 7 bit code. 00H to 3FH are reserved.
The remaining codes are user definable.

Any number of MEMs may be defined in one poll as long as the maximum size of the poll is not
exceeded. Only the MEM codes available for User definition may be defined by this command. The
[Text] field in the Poll is coded as follows:

[Text] ::= [MEM Descriptor]N

N is restricted by the constraint that the maximum length of a Poll packet is 300 bytes.

[MEM Descriptor] ::= [MEM][MEM Attribute][MEM Length][Message]

2.4.4.2.8.1.1 MEM (8 Bits)

The MEM code that is to be associated with the message given in the [Message] field.

2.4.4.2.8.1.2 MEM Attribute (16 Bits)

The MEM attribute code which, together with the MEM code, is to be associated with the message
given in the [Message] field.

2.4.4.2.8.1.3 MEM Length (8 Bits)

An unsigned binary number indicating the number of bytes in the [Message] field.

2.4.4.2.8.1.4 Message (Variable)

Contains the message that is to be represented by the MEM code.

2.4.4.2.8.2 Macro Encoded Message

This command is used when a Macro Encoded Message is sent to an MES or group of MESs. The
[Text] field is coded as follows:

[Text] ::= [MEM][Free Field]

2.4.4.2.8.2.1 MEM (8 Bits)

The MEM code representing the message stored at the MES to be displayed

2.4.4.2.8.2.2 Free Field (Variable)

Volume 4: Packet Formats and Usage, Page: 9


Chapter 9: Packet Formats for the Polling Service
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

An optional field, which may convey any user data, binary or text. The length of this field is limited by
the maximum packet length of 300 bytes.

2.4.4.2.9 Data Transmission

The [Text] field is available for use by the user and is treated as byte oriented binary data.

2.4.4.2.10 Download DNID

Used to download a Data Network ID. The MES stores five basic parameters associated with a Data
Network ID:

i) the DNID is contained in the [Data Network ID] field;

ii) the Sub-address in the [Subaddress] field (depending on the MES configuration; see Volume 1,
Chapter 5);

iii) the LES ID in the [LES ID] field;

iv) the member number contained in the [Text] field; and

v) the first 25 characters of the [Free] field.

[Text] ::= [Member Number][Free Field]

2.4.4.2.10.1 Member Number (8 Bits)

A number uniquely identifying the MES within the group defined by the Data Network ID, LES ID.

2.4.4.2.10.2 Free Field (Variable)

In the case of a DNID download, the free field will contain characters formatted IA5 with odd parity;
the first 25 characters of which will be used to identify the "operator" of the DNID.

2.4.4.2.11 User Defined Commands

The MES DCE shall ignore these commands and they may be passed directly to the sub-
address/DTE/application (depending on the DCE configuration).

2.4.4.2.12 Delete DNID

Used to delete a DNID existing in an MES or group of MESs. The DNID (and sub-address for a
Configuration I DCE) given in the Poll must correspond with one of the MESs entries. For the
limitations on the use of this command, see Volume 3, Part 1, Chapter 2, Section 5.8.4.

2.4.5 Sequence Number (8 bits)


The Sequence Number (0 - FFH) is normally incremented modulo 256. It is used by the MES to detect
duplicate polls, which are to be ignored. It is also used as a reference, when Poll Acknowledgements
are required. The MES should retain a record of all sequence numbers received (for the DNIDs that
are downloaded) for a maximum of 24 hours or until a sequence number is received which is at least
128 greater (modulo 256).

So that a poll may be repeated with the same sequence number, an operator may choose to supply
the sequence number and provide an alternative means for the terrestrial user to request a duplicate
poll, or he may leave it to the terrestrial user to supply the same sequence number. In either case, the
sequence number is allocated on a per DNID basis; that is, independently for each Closed Network.

Volume 4: Packet Formats and Usage, Page: 10


Chapter 9: Packet Formats for the Polling Service
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

2.4.6 Randomizing Interval (8 Bits)


An unsigned binary number giving the number of frames over which the responding mobile earth
station must randomize the timing of its response. It is supplied by the LES.

The Randomizing Interval contained in the poll applies to both the ack, if one is requested, and/or the
response to the poll regardless of whether this takes the form of a data report or message transfer. In
the case of a message transfer the randomization applies to the assignment request only (that is, start
of message transfer).

This Randomizing Interval should not be confused with the Randomization Interval in the LES TDM
bulletin board. The Randomizing Interval in the bulletin board is for the purpose of randomizing re-try
attempts on the signalling channel following a collision and is only used by the signalling channel
control process.

The LES is responsible for managing the randomizing interval therefore needs to know approximately
how big the group is. The LES should not expect all responses to occur within the randomization time
immediately following the poll. It is an operational matter as to how long the LES should wait for
responses following a poll.

It is preferable that the MES should randomize each programmed data report such that the actual
interval between any two successive data reports shall be the programmed interval +/- the
randomizing interval (from the initiate poll). The average interval will tend to converge to the
programmed interval over a large number of reports.

2.4.7 Response (2 bits)


Indicates to the MES what type of response is expected in response to a Poll. It is supplied by the
terrestrial user. The field is coded as follows:

00B No Response

01B Data Report

10B Message Transfer

11B Reserved

2.4.8 MES ID (24 Bits)


A number allocated by Inmarsat for use in the forward direction, uniquely identifying a particular
mobile earth station.

2.4.9 Sub-Address (8 Bits)


This field is used to address different ports attached to the DCE of the mobile earth station. It is
supplied by the terrestrial user. The main DTE is designated 00H.

Sub-address is used for the routing of a poll and can be a physical port on the MES DCE
(configuration I) or a logical/physical address within the DTE (configuration II).

2.4.10 Text (Variable Length, Byte Aligned)


A variable length field containing information specific to a particular data network identity. The format
of the data is application specific. The only exception being for download and delete commands,
where the text should be formatted in IA5 with odd parity.

Volume 4: Packet Formats and Usage, Page: 11


Chapter 9: Packet Formats for the Polling Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 10: Packet Formats for the Pre-Assigned


Data Reporting Service

Contents

1 Introduction ............................................................................ 2

2 Packet Formats ....................................................................... 2


2.1 Slot Logical Channel Assignment .....................................................................2
2.1.1 Duration (8 Bits) .............................................................................................2
2.1.2 Interval (8 Bits) ...............................................................................................3
2.1.3 Logical Channel Number (8 Bits) ...................................................................3
2.1.4 Member Number (8 Bits) ................................................................................3
2.1.5 Packets per Report (2 Bits) ............................................................................3
2.1.6 Slot Number (6 Bits) .......................................................................................3
2.1.7 Start Frame (16 Bits) ......................................................................................4
2.2 Data Report.......................................................................................................4
2.3 GROUP POLL TO INITIALISE DATA REPORTING .........................................4
2.3.1 LES TDM (16 Bits) .........................................................................................4
2.3.2 Randomizing Interval (8 Bits) .........................................................................4
2.3.3 Signalling Channel (16 Bits) ...........................................................................4
2.4 Poll to Clear Slot Logical Channel .....................................................................4
2.4.1 Logical Channel Number (8 Bits) ...................................................................4
Figure 1: Packets Used in Pre-Assigned Data Reporting........................................5

Volume 4: Packet Formats and Usage, Page: 1


Chapter 10: Packet Formats for the Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
The pre-assigned data reporting service is intended for users who need to gather data from MESs on
a regular basis. With the ability to define a constant interval between transmissions from each MES,
pre-assigned TDMA operation of signalling channels can be used instead of the normal Slotted-Aloha
access scheme, thereby allowing more efficient use of the return channel capacity. This is a closed
user group service with the LES operator coordinating user requirements and satellite channel
resources.

An LES offering the Pre-assigned Data Reporting service must synchronise its TDM frame numbers
with UTC.

A user's group of terminals are each pre-programmed, with the necessary parameters. This is
performed remotely using an Individual Poll by the LES operator. A Group poll command is
subsequently used to initiate data reporting.

This chapter describes the packet formats that are used; protocols are described in Volume 1.

2 Packet Formats
The following describes the packet formats to be used in Pre-assigned Data Reporting where they
differ from those used for the basic Data Reporting and Polling service.

2.1 Slot Logical Channel Assignment


Each MES is pre-programmed using an Individual Poll packet (see Chapter 9). This assignment does
two things: it defines a new Closed Network for the MES and provides all the programming
information necessary for Pre-assigned Data Reporting.

[Individual Poll] ::= [MES ID] [LES ID]


[Sub-address][Data Network ID]
[Response][Spare]
[Command][Sequence No.]
[Text]

[Text] ::= [Member Number]


[Slot Logical Channel Assignment]

[Slot Logical Channel Assignment] ::= [Logical Channel Number]


[Start Frame] [Packets per Report]
[Slot Number][Interval] [Duration]

Fields not defined below are used as defined in Chapter 9. The Command type sub-field of the
Command field is set to 01H, and the Response sub-field is set to 00B. It is at the user's discretion
whether an acknowledgement data report is required from the MES.

2.1.1 Duration (8 Bits)


This field defines the duration for which the assignment is valid. It is given as a count of the maximum
number of data reports which may be delivered. Note that if the MES is not able to use every interval
to send a Data Report, it must, nevertheless, terminate data reporting after (Duration-1) * Interval
frames starting from the Start Frame.

[Duration] ::= [x100 Multiplier] [x10 Multiplier] [Unit Count]

[Unit Count] is a six bit unsigned binary number representing an assignment duration of between 0
and 63 reports including the first report. The two multiplier flags allow the duration to be extended with
an accompanying loss in resolution. Each flag is one bit and when set (i.e =1), indicates that [Unit

Volume 4: Packet Formats and Usage, Page: 2


Chapter 10: Packet Formats for the Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Count] should be multiplied by 10, 100 or 1000. For example, the binary value 10001010 would
indicate a duration of 1000 reports.

If [Unit Count] is set to zero, no time limit has been set on the time the assignment is valid. The
multipliers have no significance in this case. Data Reporting can be terminated by the LES sending a
Stop reserved data reporting command or a delete DNID (for the DNID and LES ID to which the
programmed data reports are being sent).

2.1.2 Interval (8 Bits)


This field defines the interval between data reporting transmissions as a frame count.

[Interval] ::= [x100 Multiplier] [x10 Multiplier] [Interval Units]

[Interval Units] is a six bit unsigned binary number representing an interval of between 0 and 63
frames. The two multiplier flags allow the interval to be extended with an accompanying loss in
resolution. Each flag is one bit and when set (i.e. =1), indicates that [Interval Units] should be
multiplied by 10, 100 or 1000. For example, the binary value 10001010 would indicate an interval
between reports of 1000 frames (approximately 2.4 hours).

For MESs which need to transfer messages or receive EGC transmissions, the minimum interval is
100 frames.

Example: If the start frame number is 9521 and the interval is 100 frames, transmissions may occur in
frames 9521, 9621, 9721, 9821, 9921, 21, 121 ...

Unreserved and reserved traffic may be mixed on one signalling channel and signalling channel slots
can be set aside for assignments having the same interval (or multiples).

2.1.3 Logical Channel Number (8 Bits)


In contrast to messaging, the logical channel numbers given for pre-assigned data reporting
assignment do not have to be unique between MESs.

2.1.4 Member Number (8 Bits)


A number uniquely identifying the MES within the group defined by the Data Network ID and LES ID.

2.1.5 Packets per Report (2 Bits)


Encoded as follows:

00B 1 packet per report

01B 2 packets per report

10B 3 packets per report

11B 4 packets per report

2.1.6 Slot Number (6 Bits)


The slot number within the frame being assigned Encoded as an unsigned binary number, the integer
has a decimal range of 1 to 14 for first generation satellite operation and 1 to 28 for second
generation.

Volume 4: Packet Formats and Usage, Page: 3


Chapter 10: Packet Formats for the Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.1.7 Start Frame (16 Bits)


An integer encoded as an unsigned binary number with a decimal range of 0 to 9999. This number
defines the absolute frame number for the start of the assignment as referred to the frame number
given in the bulletin board. If the number received is greater than the frame number of the current
bulletin board, the assignment starts in the current day. If the received number is less, then the
assignment starts in the following day. The LES should attempt to ensure that the desired Start Frame
has not passed, before the MES receives the programming.

2.2 Data Report


The format of the data report is exactly as defined for unreserved Data Reporting in Chapter 8.

2.3 GROUP POLL TO INITIALISE DATA REPORTING


See Chapter 9.

[Group Poll] ::= [Data Network ID] [LES ID]


[LES TDM]
[Sub-address] [Randomizing Interval]
[Response][Spare]
[Command] [Sequence No.] [Text]
[Text] [Signalling Channel]

Fields not defined below are used as defined in Chapter 9. The Command type sub-field of the
[Command] field is set to 02H, and the Response sub-field is set to 01B (Data Report).

2.3.1 LES TDM (16 Bits)


The satellite frequency code of the TDM associated with the signalling channel to be used for Pre-
assigned Data Reporting. If the LES is operating with demand assigned TDMs, this field will be set to
FFFFH (See Chapter 3, Section 4.2.3).

2.3.2 Randomizing Interval (8 Bits)


Used for acknowledgement data reports only (when requested), which are transmitted using
unreserved access.

2.3.3 Signalling Channel (16 Bits)


The satellite frequency code of the signalling channel to be used for Pre-assigned Data Reporting.
(See Chapter 3, Section 4.20.)

2.4 Poll to Clear Slot Logical Channel


Slot Logical Channels may either be cleared on an individual basis using an individual poll or on a
group basis using a group poll. The [Command] field is set to 03H ("Stop Reserved Reporting") and
the MES(s) search for a match on Data Network ID, LES ID and Slot Logical Channel. If a match is
found, Pre-assigned Data Reporting is stopped. However, the Slot Logical Assignment remains
available for re-activation until the Closed Network ID is explicitly removed using a poll with the Delete
DNID command (see Chapter 9), or the program has expired. The [Text] field of the poll stopping Pre-
assigned Data Reporting is defined as follows:

[Text] ::= [Logical Channel Number]

2.4.1 Logical Channel Number (8 Bits)

Volume 4: Packet Formats and Usage, Page: 4


Chapter 10: Packet Formats for the Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The Logical Channel Number given in the Slot Logical Channel Assignment.

Figure 1: Packets Used in Pre-Assigned Data Reporting

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
1 1
Data Network ID
MES ID 2 2
3 LES ID 3
LES ID 4 4
LES TDM
Sub-address 5 5

Byte
6 Sub-address 6
Data Network ID
7 Randomising Interval 7
Byte

Resp Spare 8 Resp Spare 8


Command 9 Command 9
Sequence No. 10 Sequence No.
10
Member Number 11 Signalling 11
Logical Channel Number 12 Channel 12
13
Start Frame
14
Pkts Slot Number 15
Interval 16
Duration 17

Individual Poll Group Poll

Bit No. Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
P C Type 1 P C Type 1 Type 1
P 0
2 2 2
DNID DNID
3 3 Byte
3
LES ID 4 4 LES ID 4
Member Number 5 5 Member Number 5
6 6
7 7
Data
8 8
(1-12 bytes)
Data 9 9
(1-8 bytes) 10 10 Data
(1-44bytes)
11 11
12 12
13 13
14 14
Checksum Checksum
15 15

Data Report Data Report Combined Data Report


First Signalling Continuation packet body on ISL
packet Signalling packet

Volume 4: Packet Formats and Usage, Page: 5


Chapter 10: Packet Formats for the Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 11: Packet Formats for Land Mobile Alerting

Contents

1 Introduction ............................................................................ 2

2 Packet Format ......................................................................... 2


Figure 1: Land Mobile Alert Packet .........................................................................2
2.1 P (1 bit) .............................................................................................................3
2.2 C (1 bit) .............................................................................................................3
2.3 Type (6 bits) ......................................................................................................3
2.4 MES ID (3 bytes) ...............................................................................................3
2.5 LES ID (1 byte) .................................................................................................3
2.6 Land Position (40 bits) ......................................................................................3
2.7 Protocol (2 bits) .................................................................................................3
2.8 User Defined (1 bit) ...........................................................................................3
2.9 Nature of Alert for Land Mobile Terminals (4 bits).............................................4
2.10 A-Automatic Activation (1 bit) ..........................................................................4
2.11 TOP - Time of Position (3 bits) ........................................................................4
2.12 SP - Speed (2 bits) .........................................................................................4
2.13 DOT - Direction of Travel (3 bits) ....................................................................5
2.14 Extra Information (8 bits) .................................................................................5

Volume 4: Packet Formats and Usage, Page: 1


Chapter 11: Packet Formats for Land Mobile Alerting
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
This chapter describes the packet formats used for the optional Land Mobile Alerting function in the
Inmarsat-C system. As it is an optional service, its implementation at an individual Inmarsat-C LES is
at the discretion of that particular LES operator. The end-to-end service arrangements, including the
routing of the alert message at the LES end for appropriate responses, will also naturally vary from
service provider to service provider. This optional service capability is envisaged as a chargeable
service and no parallels are to be drawn between this land mobile alerting function and the maritime
distress alert.

Provision for Land Mobile Alerting is optional for LESs. For LMESs and LPESs, the capability to send
Land Mobile Alerts is also optional (see Volume 3, Part 2, Chapter 6, Section 8).

2 Packet Format
For the Land Mobile Alert packet, the 'priority' bit is set to '0' and not '1' as for Maritime Distress Alerts.
This allows LESs to continue to process maritime distress alerts separately from land mobile alerts.
(For details of the maritime distress alert packet format, see Chapter 4, Section 3.6).

The format for the remainder of the packet is similar to that for the maritime alert, except that the
position field is redefined to allow more accurate position information, and the fields following the
'protocol' field are defined differently to reflect the requirements of land mobile.

Figure 1: Land Mobile Alert Packet

Bit No.

8 7 6 5 4 3 2 1

P C Type 1
2
MES ID 3
4
LES ID 5
6
7
Byte

Land Position 8
9
10
Protcl U Nature A 11
TOP SP DOT 12

Extra Information 13
14
Checksum
15

[Land Mobile Alert] := [MES ID] [LES ID] [Land Position] [Protocol]
[User Defined] [Nature of Alert]
[Automatic Activation] [Time of Position}
[Speed] [Direction of Travel]
[Extra Information]

The packet contents are:

Volume 4: Packet Formats and Usage, Page: 2


Chapter 11: Packet Formats for Land Mobile Alerting
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.1 P (1 bit)
Maritime distress priority bit, which is set to 'zero' for land mobile terminals.

2.2 C (1 bit)
The continuation bit: set to '0', i.e. no continuation packets.

2.3 Type (6 bits)


The type field is set to 05H (Distress alert). For an alert test the type field is set to 06H.

2.4 MES ID (3 bytes)


Identifies MES initiating the alert.

2.5 LES ID (1 byte)


Identifies LES to which the alert is to be transmitted.

2.6 Land Position (40 bits)


Describes the position in degrees, minutes, and fractions of minutes. The field is divided into
subfields as follows:-

- N/S hemisphere flag (0=N, 1=S) (1 bit)

- latitude degrees (7 bits)

- latitude minutes (6 bits)

- latitude, fractions of minutes, units of 0.04 of a minute (5 bits)

- E/W hemisphere flag (0=E, 1=W) (1 bit)

- longitude degrees (8 bits)

- longitude minutes (6 bits)

- longitude, fractions of minutes, units of 0.04 of a minute (5 bits)

- Manual position flag (1 bit), set to 1 if position has been manually entered.

2.7 Protocol (2 bits)


Set to '01' to indicate Land Mobile Alert format.

2.8 User Defined (1 bit)


Defines format of remainder of packet.

0H Format defined as below

1H Format User Defined.

Volume 4: Packet Formats and Usage, Page: 3


Chapter 11: Packet Formats for Land Mobile Alerting
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.9 Nature of Alert for Land Mobile Terminals (4 bits)


The coding below may be used to convey information on the nature of the alert. However, for many
implementations only the default value of 'zero' need to be used. This might be the case if, for
example, alerts are to be initiated by a 'panic button', without resort to a user menu.

0H Unspecified (default)

1H Ambulance

2H Fire

3H Police

4H Hijack

5H Under attack/threat of attack

6H Dangerous cargo leak / spill

7H Accident

8H Vehicle Breakdown

9H Severe Weather

AH-FH Spare

2.10 A-Automatic Activation (1 bit)


Set to 1 only if an alert has been automatically activated (i.e. not by the operator).

2.11 TOP - Time of Position (3 bits)


Coded as follows:

0H < 1 minute old

1H 1 to < 5 minutes old

2H 5 to < 30 minutes old

3H 30 to < 60 minutes old

4H 1 hour or older

5H Not Available

6H Spare

7H Spare

2.12 SP - Speed (2 bits)


Coded as follows:

0H Stopped

Volume 4: Packet Formats and Usage, Page: 4


Chapter 11: Packet Formats for Land Mobile Alerting
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1H Slow < 20 km/h

2H Medium 20 to 70 km/h

3H Fast > 70 km/h

2.13 DOT - Direction of Travel (3 bits)


Coded as follows:

0H N 337.5 to < 22.5 degrees

1H NE 22.5 to < 67.5 degrees

2H E 67.5 to < 112.5 degrees

3H SE 112.5 to < 157.5 degrees

4H S 157.5 to < 202.5 degrees

5H SW 202.5 to < 257.5.5 degrees

6H W 257.5 to < 292.5 degrees

7H NW 292.5 to < 337.5 degrees

2.14 Extra Information (8 bits)


Free field, the contents of which may be defined by user / service provider. For example, might be
used for more Nature of Alert codes, or for coded hazardous chemical identifier, or to indicate
language of user (for subsequent communication).

Volume 4: Packet Formats and Usage, Page: 5


Chapter 11: Packet Formats for Land Mobile Alerting
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Chapter 12: Packet Usage

Contents

1 Introduction ............................................................................ 4

2 Store and Forward Message Protocol ...................................... 4


2.1 Assignment Request .........................................................................................4
2.2 Request Status .................................................................................................5
2.3 Logical Channel Assignment .............................................................................5
2.4 Assignment Response ......................................................................................7
2.5 Announcement ..................................................................................................7
2.6 Announcement Response .................................................................................8
2.7 Message Data ...................................................................................................8
2.8 Message Packet ...............................................................................................9
2.9 Acknowledgement Request ............................................................................ 10
2.10 Acknowledgement ......................................................................................... 10
2.11 Acknowledgement ......................................................................................... 10
2.12 Clear ............................................................................................................. 11
2.13 Network Record ............................................................................................ 11
2.14 LES Forced Clear.......................................................................................... 12
2.15 MES Forced Clear......................................................................................... 12
2.16 Confirmation .................................................................................................. 13
2.17 Message Status Request .............................................................................. 13
2.18 Message Status ............................................................................................ 14
2.19 Transfer Status Request ............................................................................... 14

3 Network Management ............................................................ 15


3.1 Bulletin Board .................................................................................................. 15
3.2 Signalling Channel Descriptor ......................................................................... 17
3.3 Login Request ................................................................................................. 17
3.4 Login Acknowledgement ................................................................................. 18

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 1
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

3.5 Logout Request ............................................................................................... 18


3.6 Logout Acknowledgement ............................................................................... 18
3.7 Network Update .............................................................................................. 19
3.8 Registration ..................................................................................................... 19
3.9 MES Status Change........................................................................................ 20
3.10 Update Request ............................................................................................ 20
3.11 Block Update Start ........................................................................................ 20
3.12 Block Update End ......................................................................................... 21

4 Performance Verification Testing .......................................... 21


4.1 Commission Request ...................................................................................... 21
4.2 Test Request ................................................................................................... 21
4.3 Distress Test Request ..................................................................................... 21
4.4 Distress Alert Test ........................................................................................... 22
4.5 Test Result ...................................................................................................... 22
4.6 Test Result Acknowledgement ........................................................................ 23

5 Alerting ................................................................................. 23
5.1 Distress Alert ................................................................................................... 23
5.2 Land Mobile Alert ............................................................................................ 24
5.3 Distress Alert Acknowledgement .................................................................... 24

6 Polling and Data Reporting .................................................... 25


6.1 Individual Poll .................................................................................................. 25
6.2 Group Poll ....................................................................................................... 26
6.3 Area Poll ......................................................................................................... 26
6.4 Area Poll Status .............................................................................................. 27
6.5 Group Poll Status ............................................................................................ 27
6.6 Data Report ..................................................................................................... 27
6.7 Acknowledgement Data Report ...................................................................... 28

7 Enhanced Group Calls ........................................................... 28


7.1 EGC Packet (Single Header) .......................................................................... 29

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 2
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

7.2 EGC Packet (First of Double Header) ............................................................. 30


7.3 EGC Packet (Second of Double Header) ........................................................ 31
7.4 EGC Acknowledgement .................................................................................. 31

8 Communications between LES and NCS ................................. 31


8.1 MES Status Request ....................................................................................... 31
8.2 MES Status Request + Announcement ........................................................... 31
8.3 MES Status ..................................................................................................... 32
8.4 Cancel Announcement .................................................................................... 33
8.5 Network Record .............................................................................................. 33
8.6 Signalling Packet Envelope ............................................................................. 34
8.7 System Message ............................................................................................ 34

9 Demand Assignment .............................................................. 34


9.1 TDM Request .................................................................................................. 34
9.2 TDM Request Response ................................................................................. 35
9.3 TDM Release Request .................................................................................... 35
9.4 TDM Release .................................................................................................. 36
9.5 TDM Release Acknowledgement .................................................................... 36

10 Miscellaneous TDM Packets ................................................. 36


10.1 Continued Packet A ...................................................................................... 36
10.2 Continued Packet B ...................................................................................... 36

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 3
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

1 Introduction
This chapter lists the packets used in the Inmarsat-C System and describes their use in the various
protocols (see Volume 1). It explains the use of the parameters of each packet. The purpose and
circumstances of use of each packet are only given in general terms—for a definitive description of
their use, refer to the SDL diagrams in Volume 5.

2 Store and Forward Message Protocol

2.1 Assignment Request


Used by an MES to request an Assignment for a From-Mobile message transfer or a Performance
Verification Test. The Assignment Request will be sent directly to the LES if it has a permanent TDM,
but will be sent indirectly via the NCS, if the LES is demand assigned.

In the event that the Assignment Request comes indirectly (via the NCS) and has Distress Priority and
if the LES has the necessary Channel Units, the LES should request the additional frequencies
required using a TDM request for the Distress TDM.

The first parameter forms part of the packet Type code. Currently only 3 values are fully defined. They
are for Store and Forward message, Prefixed Store and Forward message and Performance
Verification Test.

The other parameters are:

MES ID The return 24 bit identifier of the MES.

LES ID The network identifier of the addressed LES.

Service Dependent Descriptor The only defined value for this field is the Message Length, i.e.
the number of message packets to be transferred.

Destination Descriptor A complex parameter conveying addressing information. It


consists of the following fields:

Destination Network Defines the type of terrestrial network or service to which the
message should be sent.

Extension Length Indicates the number of bits in the following Destination


Extension field.

Address Location Indicates how and where the addressing information is held in
this packet and in the first message packet.

Destination Extension Additional Destination Network/service information as required.

Address Full or abbreviated address for the first or only destination. The
address held here may be all the addressing information that is
required. More usually, however, the full address appears in
the first message packet and only a selected part of the
address appears here. Examples are: Telex Destination Code
for Telex, Country Code for PSTN access, DNIC for PSDN
access. For Address Location 4H, the address field in the
Assignment Request should contain only the Telex Destination
Code of the first (or only) address, padded if necessary by a
leading zero, so that the field is always three bytes in length.
Note that this padding is not done in the Message packet. The

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 4
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

address field in the Message packet should contain both the


Telex Destination Code and the National Telex Address.

2.2 Request Status


A Request Status packet may be sent by an LES in response to an Assignment Request from an
MES. The LES responds in this way, if it is unable to immediately proceed with the assignment. It will
be sent on the TDM channel, if the request was received directly or via the NCS if the request was
received indirectly. The NCS relays such Request Status packets received on an interstation
signalling link from an LES. The NCS also uses the packet to respond to a Login request that is
barred.

The parameters are as follows:

MES ID The forward 24 bit identifier for the addressed MES.

LES ID The network identifier for the particular LES.

Pending/Reject flag Indicates whether the request is actually rejected or that an


announcement will follow.

Request Status Code Gives further information as to the reason for rejection/pending.

2.3 Logical Channel Assignment


This is one of the two ways in which the LES starts a call to an MES and conveys the necessary
parameters of the call. (The other is by means of an Announcement via the NCS.) It is used in the
following circumstances:

- To accept an Assignment Request for a From-Mobile call received directly from an MES on an
LES Signalling channel.

- To proceed with a From-Mobile call, where the LES has issued an Announcement via the NCS
to indicate readiness to proceed. The MES must first respond with an Announcement
Response on an LES signalling channel, to inform the LES that it is listening.

- To initiate a follow-on To-Mobile call. The Logical Channel Assignment is issued instead of a
Clear, when the MES is waiting for the logical channel to be cleared, after receiving a message
as a result of the first call.

The Logical Channel Assignment remains in effect until the call is cleared in the normal way, by the
LES using a Clear packet, or is forced clear by the LES using an LES Forced Clear or by the MES
using an MES Forced Clear.

The parameters are as follows:

MES ID The forward 24 bit identifier for the addressed MES.

LES ID The network identifier for the particular LES.

Service This will normally be set to zero, to indicate Store-and-Forward


message. During Message Performance Verification it will be
set to 0EH. Other values can be used (see Chapter 3, Section
4.14).

Direction The value indicates To-Mobile, From-Mobile or Both directions


(see Chapter 3, Section 4.5).
Service Dependent Assignment Currently the only defined uses of this field are for From-Mobile
message transfer or for To-Mobile message transfer.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 5
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

These are respectively:

From-Mobile:

Logical Channel Number The identifier to be used for the call.

Frame length The number of message packets per (interleaved) frame. The
frame length is defined by the parameter N, where N+1 is the
number of message packets per frame. N is also referred to as
interleaver block size or interleave factor.

Duration The number of frames (of N+1 packets each) in the message.

LES TDM The satellite frequency code, or channel number, for the TDM
channel used.

Message Channel The satellite frequency code, or channel number, for the
Message channel to be used.
To-Mobile:

Logical Channel Number The identifier to be used for the call.

Message Reference Number A reference number for the message (binary coded).

Sub-address The number of a port on the MES DCE (normally zero).

Presentation IA5 with odd parity, ITA 2 or Data.

Packets The number of packets in the message.

Last Count The number of characters in the last packet.

For the To-Mobile logical channel assignment (follow-on call) the following are also sent as the
assignment response is transmitted using reserved access.

Signalling Channel The satellite frequency code for the signalling channel to be
used by the MES sending the assignment response.

Frame Offset The Offset of the Frame in which the MES should transmit the
assignment response.

AM/PM Bit Set as appropriate to the Frame Offset. Since the frame offset
contains only the least significant 8 bits of the frame number
(for re-transmission), there is a possibility that approaching
frame number 9999 (which may occur around midnight UTC)
the frame offset may be equal to or lower than the current
frame number least significant 8 bits. The AM/PM flag is used
to indicate if the frame offset refers to frames in the range 0 -
4999 or 5000 - 9999 (decimal).

Slot Number The slot number in which the MES should transmit the
assignment response.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 6
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

2.4 Assignment Response


Used by an MES to respond both to an Announcement from an LES for a To-Mobile message
transfer, and to a Logical Channel Assignment issued by the LES for a follow-on message. The
Assignment Response informs the LES that the MES is, or has now, tuned to it and is ready for the
Message.
The parameters are as follows:

MES ID The return 24 bit identifier of the MES.

Logical Channel Number The LCN that has been assigned for the call.

Packets The number of message packets to be transferred. It is


repeated back to the LES as a check.
2.5 Announcement
This packet is transmitted by the NCS on the Common Channel, as a result of a request from an LES
for an announcement to be made. The LES requests the announcement by sending a Status Request
+ Announcement packet to the NCS on the Interstation Signalling Link. The announcement conveys
to the specified MES, that the LES is ready to proceed with a message transfer. This may be in the
direction To-Mobile, or in the direction From-Mobile.

With the exception of Follow-on To-Mobile calls, an Announcement is always used to initiate a To-
Mobile call.

For From-Mobile calls, an Announcement is only used in two situations:

i) When an LES has no permanent TDM (that is, when it is Demand Assigned), the MES will
always make its Assignment Request via the NCS. The LES will use an Announcement (via the
NCS TDM) to indicate willingness to accept the call when it is ready. It does this, because it
knows that the MES is not listening to the LES TDM channel.

ii) When an LES has a permanent TDM, the MES will send the Assignment Request directly to the
LES. If the call can be accepted immediately, the LES will use a Logical Channel Assignment
(see 2.3 above) to accept the call. However, if the call has to be pended (by the issue of a
Request Status, with status = pending), when the LES later becomes ready to proceed with the
call, it will use an Announcement, because it must assume that the MES is no longer listening
to the TDM channel.

Since Announcements are transmitted on the NCS Common Channel, they are held back by the NCS
until it is sure that the MES is listening to the Common Channel. Thus the LES does not need to be
concerned with this matter, when it requests the Announcement. The MES is expected to tune to the
specified TDM channel, re-synchronise, determine the frequencies of the signalling channels from the
bulletin board and signalling channel descriptors, and send a response packet in an unreserved slot
of a Signalling Channel. The response packet will be an Announcement Response, if the direction is
From-Mobile, or Assignment Response, if the direction is To-Mobile. In the first case, the LES will
then issue a Logical Channel Assignment. In the latter case, it simply proceeds with the transfer of the
message on the TDM, the To-Mobile Assignment details having been included in the Announcement
packet.

The parameters are as follows:

MES ID The forward 24 bit identifier for the addressed MES.

LES ID The network identifier for the particular LES.

LES TDM The satellite channel being used for the LES TDM.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 7
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Service Defines the kind of transfer, e.g. Store and Forward,


Performance Verification, or other.

Direction The value indicates To-Mobile, From-Mobile or both directions.

Priority Routine or Distress.

For a To-Mobile call the Announcement also includes a To-Mobile Message Assignment, which may
be for normal Store-and-Forward message transmission or for Performance Verification. It consists of:

Logical Channel Number The LCN that shall be used for the call.

Message Reference Number A reference number for the message.

Sub-address Selects a physical or logical port at the DCE or DTE of the


MES.

Presentation The presentation code to be used for the message text. For
PVT, this is normally set to data.

Packets The number of packets that will be transmitted by the LES.

Last Count The number of characters in the last packet.

2.6 Announcement Response


Used by an MES to respond to an Announcement for a From-Mobile message transfer, that the MES
has requested earlier, but which was pended by the LES. The Announcement Response simply
informs the LES that the MES has now tuned to it and is ready for the Assignment.

The one and only parameter is:

MES ID The return 24 bit identifier of the MES.

2.7 Message Data


This packet is used to convey part of a To-Mobile message. The format of every packet is the same.
Note that this format is different from the format of Message Data packets conveyed on a Message
channel for the direction From-Mobile.

Each packet carries the following information:

LES ID The network identifier for the LES.

Logical Channel Number The reference number for the call.

Packet Sequence Number The ordinal number of the packet. An unsigned binary number
giving the sequence number of the packet in the message. The
first packet is given the number 1, and the number is
incremented by 1 for each subsequent packet in the message.

Data The fragment of the total message data conveyed in this


packet.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 8
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

2.8 Message Packet


Used by an MES to send one, or the only, packet of a message on a Message Channel. The format is
not the same as used by an LES to send packets of a message to the MES on the TDM channel.

The parameters are as follows:

Packet Number The ordinal number of the packet. The first packet contains 1
and the value is incremented by 1 for each following packet.

Message Header Only included in the first packet. It contains further details of
the message and/or address(es). Its content is:

Delivery Class Immediate or Deferred delivery.

Confirmation Whether confirmation is required for message delivery. Note


that an indication of non-delivery is always given and it is not
required to request such indication.

Length The total number of bytes in the Message Header.

Logical Channel Number The call reference number assigned by the LES.

Presentation IA5 with odd parity, ITA 2 or Data. For PVT, the same code is
used as for the To-Mobile call.

Last Count The number of characters in the last packet.

Additional Information Additional information (answerback, validation codes or


destination addresses for certain services) to be used by the
LES in establishing the terrestrial link. This field is empty for the
mandatory store and forward telex service.

Data The message data. Unused bytes at the end of the last packet
of a message are set to zero. For non 8-bit codes, bit 1 of the
first character will be stored in bit 1 of the first byte. Bytes in the
[Data] field are sequentially filled from bit 1 to bit 7 wrapping
around to bit 1.

For the mandatory Store and Forward Telex service, the


address input should be at the head of this field and should
conform to CCITT Rec. U80, paragraph 4.7 with the following
exceptions:

i) when using the IA5 alphabet, the EOA signal defined in


paragraph 4.7.4 should be replaced with the IA5 'STX'
character; and

ii) paragraph 4.7.3 is not applicable.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 9
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

2.9 Acknowledgement Request


Used by the LES to request an acknowledgement for a message sent to the MES. It is sent at the
conclusion of message transmission. If no response is received after a timeout, T17, the LES will re-
send the whole message. If no response is received after four attempts, the LES will Force Clear the
call.

The parameters are as follows:

LES ID The network identifier for the particular LES.

Logical Channel Number The LCN that has been used for the call.

Signalling Channel The satellite frequency code for the signalling channel to be
used by the MES sending the requested acknowledgement.

Frame Offset The Offset of the Frame in which the MES should transmit the
acknowledgement.

AM/PM Bit Set as appropriate to the Frame Offset. See Section 2.3.

Slot Number The slot number in which the MES should transmit the
acknowledgement.

2.10 Acknowledgement
Used by the MES to respond to a request from the LES for an acknowledgement of a To-Mobile
message.

The parameters are as follows:

Logical Channel Number The LCN that has been used for the call.

Errored Packet Nos. The ordinal numbers of any packets received in error. At most
11 errored packets can be reported at one time. The LES will
retransmit reported errored packets and will then again request
an acknowledgement. The MES will thus get another
opportunity to report further errored packets and this process
will be repeated until all packets have been received error-free
or until the attempt is aborted as a result of too many attempts
being required. In any one acknowledgement, if fewer than 11
packets are in error, this field is padded with zeros, to make
exactly 11 entries.

2.11 Acknowledgement
Used by an LES to acknowledge receipt of a message from an MES, but only when errors have
occurred. When a message is received without error, the LES simply sends back a Clear packet to
clear the call.

The parameters are as follows:

LES ID The network identifier for the particular LES.

Logical Channel Number The LCN that is being used for the current call

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 10
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Frame length Indicates the frame length (or interleave factor) that should be
used by the MES for the re-transmission of errored packets on
the message channel.

Duration The number of frames (of length determined by the frame


length) that should be re-transmitted from the MES.

Message Channel The satellite frequency code for the message channel used by
the MES.

Frame Offset Defines the Frame in which the MES should start its re-
transmission.

AM/PM Bit Set as appropriate to the Frame Offset. See section 2.3.

Slot Number The slot number at which re-transmission should start on the
Message channel.

Errored packet no. For each packet of the message received in error, there will be
an entry giving the number of the packet.

2.12 Clear
This packet is only used by the LES. It is sent at the end of a successful To-Mobile or From-Mobile
message transfer. Note that although it is listed in Chapter 4, it is not used by an MES.

The parameters are as follows:

MES ID The forward 24 bit identifier for the addressed MES.

LES ID The network identifier for the particular LES.

Logical Channel Number The LCN that has been used for the call.

For From-Mobile transfers a Message Reference Number is included:

Message Reference Number A reference number for the message.

For To-Mobile Message transfer the Message Reference Number has already been supplied at the
time of the Announcement.

2.13 Network Record


When a call has completed, whether successfully or unsuccessfully, a Network Record is sent to the
NCS by the LES.

The parameters are as follows:

LES ID The network identifier of the LES.

Call Commencement Is in Date-Time format.

Satellite Frequency Code An unsigned binary number giving the specific 5kHz channel.
The same coding is used whether the mobile earth station
expects to transmit on the signalling channel or on the
message channel.

Repeated Packets The count of the number of repeated packets in a message


transfer.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 11
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Service The [Service] field of the TDM Assignment packet or the lower
4 bits of the [Type] field of the MES Assignment Request as
appropriate.

Direction From-Mobile, To-Mobile or both.

Delivery Status A Boolean indicating whether or not a message has been


completely delivered.

Call Volume For From-Mobile, this field is split as follows:

Packets An unsigned binary number representing the number of


packets given in the assignment request packet.

Frame Length Copy of the [Frame Length] field of the logical channel
assignment packet sent to the MES by the LES.

For To-Mobile:

Packets An unsigned binary number representing the number of


packets given in the assignment request packet.

Packet Size An unsigned binary number representing the packet size in


bytes.

Time Complete Is in Date-Time format.

2.14 LES Forced Clear


There are various situations, in which the LES needs to be able to force clear a call, usually as a
result of an error, that has been repeated a number of times, or because of a timeout. It is also used
to respond to (or echo) an MES Forced Clear received from an MES. The LES Forced Clear will be
sent on the TDM channel or to the NCS (via the ISL) for transmission on the Common Channel,
depending on which TDM the LES believes that the MES is listening to. Note that the LES always
acknowledges a Forced Clear from an MES, by returning an LES Forced Clear.

The parameters are as follows:

MES ID The forward 24 bit identifier for the addressed MES.

LES ID The network identifier for the particular LES.

Logical Channel Number The LCN that has been used for the call.

Reason for Clear A code to indicate the reason for Force clearing.

2.15 MES Forced Clear


There are a number of situations in which the MES may find it necessary to abort a call. It does this by
sending this packet.

The parameters are as follows:

MES ID The return 24 bit identifier of the MES.

LES ID The network identifier of the addressed LES.

Logical Channel Number The identifier allocated to the call by the LES.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 12
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Reason for Clear A code indicating the reason the MES needs to clear the call.

2.16 Confirmation
If an MES requests confirmation of delivery of a From-Mobile message, the LES will send a
confirmation after delivery to the final destination, which may either be a terrestrial subscriber or
another MES. Note that this packet is always used to convey a Notification of Non-delivery if delivery
fails, regardless of whether the MES has requested confirmation or not. The confirmation packet is
sent via the NCS for transmission on the Common Channel. The NCS will only transmit the
confirmation, when the MES is idle and therefore should be listening to the Common Channel. For
multiple destination messages, one confirmation may be used to convey information concerning more
than one destination. Each destination's delivery details is given in a [Message Status Descriptor].
Confirmation of delivery is not supplied unless it is specifically requested in the Message Header of
the first packet of the message.

The parameters are:

MES ID The forward 24 bit identifier for the addressed MES.

LES ID The network identifier for the particular LES.

Message Reference Number A reference number for the message.

Message Status Descriptors A message status descriptor is included for each destination to
which the message was addressed. If the message reference
number is invalid or unknown at the LES only one descriptor
will be present. The format of the Message Status Descriptor
is:

Length The number of bytes in the descriptor including this field.

Status Value 1 for delivered, otherwise set to 0.

Attempts The number of attempts to deliver that have been made, or


7FH if the message reference number was invalid or unknown.

Non-delivery code Only present if Status is 0. A 3-character code formatted IA5


with odd parity, LES specific.

Address information The destination address, coded in IA5 with odd parity. Only
present if the message reference number was known and may
also be absent if the message was only addressed to a single
destination.

2.17 Message Status Request


An MES may request the status of a From-Mobile message that it has sent. This is particularly useful,
if a Confirmation was not requested or has not been received. The LES will respond with a Message
Status packet indicating whether the message has yet been delivered, is awaiting delivery or has
failed to be delivered for some reason. The LES uses the Message Reference Number to identify (if
possible) the particular message.

The parameters are as follows:

MES ID The return 24 bit identifier of the MES.

LES ID The network identifier of the addressed LES.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 13
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Message Reference Number The reference number allocated to the message when it was
input to the LES.

2.18 Message Status


This packet is used to return message status requested by an MES using Message Status Request.
This is always done, even if the Message could not be identified. Like Confirmation packets, Message
Status packets are sent via the NCS, which will wait until the MES is idle, before transmitting the
Message Status.

The parameters are as follows:

MES ID The forward 24 bit identifier for the addressed MES.

LES ID The network identifier for the particular LES.

Message Reference Number The reference number for the message as supplied by the
MES.

Message Status Descriptors A message status descriptor is included for each destination to
which the message was addressed. If the message reference
number is invalid or unknown at the LES only one descriptor
will be present. The format of the Message Status Descriptor
is:

Length The number of bytes in the descriptor including this field.

Status Value 1 for delivered, otherwise set to 0.

Attempts The number of attempts to deliver that have been made, or


7FH if the message reference number was invalid or unknown.

Non-delivery code Only present if Status is 0. A 3-character code formatted IA5


with odd parity, LES specific.

Address information The destination address, coded in IA5 with odd parity. Only
present if the message reference number was known and may
also be absent if the message was only addressed to a single
destination.

2.19 Transfer Status Request


If at any stage during a call, the MES is unsure as to the exact stage of the call, for example after a
timeout or when an unexpected packet is received, it may use this packet to request the LES to send
or resend a suitable packet to re-synchronise communications. Frequently the LES response is in fact
to Force Clear a call, if any, rather than to attempt to continue. It can happen that the MES may
request Transfer Status even after the LES has completed the call. This can occur when the LES has
sent Clear or Forced Clear, but the MES has not received it.

The parameters are as follows:

MES ID The return 24 bit identifier of the MES.

Logical Channel Number The identifier allocated to the call by the LES. If the Stage is
"Waiting for Distress Test Request" or "Waiting for Test
Results" the Logical Channel is undefined, and this parameter
should be set to zero.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 14
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Stage This number references the transfer stage that the mobile earth
station had reached before a timeout had occurred.

3 Network Management

3.1 Bulletin Board


The bulletin board contains largely unchanging information relating to that TDM channel (either LES
or NCS), and the facilities available, and is transmitted in every frame and is always the first packet in
the frame. The bulletin board is also used as a fixed length, reference packet by the MESs for the
purpose of assessing the quality of the mobile link. The parameters are as follows:

Network Version The current network configuration number (non-zero) for the
network associated with a particular NCS ID. For LES TDMs
this is set to 0.

Frame Descriptor This contains information specific to the current frame

Frame Number The number of the frame between 0 and 9999 (decimal). This
number is incremented by one every frame. In the case of NCS
TDMs these are synchronised with UTC; that is frame 0 occurs
concurrently (within some tolerance) with midnight UTC.

Signalling Channels Indicates the number of signalling channels associated with


that TDM. Used by the MES for transmission timing.

2-frame Count For all signalling channels associated with that TDM, indicates
the number of slots which are 2-frame slots (the earliest
occurring slots). The remaining slots being 3-frame slots.

Empty frame A 1 bit flag used to indicate to MESs if there are any other
packets in the current frame other than just the bulletin board
and signalling channel descriptors.

TDM Descriptor Contains details specific to the Earth Station (LES or NCS) and
the TDM channel.

Channel Type Indicates the type of TDM channel, for example NCS/LES/joint
common/standby. Used by the MES to determine if the network
is in restoration mode.

Local ID The ID of the TDM where a LES or NCS has more than one
TDM, numbered from 0 for the primary TDM.

Origin ID The LES/NCS ID. The first 2 bits identify the Ocean Region in
which the LES/NCS is operating. The remaining 6 bits identify
the LES/NCS within that Ocean Region. LESs are numbered
from x00 - x43 and NCSs x44 - x63 (where x is the Ocean
Region identifier and 0 ≤ x ≤ 3).

The status and service bytes below are set appropriately for each TDM of each NCS and LES within
the network. For the LESs they are usually the same as those transferred to the MES when it logs in
and receives network configuration information. When logging in the MES receives the status and
service information for the LES primary TDM (Local ID 0). Note that when an MES is about to transmit
on a signalling channel it uses the flags in the bulletin board, since this information is the most current,
and NOT the information downloaded for that LES (primary TDM) during login.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 15
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Status 8 1 bit flags to indicate the status of the LES and TDM. Note
that it is possible for these flags to be set differently for different
TDMs associated with the same Earth Station.

B8 Return link speed for all return channels (signalling and


message) associated with that TDM. This is used by the MES
in determining if it should transmit at 600 bits/s or 300 bits/s
(1200 symbols/s or 600 symbols/s).

B7 Whether the TDM is being transmitted on an operational or


spare satellite. For information only: not used by the MES.

B6 If the TDM is in service or out of service. If the TDM is


indicating out of service, MESs shall not attempt to transmit on
any return channels associated with that TDM.

B5 Indicates if the Earth Station is presently congested or not for


incoming, From-Mobile message channel traffic. If the
LES/NCS is congested, MESs must not attempt to transmit on
any signalling channel associated with that TDM, except for
alerting, data reporting or if a logical channel is currently active
(i.e. the MES is engaged in a call).

B4 In the case of LESs, this bit indicates if terrestrial lines are


currently open or not. For information only: not used by the
MES.

Services 16 1 bit flags used to indicate the services available at that LES
for that TDM group. Generally these are for information only
and are not used by the MES in any transmission protocol.
Note that it is possible for these flags to be set differently for
different TDMs associated with the same LES or NCS station.

Byte 1

B8 Indicates if distress alerting is available.

B7 Indicates if the TDM handles SafetyNETSM traffic.

B6 Indicates if the TDM handles Inmarsat-C traffic.

B5 Indicates if the TDM handles store and forward traffic.

B4 Indicates if the TDM handles half duplex traffic.

B3 Indicates if the TDM handles full duplex traffic.

B2 Indicates if the TDM handles closed network traffic.

B1 Indicates if the TDM handles FleetNETSM traffic.

Byte 2

B8 Indicates if the TDM handles prefixed store and forward


message traffic.

B7 Indicates if the TDM handles Land Mobile Alerting.

B6 Indicates if the TDM handles Aero-C traffic.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 16
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Randomising Interval Used by MESs when a collision has occurred on a signalling


channel. If the randomisation interval is X, the MES will wait for
N frames (where 1 ≤ N ≤ X and N is determined randomly)
before attempting to re-send the signalling channel packet.

3.2 Signalling Channel Descriptor


There is one signalling channel descriptor for each signalling channel associated with that TDM. The
parameters are as follows:

Available Indicates if the channel is available for store and forward and
general signalling functions associated with store and forward
messaging (i.e., logins, logouts, message status requests, etc).

CUG Indicates if the channel is available for closed user group use.
In other words it may be used for data reporting traffic or traffic
destined for a closed network.

Distress Indicates if the channel is available for Maritime Distress traffic.

Slotted Indicates if the channel is available for slotted ALOHA access


only, or if the channel can also support pure ALOHA access
(not currently used).

Land Mobile Alert Indicates if the channel is available for Land Mobile Alerting.

Aero-C Indicates if the channel is available for Aero-C traffic.

Satellite Frequency Code Indicates the satellite frequency code for the signalling
channel.

Slot State Markers Each 2 bit marker indicates if the associated slot is reserved or
not and if a signalling channel burst was successfully received
or not at the LES/NCS.

3.3 Login Request


Before an MES may use the network to send messages or to use other services, it must log in to the
NCS. The NCS must know to which NCS TDM the MES is tuned whilst it is idle so that it may route
call announcements correctly for that MES. The sole exception to this is the issuing of a Distress
Alert, which will be accepted in any state. A MES which is already logged in, may log in again without
first logging out. The NCS does not require that the MES log out first and will respond in the usual
way.

The parameters are as follows:

MES ID The return 24 bit identifier of the MES.

Class This field indicates the Class of the MES as defined in Volume
3, Part 2. The allowed values for this field are given in Chapter
4, Section 3.8.1.

Version Number The version number of the network configuration currently


stored in the MES (if there is one). A value of zero indicates
that the MES has no valid configuration for this NCS. The MES
will always send its stored current version number (if it has
one) when logging in except when the NCS ID to which it is
logging in is different from the current NCS ID stored.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 17
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

3.4 Login Acknowledgement


When an MES attempts a Log in to the NCS for a region, the NCS makes an initial check that the
MES number is in its database and that it is not barred. If this check fails it replies with a Request
Status packet indicating Request Barred. If the check succeeds, the NCS acknowledges the Login
with a Login Acknowledgement packet. The NCS compares the version number included in the Login
with its current version number and if they are the same a short-form acknowledgement is returned. If
the version number is not current, a full-form acknowledgement is returned.

The parameters are as follows:

MES ID The forward 24 bit identifier for the addressed MES.

Common Channel The satellite frequency code of the NCS common channel to
which the MES should tune. If this is not the same as that
assigned to the NCS to which the MES is logging in, then the
MES will tune to this channel and login once more.

The above parameters are included in both short-form and full-form acknowledgements.

The parameters below are only included in Full-form acknowledgements:

Network Version The current network configuration number (non-zero).

LES Total The number of operational LESs in the Ocean Region.

LES Descriptors For each LES in the above total, a descriptor is included. It
contains the following information:

LES ID The network identifier for the LES.

LES Status One byte of bit-wise codes indicating such things as 'In-
service', etc. coded in the same way as the Status byte of the
Bulletin Board.

LES Services Two bytes of bit-wise codes indicating the services supported
as in the Services byte of the Bulletin Board.

TDM channel The satellite frequency code for the TDM channel, if the LES is
using a permanent TDM, or FFFFH to indicate Demand
Assigned operation.

3.5 Logout Request


Used to indicate that the MES will not be available within the Inmarsat-C network. This will save
unnecessary reservation of resources at the NCS and LESs. The protocol is such however that the
Logout is not absolutely necessary when leaving one ocean region before logging in to another. A
Logout, when the MES is already logged out, will still be acknowledged. The only parameter is:

MES ID The return 24 bit identifier of the MES.

3.6 Logout Acknowledgement


The Logout Acknowledgement is sent by an NCS, in response to a Logout received from an MES.
The Acknowledgement is sent regardless of the MES logged in state. The packet only contains one
parameter:

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 18
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

MES ID The forward 24 bit identifier for the addressed MES.

3.7 Network Update


When changes are made to the network, that require a change to the version number, the NCS
broadcasts a network update packet to all MESs that are logged in and are currently Idle. An MES
that is busy at the time of the change will discover a change in the Network Version included in each
Bulletin Board from the NCS, when it next becomes Idle. If after 24 hours it has not received a
Network Update packet or it is unable to synchronise with an TDM channel, it will log in again.

The parameters are as follows:

Network Version The current network configuration number (non-zero).

LES Total The number of operational LESs in the Ocean Region.

LES Descriptors For each LES in the above total, a descriptor is included. It
contains the following information:

LES ID The network identifier for the LES.

LES Status One byte of bit-wise codes indicating such things as 'In-
service', etc. coded in the same way as the Status byte of the
LES Bulletin Board.

LES Services Two bytes of bit-wise codes indicating the services supported
as in the Services bytes of the LES Bulletin Board.

LES TDM The satellite frequency code for the TDM channel, if the LES is
using a permanent TDM, or FFFFH to indicate Demand
Assigned operation.

3.8 Registration
Used by an NCS to inform LESs in its Ocean Region of changes in the status of an MES, for example
after commissioning.

The parameters are as follows:

Forward MES ID The forward 24 bit identifier of the MES.

Return MES ID The return 24 bit identifier of the MES.

INMARSAT Mobile Number The INMARSAT Mobile Number for the MES encoded in
binary.

Answerback The four character answerback assigned to this MES. Coded


as IA5 characters, odd parity.

MES Status Idle, Busy, Not in OR, Commissioned, etc.

Current NCS If the MES is logged into a region, this field will contain the
NCS ID. Otherwise it will be set to zero.

Spot ID An unsigned binary number identifying the Spot beam. The


global beam will have ID zero.

Class This field indicates the Class of the mobile earth station as
defined in Volume 3, Part 2.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 19
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Sequence Number Each Registration packet will have the next sequence number
in a cycle from 1 to 255. When a Block Update is initiated, the
Sequence Number is reset to 1.

Update Time The time at which the update was applied to the MES database
at the NCS in Date-Time format.

3.9 MES Status Change


This packet is used by an NCS to inform other NCSs of changes in the status of an MES.

The parameters are as follows:

Originating NCS The identifier of the NCS.

MES ID The forward 24 bit identifier of the MES.

MES Status Four bits defining which station caused the change, whether
the MES is barred, logged in and commissioned.

Sequence Number An unsigned binary number which is incremented by one for


each MES Status Change packet sent. The sequence will reset
to one for the next packet following a count of FFH.

Update Time The time at which the update was applied to the sender's MES
database. In Date-Time format.

3.10 Update Request


AN LES may request an update of the information held about MESs in its database. The NCS will
transmit a Block Update Start packet, a sequence of Registration packets and a Block Update End
packet. The transmission takes place on the Interstation Signalling Link.

Equally an NCS, requiring re-initialisation from another NCS, may request an update of its MES
database. The NCS responding will transmit a Block Update Start packet, a sequence of MES Status
Change packets and a Block Update End packet. The transmission takes place on the NCS/NCS
Link.

The parameters are as follows:

NCS ID The identifier of the NCS being addressed.

Last Update Time The time contained in the last Registration packet received
which caused an update to the MES database at the LES. In
Date-Time format.

3.11 Block Update Start


NCS ID The identifier of the NCS transmitting the Block Update.

Update Request Time A repeat of the contents of the [Last Update Time] contained in
the Update Request packet. It is in Date-Time format.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 20
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

3.12 Block Update End


The parameters are as follows:

NCS ID The identifier of the NCS which has transmitted the Block
Update.

Last Sequence Number For transmission to an LES, this field contains the sequence
number of the last Registration packet sent by the NCS as part
of this update.

For transmission to a NCS, this field contains the sequence


number of the last MES Status Change sent as part of this
update.

Latest Time The time stored at the NCS of the last update to its database.
In Date-Time format.

4 Performance Verification Testing

4.1 Commission Request


When an MES logs in for the first time to the network, the NCS will initiate a commissioning
procedure, provided that it is registered and not barred. It selects a suitable LES in the same Ocean
Region and charges it to undertake the test and to report its findings. The packet is sent to the LES on
the Interstation Signalling Link. The Commissioning Test is just a PVT (but the MES status prior to the
test is "pending commissioning").

The parameters are as follows:

Forward MES ID The forward 24 bit identifier of the MES.

Return MES ID The return 24 bit identifier of the MES.

Class This field indicates the Class of the mobile earth station as
defined in Volume 3, Part 2.

Spot ID An unsigned binary number identifying the Spot beam. The


global beam will have ID zero.

4.2 Test Request


If an MES is having difficulty in using the service, even though it is already commissioned, it may
request a repeat of the Performance Verification Test. It may do this directly to an LES or to the NCS.
In the latter case the NCS will select a suitable LES to conduct the test provided it is not barred. PVT
is not allowed for an MES that is barred. The LES should not respond to a Test Request from an MES
that is not registered at the LES.

The only parameter is:

MES ID The return 24 bit identifier of the MES.

4.3 Distress Test Request


Used by the LES as part of Message Performance Verification. The MES is expected to respond with
Distress Alert Test.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 21
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

The parameters are as follows:

MES ID The forward 24 bit identifier for the addressed MES.

LES ID The network identifier for the particular LES.

4.4 Distress Alert Test


Used during Performance Verification Testing. This packet contains the same fields as the Distress or
Land Mobile Alert Packet.

4.5 Test Result


Used by an LES to return the results of either a commissioning or a performance verification to an
MES. It is sent to both the MES and to the NCS.

The parameters are as follows:

MES ID The forward 24 bit identifier for the addressed MES.

LES ID The network identifier for the particular LES.

Test Results The results of the Performance Verification Test are returned in the following format:

Attempts The number of full attempts made at the test sequence


including the attempt that was successful, if any. The value
zero is used to indicate that the sequence failed after the third
attempt. The LES is responsible for counting the number of
PVT attempts. An Attempts Count should be kept by each LES
for each MES, for which a PVT is requested. In addition the
NCS keeps a count of the number of attempts, and if it employs
more than one LES in the Commissioning attempts, the LES
supplied Attempts Count will be less than the total known to the
NCS. It is expected that this will not normally occur.

BBER The result of the Bulletin Board Error Rate assessment carried
out over the last 100 bulletin boards received by the MES.

Forward Attempts The number of attempts required to successfully transfer a


message from the LES to the MES (if known) within the
particular PVT attempt. A value of zero indicates that the
message failed to be delivered.

Return Attempts The number of attempts required to successfully transfer the


message from the MES to the LES within the particular PVT
attempt. A value of zero indicates that the message failed to be
delivered.

Distress Alert Test The result of the Distress Alert test. The following codes
are used in the circumstances listed:

01H Where a Distress Alert Test was not performed as part of a


PVT (for future use);

04H Packet unexpectedly empty (no position coordinates for


example) but otherwise valid;

05H Protocol flag in packet incorrectly set (see Chapter 4,


Section 3.7.2);

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 22
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

06H Packet data not valid.

Signal Strength The apparent signal strength (as measured on the message
channel) received at the LES referred to a reference level.

Overall Result Pass or Fail, with a coded reason in the case of the latter.

Signalling Channel The satellite frequency code for the signalling channel used by
the MES.

Frame Offset The Offset of the Frame in which the MES should transmit an
acknowledgement.
AM PM Bit Set as appropriate to the Frame Offset.

Slot Number The slot number in which the MES should transmit the
acknowledgement.

4.6 Test Result Acknowledgement


After a test is completed, the LES conducting the test will send a Test Result packet to the MES. The
MES should acknowledge the Test Result, by sending this packet.

The only parameter is:

MES ID The return 24 bit identifier of the MES.

5 Alerting

5.1 Distress Alert


May be used by an SES at any time to request emergency assistance when in distress. It is not
necessary for the SES to be logged in and may interrupt any other communication. It may be sent
directly to an LES or indirectly via the NCS. Special actions are taken to ensure that the Alert is not
lost or ignored. When the LES receives the Distress Alert, the LES sends an SES Status packet to the
NCS, to indicate that the MES is tuned to the LES.

The parameters are as follows:

MES ID The return 24 bit identifier of the SES.

LES ID The network identifier of the addressed LES.

Position Latitude, Longitude and time of position. If the position has not
been updated for more than 24 hours as indicated by the U1
flag, the last entered position should be used.

Protocol Maritime distress alert format.

Nature of Distress A code indicating the nature of the vessels distress situation.

Course Degrees from due North, or all 1s if unknown or static.

Speed Speed in knots. Zero if not known or static.

Automatic Activation Set to 1, if activated automatically as part of a Commissioning


or Performance Verification Test.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 23
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Position Update (U1) Set to 1 if the Position has not been updated in the last 24
hours.

Course/Speed Update (U2) Set to 1 if the Course and/or Speed have not been updated in
the last 24 hours.

5.2 Land Mobile Alert


May be used by an LMES at any time to request emergency assistance. It must be sent directly to an
LES. Special actions are taken to ensure that the Alert is not lost or ignored. When the LES receives
the Land Mobile Alert, the LES sends an MES Status packet to the NCS, to indicate that the MES is
tuned to the LES.

The parameters are as follows:

MES ID The return 24 bit identifier of the MES.

LES ID The network identifier of the addressed LES.

Land Position Latitude and Longitude (note that the format of this field is not
the same as the distress alert).

Protocol Land Mobile Alert format. This indicates that the packet is a
Land Mobile Alert.

User defined 0 indicates defined as below, 1 indicates remainder of format is


user defined.

Nature of Alert A code indicating nature of assistance requested or the reason


for the alert.

Automatic Activation Set to 1, if activated automatically, i.e. as part of a


Commissioning or Performance Verification Test.

Time of Position 3 bits coded to indicate how recently the position information
conveyed was updated.

Speed 2 bits coded to indicate the Mobiles speed.

Direction of travel 3 bits coded to indicate the direction of travel of the mobile.

Extra Information An 8 bit field which may be used by the user or service provider
to indicate further or special information.

5.3 Distress Alert Acknowledgement


Used by the LES to acknowledge a Distress or Land Mobile Alert from an MES. It will be transmitted
on the TDM channel, if the Distress Alert is received on a signalling channel; if the Distress Alert has
been received via the NCS, however, it will be transmitted (via the Interstation Signalling Link) on the
NCS Common Channel.

The parameters are as follows:

MES ID The forward 24 bit identifier for the addressed MES.

LES ID The network identifier for the particular LES.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 24
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

6 Polling and Data Reporting

6.1 Individual Poll


An individual poll may be sent by an LES to a MES via an NCS. The fields are as follows:

MES ID The forward 24 bit identifier for the addressed MES.

LES ID The network identifier for the particular LES. For LESs serving
multiple ocean regions it is permissible for the LES ID indicated
in the poll to have a different 2-bit ocean region identifier than
the sending LES, corresponding to a group address valid for
another ocean region.

Sub-address This field may be used by the poll originator to route polls at the
destination MES(s). Depending on the configuration of the
MES DCE, it may correspond to a physical port on the DCE or
a logical sub-address at the DCE or DTE.

DNID The DNID to which the MES belongs, or the DNID to be


downloaded or deleted if the command field specifies one of
these commands. Note that DNIDs in the range 32768 to
65536 (i.e., those for which the MSB is 1) are for future use.

Response The anticipated response expected from the MES following the
poll. Note that this facility may or may not be used by the
application. Therefore the actual response sent by the MES
may differ from that expected.

Command The command has the following format:

Ack This is a 1 bit flag which indicates if the MES should


acknowledge receipt of the poll (by sending an
acknowledgement data report to the LES originating the poll).

Command Type This indicates the type of command, specifically if this is for the
MES DCE (i.e., a download/delete or programming command)
or is for the DTE or application. Command codes 40H – 7FH
are user definable and are not intercepted by the MES DCE.

Sequence Number The sequence number of the poll. It is used to ensure that
duplicate polls are not passed to the application. It is not
necessary for the sequence number to be passed to the
DTE/application, but it is not precluded.

Text A free field which may contain further parameters depending


on the command type. In the case of a download command this
will just contain the member number (of that MES in the DNID).
A presentation code is not defined for this field (it is application
specific), except for download and delete commands which are
to be processed by the MES DCE in which case the
presentation is IA5 with odd parity. MES DCE programming
information is also conveyed in this field in which case the
formatting of the program parameters is pre-defined.

Individual polls are only accepted by the MES identified by the forward 24 bit ID in the poll packet.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 25
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

6.2 Group Poll


Group polls allow a number of MESs to simultaneously be polled by a terrestrial user. The MESs that
respond to the poll are only those that have previously had that DNID downloaded by the LES
sending the poll. The fields are as follows:

DNID The DNID to which the MES belongs, or the DNID to be


downloaded or deleted if the command field specifies one of
these commands. DNIDs are not unique within the network but
are unique to each LES.

LES ID The network identifier for the particular LES. Note that the
Group address consists of both the DNID and the LES ID. For
LESs serving multiple ocean regions it is permissible for the
LES ID indicated in the poll to have a different 2-bit ocean
region identifier than the sending LES, corresponding to a
group address valid for another ocean region.

LES TDM The satellite frequency code for the TDM channel, if the LES is
using a permanent TDM, or FFFFH to indicate Demand
Assigned operation. Note that this may be different from the
satellite frequency code provided for that LES in the network
configuration information (obtained from a login
acknowledgement or network update). The MES shall use the
LES TDM satellite frequency code supplied in the poll for the
response and/or acknowledgement (if either were requested).
Note that this will correspond to a TDM associated with the
issuing LES.

Sub-address This field may be used by the poll originator to route polls at the
destination MES(s). Depending on the configuration of the
MES DCE, it may correspond to a physical port on the DCE or
a logical sub-address at the DCE or DTE.

Randomising Interval In the event that a data report or acknowledgement data report
are to be transmitted in response to the poll, then the
randomising interval defines the number of frames over which
the MES is to randomise its response (i.e. if the randomising
interval is X, the MES randomly selects a number between 1
and X and sends its response after waiting this number of
frames). The randomisation interval shall also be used if the
response to the poll is a message transfer. In this case the
randomisation applies to the assignment request only. Note
that this randomisation interval should not be confused with the
randomisation interval of the bulletin board (see Section 3.1).
MESs should remain tuned to the NCS TDM until the
randomisation backoff has occurred.

The remaining fields are as defined for the individual poll.

MESs will only accept group polls for which a DNID/LES ID pair has been previously downloaded and
has not been disabled by the MES operator.

6.3 Area Poll


An area poll is identical to a group poll except that the address of the poll is defined as both a
DNID/LES ID and an area: that is the addressed MESs must belong to the DNID at that LES and must
also lie within the addressed area. In addition to the fields of the group poll, the following fields are
also present:

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 26
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Type This is a 3 bit field and defines the area type; Navarea, circular
area etc.

Length This is a 3 bit field and defines the area address length in
bytes.

Area The formatting of the area address is identical to the formatting


currently used to define EGC area addresses.

MESs will only accept area polls for which a DNID/LES ID pair has been previously downloaded and
has not been disabled by the MES operator, and if the currently stored position of the MES lies within
the addressed area.

6.4 Area Poll Status


Used by the NCS to confirm to the LES that it has broadcast an Area Poll submitted earlier.

The only parameter is:

DNID The identifier of the Data Closed Network.

6.5 Group Poll Status


Used by the NCS to confirm to the LES that it has broadcast a Group Poll submitted earlier.

The only parameter is:

DNID The identifier of the Data Closed Network.

For each group or area poll for a particular DNID sent to a NCS, no further polls of the same type and
for the same DNID should be submitted by a LES until a poll status packet has been received.

6.6 Data Report


Data Reports are sent by an MES directly to an LES or indirectly via the NCS. The latter method is
used where the LES is operating Demand Assigned. If the Continuation bit is set in the header of a
packet, the packet is considered to be a fragment of the complete Data Report. Where transmission is
via the NCS, the fragments are first re-assembled and the resulting Data Report is sent on the ISL in
a Signalling Packet Envelope.

The receiver of the Data Report can use the length field to determine whether it was sent using the
reserved or unreserved protocol, as a result of the greater information content of reserved data
reports, as follows:

Unreserved Reserved

1 packet report 8 8
2 packet report 20 20
3 packet report 32 32
4 packet report N/A 4

The parameters of the first data report packet are as follows:

DNID The identifier of the Data Closed Network.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 27
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

LES ID The network identifier for the particular LES.

Member Number The member number of that MES within the DNID.

Data Data field comprising data supplied by the user or application.

Continuation data report packets have a data field only; that is only the first packet in the sequence
contains the DNID, LES ID and member number.

6.7 Acknowledgement Data Report


This is a data report packet having a specific packet content and used for the purpose of
acknowledging polls. The acknowledgement is a link level function intended to convey to the LES/poll
originator that a poll has been successfully received by a destination MES, and the MES (DCE) has
completed any necessary action. It does not necessarily mean that the MES or application is able to
process or respond to the poll. The acknowledgement data report is always originated by the MES
DCE.

The parameters of the acknowledgement data report (contained in the data field of the data report
packet) are as follows:

Category Set to 10B indicating extended category.

Sub-category Set to 00H to indicate that this is a poll acknowledgement. The


category/sub-category byte, which is the first byte of the data
field of the acknowledgement data report is therefore always
set to 80H.

Command Set to the same value as the command field received in the
poll.

Sequence number Set to the same value as the sequence number received in the
poll in which the acknowledgement was requested. This allows
the poll originator to verify that the destination MES(s) received
the poll.

All Group and Area polls with new sequence numbers and recognised DNIDs/LES IDs shall be
acknowledged, if requested in the poll packet, even if the poll makes no change to the MES state. If
the LES ID of the poll has a different Ocean Region identifier from the LES issuing the poll, then the
acknowledgement will indicate the LES ID and Ocean Region identifier for the originating LES
indicated in the poll.

All Individual polls with any sequence number and recognised MES ID, DNID/LES ID shall be
acknowledged if requested in the poll packet even if the command cannot be handled (e.g., download
DNID when the MES is unable to accept further downloads). A download poll for a particular MES
shall be acknowledged, if requested, even if the DNID/LES ID pair has previously been downloaded.
A delete poll for a particular MES shall be acknowledged, if requested, even if the DNID/LES ID pair is
not recognised. In the event that the MES receives a poll requesting an acknowledgement for which it
has no associated member number (e.g., an individual DNID delete poll for a DNID not previously
downloaded), the acknowledgement may be sent with member number zero.

Only polls with new sequence numbers need be acted upon. Group and Area polls with repeated
Sequence Numbers need not be acknowledged if previously received and processed.

7 Enhanced Group Calls


An EGC message can have any length from 1 to 65,280 bytes. Messages that are longer than 256
bytes are divided into fragments. Each fragment (except perhaps the last) consists of 256 bytes of

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 28
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

data. The fragments are transmitted in EGC packets. There may be up to 255 packets in a single
message.

Each EGC packet has a header and an information field. The header has its own Checksum. It is
used by the MES to determine whether it should print an EGC message received with errors on the
TDM link. The EGC header Checksum is in addition to the normal packet Checksum and is used
when the packet Checksum indicates an error. The text in the Information field may still be accepted
for display, provided that there are no errors in the Packet Descriptor or Header (as determined by the
header Checksum check). Characters in error, as indicated by the parity bit (if the presentation is IA5
with odd parity), may be substituted with a 'low line' character before printing/display.

The Checksum for the EGC header is not important on the Inter-station signalling link, but for reasons
of uniformity, the same format is used on both the TDM channel and the ISL.

7.1 EGC Packet (Single Header)


The simplest form of EGC packet is the Single Header packet. Each Single Header packet carries
one fragment of the EGC message.

The parameters are as follows:

Service Code Any of the defined services, i.e. General Call, Group Call, NAV
warnings, Coastal warnings, MET/NAV warnings, MET
forecasts, Chart Correction Services, Shore-to-Ship Distress
Alert, SAR coordination, INMARSAT System Message, EGC
System Message, Download ENID, etc. Note that the least
significant four bits of the code, gives the number of bytes in
the accompanying address.

Continuation Indicates that the message continues in the next packet.

Priority Four priority levels as follows: Routine, Safety, Urgency or


Distress.

Repetition Number Zero for the first transmission, and incremented (modulo 32) for
repetitions of the message. Echoes, transmitted 6 minutes after
the primary transmission, have the same repetition number (as
the primary transmission).

Message Sequence Number A unique number to identify the message for the particular LES
and Service code. The sequence number is incremented for
every new message. The same sequence number is retained
for all repetitions of the same message.

Packet Sequence Number The sequence number of the packet within the message,
starting from 1.

Presentation IA5 with odd parity, ITA 2 or Data.

LES ID The network identifier for the particular LES.

Address EGC Network ID (ENID), Rectangular Area, Circular Area,


INMARSAT System Message address, Coastal warning
address, NAVAREA, EGC Receiver ID, or None as appropriate
to the Service Code. The address is identical for every header
of every packet associated with a particular message.

EGC Checksum The EGC header Checksum is calculated on the header only.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 29
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Information The Message or Message fragment. The message text is as


received from the terrestrial subscriber. In the case of the
Download ENID command, the ENID is conveyed as 5 decimal
digits in IA5, as described in Volume 3, Part 1, Chapter 2,
Section 9.3.3.11.

7.2 EGC Packet (First of Double Header)


For a more reliable transmission, each message fragment (max 256 bytes) is further divided into two
packets, the First and the Second. Each packet of the pair includes an identical copy of the header,
hence the name Double Header. This means that the EGC receiver may process the information in
the packets if only one (or both) of the headers are valid, giving a higher probability of reception under
impaired channel conditions. The first packet is limited to 16 bytes of data, the remainder (from 0 up to
240 bytes) is sent in the second packet of the pair. The packet pair are always sent adjacent to one
another on the NCS TDM.

The parameters are as follows:

Service Code Any of the defined services, i.e. General Call, Group Call, NAV
warnings, Coastal warnings, MET/NAV warnings, MET
forecasts, Chart Correction Services, To-Mobile Distress Alert,
SAR coordination, INMARSAT System Message, EGC System
Message, Download ENID, etc. Note that the least significant
four bits of the code give the number of bytes in the
accompanying address.

Continuation Indicates that the message continues in the next pair of


packets.

Priority Four priority levels as follows: Routine, Safety, Urgency or


Distress.

Repetition Number Zero for the first transmission, and incremented (modulo 32) for
repetitions of the message.

Message Sequence Number A unique number to identify the message for the particular LES
and Service code. The sequence number is incremented for
every new message. The same sequence number is retained
for all repetitions of the same message.

Packet Sequence Number The sequence number of the pair of packets within the
message, starting from 1. The two headers in the two packets
of the pair will have the same packet sequence number.

Presentation IA5 with odd parity, ITA 2 or Data.

LES ID The network identifier for the particular LES.

Address EGC Network ID, Rectangular Area, Circular Area, INMARSAT


System Message address, Coastal warning address,
NAVAREA, EGC Receiver ID, or None as appropriate to the
Service Code.

EGC Checksum The EGC header Checksum is calculated on the header only.

Information First part (16 bytes) of a Message fragment. If the last packet
of a message, may be less than 16 bytes,

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 30
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

7.3 EGC Packet (Second of Double Header)


The parameters are as follows:

EGC Header Identical copy of the EGC Header in the first packet of the pair.

Information Second part of the Message fragment (from 0 up to 240 bytes).

7.4 EGC Acknowledgement


The EGC acknowledgement is sent for a whole message, which may have consisted of several
fragments sent in Single or Double Header packets. The acknowledgement will not be sent unless
and until a packet is received with the Continuation bit not set.

The packets of a multipacket EGC message will be received by the NCS in order, since LAPB does
not use Selective Reject. The only case in which packets might be lost, is where the link is reset as a
result of serious errors. The NCS recognises the last packet of an EGC message, when the
Continuation bit is not set. If at this point, it has received all of the packets of the message, a positive
EGC Acknowledgement is returned (Receive Status = 1), otherwise a negative EGC
Acknowledgement is returned (Receive Status = 0). If the last packet of a message is lost, the EGC
Acknowledgement will not be sent. Therefore it is advisable that the LES should use a timer to detect
this problem. The duration should be T14. Complete EGC messages may be received out of order, as
a result of re-transmissions following negative acknowledgements. This does not matter at the NCS
and will not be the cause of sending a negative acknowledgement.

The parameters are as follows:

Message Sequence Number The message sequence number given to the particular EGC
message by the LES.

Receive Status Indicates to the LES whether the NCS received the whole EGC
message successfully.

8 Communications between LES and NCS

8.1 MES Status Request


Either station may enquire the view that the other has of the status of a particular MES. The receiver
responds by sending MES Status. The NCS view prevails if there is a difference after making
allowance for transmission time between the two stations.

If the LES receives an MES Status Request for an MES that is not in its MES List, it should reply by
sending an MES Status of 0, indicating that the MES is not commissioned.

The parameters are as follows:

MES ID The forward 24 bit identifier of the MES.

8.2 MES Status Request + Announcement


This is the means by which an LES requests an NCS to make an Announcement. The NCS will return
the status of the MES and of the Announcement.

The parameters are as follows:

MES ID The forward 24 bit identifier of the MES.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 31
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Announcement Reference A number chosen by the LES in a monotonic ascending


sequence (modulo 256), to allow the LES to subsequently refer
to the announcement.

Service Store and Forward Message, Pre-assigned Data Reporting,


Message Performance Verification or other.

Direction To-Mobile, From-Mobile or both.

Priority This field represents the service grade required and the
absolute priority of the request (at present only distress and
normal). It consists of two sub-fields:

Network Priority Normal or Distress

Service Grade This is an unsigned binary number whose representation is


dependent on the [Service] field.

LES TDM The satellite frequency code or, if demand assigned, the value
FFFFH.

To-Mobile Assignment This field is only present when the [Direction] field indicates
that a To-Mobile message transfer is being announced. It
consists of either a To-Mobile S&F Message Assignment or a
Performance Verification Assignment. In either case, it will
carry the following fields:

Logical Channel Number A reference number that will be used for the call

Message Reference Number A reference number for the message.

Sub-address Selects a port at the MES; generally set to zero.

Presentation IA5 with odd parity, ITA 2 or Data

Packets An unsigned binary number giving the number of packets to be


transferred on the land earth station's TDM.

Last Count The number of characters in the last packet.

8.3 MES Status


Used by both stations to inform the other of the status of an MES. This may be in response to an MES
Status Request or unsolicited. It is also used by the NCS to return the status of an Announcement at
various stages.

The parameters are as follows:

MES ID The forward 24 bit identifier of the MES.

Current NCS If the MES is logged into a region, this field will contain the
NCS ID. Otherwise it will be set to zero.

MES Status Idle, Busy, Not in OR, Commissioned, etc.

Call Status For the direction NCS to LES, this field is set to "No call",
"Announcing", "Announcement in Queue" or "No TDM
Assignment". After completion of Cancel Announcement, the
Call Status returned will be "No call". For the direction LES to

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 32
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

NCS, it is set to zero and conveys no information in this


direction.

8.4 Cancel Announcement


After requesting the NCS to make an Announcement, the LES may find that it would be unable to
proceed with the call as a result of a change of circumstances. In this situation it may attempt to
cancel the Announcement if it has not already been made. The NCS will respond with an MES Status
packet with the Call Status set to "No Call".

The only parameter is:

Announcement Reference An 8 bit announcement reference number.

8.5 Network Record


A record is sent to the NCS for every Call made, whether completed successfully or not. Note that no
Network Record is required for the calls of a PV test.

The parameters are as follows:

LES ID The network identifier for the particular LES.

Call Commencement The time that the call was started in Date-Time format.

Satellite Frequency Code The satellite frequency code for the TDM channel, if the LES is
using a permanent TDM, or FFFFH to indicate Demand
Assigned operation.

Repeated packets A count of the number of packet re-transmissions. For To-


Mobile calls this should be a count of the total number of
packets retransmitted after the original transmission. For From-
Mobile calls this should be a count of the total number of
packets requested for retransmission. Note that for each
repeat Logical Channel Assignment required during the call,
the original message size in packets should be added to this
count.

Service Store and Forward, Message-Performance Verification, Pre-


assigned Data Reporting, etc.

Direction To-Mobile, From-Mobile or both.

Delivery Status Completely delivered or Failed.

Call Volume For From-Mobile - two fields: Packets and Frame Length,
where:

Packets The number of packets given in the Assignment Request.

Frame Length The Frame length as given in the Assignment Request.

For To-Mobile - two fields: Packets and Packet Size, where:

Packets The number of packets given in the Announcement.

Packet Size Number of bytes in each of the packets of the message. If the
last packet is shorter than the rest, it is the length of the earlier
packets that is used.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 33
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Time Complete Time at which the Call ended in Date-Time format.

8.6 Signalling Packet Envelope


This packet is used to convey certain received Signalling packets from the NCS to the LES and in one
instance from the LES to the NCS. These are:

From NCS to LES: Assignment Request

Data Report

Distress Alert

Message Status Request

MES Forced Clear

Test Request

From LES to NCS: Distress Alert

Continuation packets are combined to form a single packet after removal of the Checksums and
packet descriptors (except for the packet descriptor of the first packet).

8.7 System Message


The only parameter is the text of the message. A variable length field of text using IA5 (IRV), with odd
parity. The message will be made available to the receiving Earth Station's controller. May be used for
communications between LESs and their associated NCS. A maximum of 256 bytes is allowed.

9 Demand Assignment

9.1 TDM Request


Used by a Demand Assigned LES to request a TDM group of frequencies. To guard against the
possibility that no reply is received from the NCS, the LES may start a timer on making the request
and repeat it with the same reference number after a timeout.

If the NCS receives a TDM Request with the same reference number as a previously answered
request, the NCS will resend the response.

The parameters are as follows:

Request Number An unsigned binary number. Each new request from an LES for
a TDM is given a sequential number to allow the LES and NCS
to differentiate between requests and to refer to them. AN LES
repeating a TDM request will use the same request number.

Permanent Indicates whether or not this is a request for a permanent TDM


(i.e. one without time limit).

Request Priority Indicates whether or not LES has distress traffic to process
immediately.

Spot ID An unsigned binary number identifying the Spot beam. The


global beam will have ID zero.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 34
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

Number Return Channels An unsigned binary number indicating the number of return
channels (signalling or message channels) the LES is
requesting to be allocated with the TDM channel. The current
range of this parameter is 0 to 40 decimal.

9.2 TDM Request Response


Used by the NCS to respond to a TDM request.

The parameters are as follows:

LES TDM The satellite frequency code.

Request Number An unsigned binary number. Each new request from an LES for
a TDM is given a sequential number to allow the LES and NCS
to differentiate between requests and to refer to them. An LES
repeating a TDM request will use the same request number.

TDM Status This field indicates the status of the TDM assignment coded as
follows:

0H TDM assignment rejected

1H TDM assignment successful

2H TDM assignment pending (placed in queue)

Hold Time This field is only present if the assignment is successful. An


unsigned binary number giving the preferred maximum hold
time for the TDM in minutes. A value of zero indicates no
maximum. For a TDM provided for Distress purposes, no
maximum is set, but the LES is expected to return the TDM
immediately after it has completed the Distress Alert
procedure.

Return Channels If the assignment is successful, this field contains a list of the
return channels. Each satellite frequency code defines a return
channel which may be used with the assigned TDM channel. A
return channel can be used for either a message or signalling
channel.

9.3 TDM Release Request


If the Hold Time expires and the TDM has not been released, or for other reasons, the NCS may
require the return of a TDM group of frequencies allocated earlier.

In the event that a TDM Release Request is received for a TDM that has been released, has not yet
been received, or is otherwise not held, the LES should respond with a TDM Release, but take no
further action.

The parameters are as follows:

LES TDM The satellite frequency code.

Spot ID An unsigned binary number identifying the Spot beam. The


global beam will have ID zero.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 35
Inmarsat Confidential C SDM
(Version Release CD004, CN142)

9.4 TDM Release


When the LES is able to release a TDM group, it uses this packet. This may be in response to a
demand from the NCS or it may be unsolicited.

The parameters are as follows:

LES TDM The satellite frequency code.

Spot ID An unsigned binary number identifying the Spot beam. The


global beam will have ID zero.

9.5 TDM Release Acknowledgement


The NCS acknowledges a TDM Release.

The parameters are as follows:

LES TDM The satellite frequency code.

Spot ID An unsigned binary number identifying the Spot beam. The


global beam will have ID zero.

10 Miscellaneous TDM Packets

10.1 Continued Packet A


When a packet is transmitted on a TDM channel, it is included in a frame with other packets. If the
frame would become too long by the inclusion of the whole packet, the Earth Station may split the
packet into two parts. The first part is sent as the last packet of the current frame and the second part
as the first packet (after the Bulletin Board and Signalling Channel Descriptors) of the next frame. So
that the MES can correctly recognise and reassemble the two parts, the sender encloses them within
special envelopes. The first part is enclosed within a Continued Packet A and the second part within a
Continued Packet B. Each part is conveyed as the type dependent field of the relevant Continuation
packet.

The split of the original packet may not be made within the original Packet Descriptor, i.e. it may only
be made within the Information part of the original packet. If this would mean that the current frame
would be too long, then the whole packet must be held back until the next frame. Note that the
Checksum of the original packet is removed, but the length given in the original Packet Descriptor is
not altered. The Checksum is removed because a new Checksum is computed for each Continuation
packet.

10.2 Continued Packet B


The second part of a packet split across two frames, is conveyed inside a Continued Packet B
envelope. This packet is sent as the first packet of the next frame after the Bulletin Board and
Signalling Channel Descriptors. Note that the Checksum of the original packet is removed, because a
new Checksum is computed for the Continuation packet.

Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 36
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 13: Packet Formats for Mobile To Mobile


Data Reporting with Indirect Acknowledgement

Contents

1 Introduction ............................................................................ 2

2 Packet Formats ....................................................................... 2


2.1 Mobile To Mobile Data Reporting and Polling ...................................................2
2.1.1 Packet Format for Mobile to Mobile Data Report (Type 08H) ........................2
Figure 1: Packet Format (Type 08H) for Mobile to Mobile Data Reports ................2
2.1.2 Packet Format for Mobile to Mobile Poll (Type 25H) ......................................3
Figure 2: Packet Format (Type 25H) for Mobile-Mobile Polls..................................3
2.2 Base Oriented Data Reporting and Polling .......................................................3
2.2.1 Packet Format for Data Report from Mobiles .................................................3
Figure 3: Non-Interpreted Data Report Format from a Mobile in a Mobile-Base Data
Reporting .................................................................................................4
2.2.2 Polling Packet Format to Base Station ...........................................................4
Figure 4: Packet Format for a Poll to Base Station .................................................5
2.3 Common Field Descriptions ..............................................................................5
2.3.1 Source Member Number (8 bits) ....................................................................5
2.3.2 Destination Member Number (8 bits) .............................................................5

Volume 4: Packet Formats and Usage, Page: 1


Chapter 13: Packet Formats for Mobile To Mobile Data Reporting with Indirect
Acknowledgement
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
This chapter describes the packet formats used for the optional Mobile to Mobile data reporting with
indirect acknowledgement in the Inmarsat-C system. The uses of these packet formats are detailed in
the Volume 2 Part 2 Application Note 5.

As it is an optional service, its implementation at an individual Inmarsat-C LES is at the discretion of


that particular LES.

2 Packet Formats

2.1 Mobile To Mobile Data Reporting and Polling


Under this mode of communication, the mobiles within a closed user group will stay tuned to the LES
at all time. They use a new data report packet format to send data reports over the LES signalling
channel and the LES will reformat the data reports to a new poll packet type for sending over its TDM

2.1.1 Packet Format for Mobile to Mobile Data Report (Type 08H)
The packet format for data reports from mobile is shown in Figure 1 below. With the exception of
packet type and destination member number, the definitions for the rest of the data fields are the
same as that for the standard data report packets.

Figure 1: Packet Format (Type 08H) for Mobile to Mobile Data Reports

Bit No. Bit No.


8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
1 1 C
P C Type = 08H P Type
2 2
DNID
3 3
4 4
LES ID
5 5
Source Member No.
6 6 Data
Destination Member No. Bytes
Bytes 7
7
8 8
Data
9 9
10 10
11 11
12 12
13 13
14 14 CRC
CRC 15
15
Mobile-Mobile Data Report Package First/second Continuation Packet
(Optional)

[Mobile to Mobile Data Report]:= [Data Network ID (DNID)][LES ID]


[Source Member Number]
[Destination Member Number]
[Data] or
[Data]

Volume 4: Packet Formats and Usage, Page: 2


Chapter 13: Packet Formats for Mobile To Mobile Data Reporting with Indirect
Acknowledgement
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Fields on Source and Destination Members are defined in Section 2.3 and the other fields are used
as defined in Chapter 8 on Packet Formats for the Data Reporting Service.

2.1.2 Packet Format for Mobile to Mobile Poll (Type 25H)


The poll packet format for mobile to mobile transaction is shown in Figure 2.

Figure 2: Packet Format (Type 25H) for Mobile-Mobile Polls

Bit No.
8 7 6 5 4 3 2 1
1 25H
1P 0 Type =
2 Length
3
DNID
4
5
LES ID
6
Source Member
Bytes 7 Destination Member
8 Sequence No.

Data

[Mobile to Mobile Poll]:= [Data Network ID (DNID)][LES ID]


[Source Member Number]
[Destination Member Number]
[Sequence Number][Data]

Fields on Source and Destination Members are defined in Section 2.3 and the rest of the fields are
used as defined in Chapter 9 on Packet Formats for the Polling Service.

2.2 Base Oriented Data Reporting and Polling


In this mode of communication, the data report packets from the mobiles are not interpreted by the
LES and they will be reformatted into a poll packet of type 24H for sending to the Base Station over
the LES TDM. However, the data reports from the Base Station will be interpreted by the LES to
construct the appropriate standard polls for sending over the NCS common channel to the mobiles
(see Application Note 5 of Volume 2 Part 2). A Base Station is an MES which is normally fixed at a
location and provides the functionality of a hub in collecting data from a closed group of mobiles.

2.2.1 Packet Format for Data Report from Mobiles


The data fields within the data reports which originate from the mobile terminals are the same as that
for standard data report packets as shown in Figure 3.

The definitions for standard data report packets are described in Volume 4, Chapter 4 of the SDM.

Volume 4: Packet Formats and Usage, Page: 3


Chapter 13: Packet Formats for Mobile To Mobile Data Reporting with Indirect
Acknowledgement
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 3: Non-Interpreted Data Report Format from a Mobile in a Mobile-Base Data


Reporting
Bit No. Bit No.
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
1 1 C
P C Type P Type
2 2
DNID
3 3
4 4
LES ID
5 5
Source Member
6 6 Data
Bytes Bytes
7 7
8 8
Data
9 9
10 10
11 11
12 12
13 13
14 14 CRC
CRC
15 15

Standard Data Report Packet First or Second Continuation Packet


(Optional)

[Data Report from Mobile]:= [Data Network ID][LES ID]


[Source Member Number][Data] or
[Data]

Field on Source Member is defined in Section 2.3 and the remaining fields are used as defined in
Chapter 8 on Packet Formats for the Data Reporting Service.

2.2.2 Polling Packet Format to Base Station


The data report packets from mobile are reformatted by the LES into a new polling packet type 24H
which shall then be transmitted over the LES TDM.

The definitions of the polling packet type 24H are given in Figure 4.

[Mobile to Base Station Poll]:= [Data Network ID(DNID)][LES ID]


[Source Member Number]
[Sequence Number][data]

Fields on Source and Destination Members are defined in Section 2.3 and the other fields are used
as defined in Chapter 9 on Packet Formats for the Polling Service.

Volume 4: Packet Formats and Usage, Page: 4


Chapter 13: Packet Formats for Mobile To Mobile Data Reporting with Indirect
Acknowledgement
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 4: Packet Format for a Poll to Base Station

Bit No.
8 7 6 5 4 3 2 1
1
1
P 0 Type = 24H
2 Length
3
DNID
4
5
LES ID
6
Source Member No.
Bytes 7
Sequence No.
8
Data

2.3 Common Field Descriptions

2.3.1 Source Member Number (8 bits)


A number uniquely identifies the data report originating MES within the group defined by the DNID
and LES ID pair.

2.3.2 Destination Member Number (8 bits)


A number uniquely identifies the MES within the group defined by the DNID and LES ID for receiving
the data report.

Volume 4: Packet Formats and Usage, Page: 5


Chapter 13: Packet Formats for Mobile To Mobile Data Reporting with Indirect
Acknowledgement
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Chapter 14: Packet Formats for the Enhanced Data


Reporting Service

Contents

1. Introduction ........................................................................... 3

2. Packet Formats ...................................................................... 3


2.1 Data Report.......................................................................................................3
Figure 1: Enhanced Data Report Packets .................................................................3
2.2 MES ID (24 BITS) .............................................................................................4
2.2.1 LES ID (8 Bits) ...............................................................................................4
2.2.2 Sequence (2 bits) ...........................................................................................4
2.2.3 Length (6 bits) ................................................................................................4
2.2.4 A-Acknowledgement Requested (1 bit) ..........................................................4
2.2.5 Spare (1 bit) ...................................................................................................4
2.2.6 Control Type (3 bits) ......................................................................................4
2.2.7 Control Length (3 bits) ...................................................................................5
2.2.8 Control Information ........................................................................................5
2.2.8.1 Data Network ID (16 bits) ....................................................................................................... 5

2.2.8.2 Member Number (8 bits) ........................................................................................................ 5

2.2.9 Data Report Checksum (16 Bits) ...................................................................5


2.2.10 Fill ................................................................................................................5
2.2.11 Packet Checksum (16 Bits) ..........................................................................5
2.2.12 Enhanced Data Report Payload and Checksum Location ...........................6
2.3 Enhanced Data Report Status Request ............................................................6
Figure 2: Enhanced Data Report Status Request Packet ..........................................6
2.4 Enhanced Data Report Acknowledgement .......................................................7
Figure 3: Enhanced Data Report Acknowledgement Packet .....................................7
2.4.1 MES ID (24 BITS) ..........................................................................................7
2.4.2 Sequence (2 bits) ...........................................................................................7

Volume 4: Packet Formats and Usage, Page: 1


Chapter 14: Packet Formats for the Enhanced Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

2.4.3 Length (6 bits) ................................................................................................7

Volume 4: Packet Formats and Usage, Page: 2


Chapter 14: Packet Formats for the Enhanced Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

1. Introduction
The Enhanced Data Reporting service is intended for transferring small quantities of data from an
MES. Data is transferred on a signalling channel using unreserved access. Enhanced Data Reporting
differs from Data Reporting in that the entire data report is protected by a checksum and an
acknowledgement is sent from the LES to the MES on successful reception of the entire enhanced
data report, as determined by the data report checksum.

Enhanced Data Reporting is intended to be fully compatible with the exisitng Data Reporting service,
but provides enhanced data integrity, reliability and additional flexibility concerning addressing.

This chapter describes the packet formats used for Enhanced Data Reporting. The communication
protocol used for this service is described in Volume 1.

2. Packet Formats
The Enhanced Data Report packets and the Enhanced Data Report Status Request packets are sent
by an MES to an LES on an MES signalling channel. The Enhanced Data Report Acknowledgement
packet is sent by an LES on an LES TDM to an MES following successful reception of an Enhanced
Data Report.

2.1 Data Report

Figure 1: Enhanced Data Report Packets

P C Type P C Type P C Type

MES RTN ID

Data
LES ID
Seq Length
A S Ctrl Ctrl len
Data
DR checksum

Additional Control/Data
Fill

Packet
Packet Checksum Packet Checksum
Checksum

First Enhanced Data Second or third Fourth or last


Report Packet Enhanced Data Enhanced Data
Report Packet Report Packet

Volume 4: Packet Formats and Usage, Page: 3


Chapter 14: Packet Formats for the Enhanced Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

[Enhanced Data Report] ::= [MES ID] [LES ID] [Sequence] [Length] [A] [Spare]
[Control type] [Control length] [Control information] [Data]
or
[Data]
or
[Data] [Data Report Checksum]

For the first packet in a Data Reporting sequence, the MES ID, LES ID, Sequence, Length, A, Control
type, Control length and Control field are included. The remaining packet(s) in the sequence may
contain only the [Data] field.

2.2 MES ID (24 BITS)


The number allocated by INMARSAT for use in the return direction, uniquely identifying a particular
mobile earth station.

2.2.1 LES ID (8 Bits)


A number uniquely identifying a particular land earth station.

2.2.2 Sequence (2 bits)


Each time a new enhanced data report is sent, the Sequence number is incremented, modulo-4.
Repeats within the protocol of previously sent data reports will have the same Sequence number.

2.2.3 Length (6 bits)


Defines the length, in bytes, of the data contents of the data report (excludes control information – see
below).

2.2.4 A-Acknowledgement Requested (1 bit)


Set as follows:

0B No acknowledgement requested
1B Acknowledgement requested (default for unreserved data reporting)

Provides the user/application the option of requesting an acknowledgement or not.

2.2.5 Spare (1 bit)


Set to zero.

2.2.6 Control Type (3 bits)


Defines the type and structure of information provided in the control field. The field is coded as
follows:

0H DNID & member number supplied (control length = 3H)


1H – 7H [TBD]

Volume 4: Packet Formats and Usage, Page: 4


Chapter 14: Packet Formats for the Enhanced Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

2.2.7 Control Length (3 bits)


Defines the length of the control information field in bytes.

0H – 6H Control information field length in bytes (0 – 6 bytes)


7H Not used

2.2.8 Control Information


The control information filed (with length in bytes defined in the control length field) provides pre-
defined control information in accordance with the control type field.

For control type 0H (DNID and member number supplied):

[Control Information]::= [Data Network ID] [Member No.]

2.2.8.1 Data Network ID (16 bits)

Gives the closed network address to be used when sending a Data Report.

2.2.8.2 Member Number (8 bits)

A number uniquely identifying the MES within the group defined by the Data Network ID and LES ID.

2.2.9 Data Report Checksum (16 Bits)


A Checksum is calculated as defined in Volume 4, Chapter 1, Fig. 1-1 (Error Detection Coding
Algorithm). This field is only present if the enhanced data report includes two or more packets. The
position of the [checksum] field depends on the number of packets comprising the data report and the
quantity of data as defined in the [length] field. The Data Report Checksum is calculated over all
contents fields of the data report for all packets comprising the data report, including MES ID, LES ID,
etc. If the enhanced data report size is such that it may use a single packet, no data report checksum
is added, i.e. the data report checksum is only added in data reports consisting of two or more
packets. Each packet will always include a packet checksum.

2.2.10 Fill
Fill bits (all zeroes) may be included after the data report checksum and before the packet checksum.
These fill bits are not taken into account when the data report checksum is calculated, but are
included in calculating the packet checksum.

Note: If the last packet checksum indicates an error, it is possible that the errors occurred in the fill
bits and/or packet checksum. A valid data report may still be recovered if the data report checksum is
valid.

2.2.11 Packet Checksum (16 Bits)


A Checksum is calculated as defined in Volume 4, Chapter 1, Fig. 1-1 (Error Detection Coding
Algorithm). The [checksum] field is at the end of the packet.

Volume 4: Packet Formats and Usage, Page: 5


Chapter 14: Packet Formats for the Enhanced Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

2.2.12 Enhanced Data Report Payload and Checksum Location


The following table indicates the maximum payload capacity and the location of the checksum bytes.

First
packet Total Note +1 and +2
2nd 3rd 4th
Payload Pckts payload including indicated bytes
Packet Packet Packet
Chksum used for checksum
Min. Max.
0 to 6 1 0 6 - - - 0 to 6 No Chksum
7 to 16 2 0 6 10+2 - - 9 to 18 Chksum in Pkt 2
17 3 0 6 11+1 +1 - 19 Chksum in Pkt 2+3
18 3 0 6 12 +2 - 20 Chksum in Pkt 3
19 to 28 3 0 6 12 10+2 - 21 to 30 Chksum in Pkt 3
29 4 0 6 12 11+1 +1 31 Chksum in Pkt 3+4
30 4 0 6 12 12 +2 32 Chksum in Pkt 4
31 to 40 4 0 6 12 12 10+2 33 to 42 Chksum in Pkt 4

The first packet may have up to 6 bytes data payload depending on the type and quantity of
control/addressing information supplied.

2.3 Enhanced Data Report Status Request

Figure 2: Enhanced Data Report Status Request Packet

P C Type

MES RTN ID

LES ID
Seq Length

Packet Checksum

Fill

Enhanced Data
Report Status
Request

[Enhanced Data Report Status Request] ::= [MES RTN ID] [LES ID] [Sequence] [Length]

Volume 4: Packet Formats and Usage, Page: 6


Chapter 14: Packet Formats for the Enhanced Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

All fields, other than the checksum and fill are copies of those from the first packet of the data report
for which transfer status is requested.

2.4 Enhanced Data Report Acknowledgement

Figure 3: Enhanced Data Report Acknowledgement Packet

MES FWD ID
Enhanced Data Report
descriptor (MES 1)
Seq Length

Enhanced Data Report


descriptor (MES N)

Enhanced Data Report


Acknowledgement
Packet

[Enhanced data report acknowledgement] ::=[EDR descriptor]N

[EDR descriptor] ::= [MES FWD ID] [Sequence] [Length]

2.4.1 MES ID (24 BITS)


The number allocated by INMARSAT for use in the forward direction, uniquely identifying a particular
mobile earth station.

The sequence and length fields (8 bits) are simply copied from the received enhanced data report for
which the acknowledgement refers.

2.4.2 Sequence (2 bits)


Each time a new enhanced data report is sent, the Sequence number is incremented, modulo-4.
Repeats of previously sent, but unacknowledged, data reports have the same Sequence number (and
length field). The sequence number and length are the same as for the data report to which the
acknowledgement refers.

2.4.3 Length (6 bits)


Defines the length, in bytes, of the data contents of the data report to which the acknowledgement
refers.

Volume 4: Packet Formats and Usage, Page: 7


Chapter 14: Packet Formats for the Enhanced Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN143)

Chapter 15: Packet Formats for the Enhanced Pre-


Assigned Data Reporting Service

Contents

1 Introduction ............................................................................ 3

2 Packet Formats ....................................................................... 3


2.1 Slot Logical Channel Assignment .....................................................................3
Figure 1: LES Slot Logical Channel Assignment Packets - Long and Short Format4
2.1.1 M – MES Requested Assignment (1 bit) ........................................................4
2.1.2 R - Repetition (1 bit) .......................................................................................4
2.1.3 Status (1 bit) – Short Format Only .................................................................4
2.1.4 Status Code (6 bits) – Short Format Only ......................................................4
2.2 Slot Logical Channel Assignment Control/Query ..............................................5
Figure 2: LES Slot Logical Channel Assignment Control/Query Packet..................5
2.2.1 A (1 bit) ..........................................................................................................6
2.2.2 Q (1 bit) ..........................................................................................................6
2.2.3 S (1 bit) ..........................................................................................................6
2.2.4 R - Repetition (1 bit) .......................................................................................6
2.2.5 Control Code (4 bits) ......................................................................................6
2.3 Slot Logical Channel Assignment (LCA) Request .............................................7
Figure 3: MES Slot Logical Channel Assignment Request Packet .........................8
2.3.1 Spare (6 bits) .................................................................................................8
2.4 Slot Logical Channel Assignment Control/Query Response/Acknowledgement8
Figure 4: MES Slot Logical Channel Assignment Query Response /
Acknowledgement Packet .........................................................................................9
2.4.1 Sub-Type (2 bits) ...........................................................................................9
2.4.2 Next Frame (16 Bits) ......................................................................................9
2.4.3 Reason Code (5 bits) .....................................................................................9
2.5 MES Slot Logical Channel Assignment Schedule ........................................... 10

Volume 4: Packet Formats and Usage, Page: 1


Chapter 15: Packet Formats for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN143)

Figure 5: MES Slot Logical Channel Assignment Schedule Packets .................... 11


2.5.1 Count (2 bits) ............................................................................................... 11
2.5.2 Next Frame (14 bits) .................................................................................... 11
2.5.3 Number of Reports Remaining (13 bits) ....................................................... 11
2.6 Enhanced Data Reports .................................................................................. 11
Figure 6: MES Enhanced Data Report Packets .................................................... 12
2.6.1 Sequence (2 bits) ......................................................................................... 12
2.6.2 Length (6 bits) .............................................................................................. 12
2.6.3 A - Acknowledgement Requested (1 bit) ...................................................... 12
2.6.4 R – Pre-Assigned Re-Transmission (1 bit) ................................................... 13
2.6.5 Control Type (3 bits) .................................................................................... 13
2.6.6 Control Length (3 bits) ................................................................................. 13
2.6.7 Control Information ...................................................................................... 13
Table 1: Control Field Formats.............................................................................. 13
2.6.8 Data Report Checksum (16 Bits) ................................................................. 14
2.6.9 Fill ................................................................................................................ 14
2.6.10 Packet Checksum (16 Bits) ........................................................................ 14
2.7 Common Field Descriptions ............................................................................ 14
2.7.1 MES ID (24 BITS) ........................................................................................ 14
2.7.2 LES ID (8 Bits) ............................................................................................. 14
2.7.3 Slot Logical Channel Number (8 bits)........................................................... 14
2.7.4 Start Frame (14 Bits) .................................................................................... 14
2.7.5 Packets per Report (2 Bits) .......................................................................... 15
2.7.6 Slot Number (6 Bits) ..................................................................................... 15
2.7.7 Interval (3 Bits) ............................................................................................. 15
Table 2: Coding for Preset Intervals...................................................................... 15
2.7.8 Duration (5 Bits) ........................................................................................... 15
2.7.9 Signalling Channel (16 Bits) ......................................................................... 16
2.7.10 LES TDM (16 bits) ..................................................................................... 16

Volume 4: Packet Formats and Usage, Page: 2


Chapter 15: Packet Formats for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN143)

1 Introduction
The Enhanced pre-assigned data reporting service is intended for users who need to gather data from
MESs on a regular basis. With the ability to define a constant interval between transmissions from
each MES, pre-assigned TDMA operation of signalling channels can be used instead of the normal
Slotted-Aloha access scheme, thereby allowing more efficient use of the return channel capacity.

Enhanced pre-assigned data reporting introduces an improved management protocol and capabilities
to improve performance and operational flexibility, and ease management. Enhanced data reporting
uses a dedicated management protocol to assign, and control MESs using enhanced pre-assigned
data reporting. It also makes use of the enhanced (unreserved) data report packet formats which offer
improved flexibility and data integrity.

This chapter describes the packet formats that are used; protocols are described in Volume 1.

2 Packet Formats
The following describes the packet formats to be used in Enhanced Pre-assigned Data Reporting.

Two new TDM packets are defined:

- Type 1BH Slot Logical Channel Assignment

- Type 1CH Slot Logical Channel Assignment Control/Query

Three signalling channel packets are defined:

- Type 21H Slot logical channel assignment request

- Type 22H Slot logical channel assignment control/query response/acknowledgement

- Type 23H Slot logical channel assignment schedule

All signalling channel packets, with the exception of the programmed data reports, are sent using
unreserved access. Note that packet type 23H (Slot logical channel assignment schedule) may
require a continuation packet depending on the number of assignment descriptors sent.

2.1 Slot Logical Channel Assignment


This packet is sent either in response to a Slot LCA Request on an LES TDM, or as an LES (user)
originated packet on the NCS Common Channel. Note that the short format Slot Logical Channel
Assignment packet is only sent following a Slot Logical Channel Assignment Request from an MES to
reject or pend the request.

The packet contents size is 12 bytes for the long format and 6 bytes for the short format (total packet
sizes are 16 bytes and 10 bytes respectively).

Packet type 1BH Slot Logical Channel Assignment (medium sized packets)

The format of the Slot Logical Channel Assignment packet is defined below and illustrated in Figure 1.

[Slot LCA] ::= [MES ID] [LES ID] [Slot LCA] or


[MES ID] [LES ID] [Status]

[Status] ::= [Slot Logical Channel Number] [Status] [Status Code]

Volume 4: Packet Formats and Usage, Page: 3


Chapter 15: Packet Formats for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN143)

[Slot LCA] ::= [Slot Logical Channel Number] [Start Frame] [Packets
per Report] [Slot Number][Interval] [Duration]
[Signalling channel]

Figure 1: LES Slot Logical Channel Assignment Packets - Long and Short Format

MES FWD ID MES FWD ID

LES ID LES ID
Slot Logical Channel Number Slot Logical Channel Number
M R R St Code
Start Frame

Pkts Slot Number


Interval Duration

Signalling Channel

LES TDM

Slot Logical Channel Slot Logical Channel


Assignment Assignment

2.1.1 M – MES Requested Assignment (1 bit)


This flag is set to 1 if the assignment is sent in response to an assignment request from an MES.
Otherwise it is set to 0.

2.1.2 R - Repetition (1 bit)


Set to zero for the first transmission of the packet. For any repeat rransmision, this bit is set to one.

2.1.3 Status (1 bit) – Short Format Only


Indicates the status of the request as follows:

0B Request rejected (reason in status code)

1B Request pending (reason in status code)

2.1.4 Status Code (6 bits) – Short Format Only


These use some of the same codes and meanings as for the Request Status Codes of Volume 4,
Chapter 3, section 3.17.2.

00H-04H Not used

05H Requested Service not provided

Volume 4: Packet Formats and Usage, Page: 4


Chapter 15: Packet Formats for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN143)

06H Request in queue (may be used with pending status)

07H Request Barred

08H MES not logged in

09H MES not Commissioned

0AH Waiting TDM Assignment (not applicable)

0BH Illegal Request

0CH LES not in service

0DH Requested service temporarily unavailable

0EH-12H Not used

13H MES has not subscribed to this service

17H Unacceptable parameters in request

18H Requested interval not allowed

19H Requested duration not allowed

20H Assignment limit reached

21H-3FH Not defined

2.2 Slot Logical Channel Assignment Control/Query


This packet is sent from an LES on the NCS Common Channel to control or query currently active (or
programmed) assignments at an MES. Any response is sent directly to the querying LES.

Packet type 1CH Slot Logical Channel Assignment Control/Query

The total packet size = 10 bytes.

The format of the Slot Logical Channel Assignment Control/Query packet is defined below and
illustrated in Figure 2.

Figure 2: LES Slot Logical Channel Assignment Control/Query Packet

Volume 4: Packet Formats and Usage, Page: 5


Chapter 15: Packet Formats for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN143)

MES FWD ID

LES ID
Slot Logical Channel Number
A Q S R Control Code

Slot Logical Channel


Assignment Control/
Query

2.2.1 A (1 bit)
Coded as follows:

0B No response/acknowledge requested

1B Acknowledgement requested (always set for query)

2.2.2 Q (1 bit)
Coded as follows:

0B Control function – ignore S flag

1B Query function

2.2.3 S (1 bit)
Coded as follows:

0B Send assignment details for queried slot logical channel number only

1B Send full assignment schedule

2.2.4 R - Repetition (1 bit)


Set to zero for the first transmission of the packet. For any repeat rransmision, this bit is set to one.

2.2.5 Control Code (4 bits)


Coded as follows:

0H No control action (query function)

1H-2H Not used

3H Suspend active assignment as defined by slot LCN

4H Resume active assignment as defined by slot LCN

5H-7H Not used

Volume 4: Packet Formats and Usage, Page: 6


Chapter 15: Packet Formats for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN143)

8H Terminate assignment as defined by slot LCN

9H - AH Not used

BH Terminate all valid assignments with this LES (slot LCN = 0)

CH-EH Not used

FH Terminate all valid assignments (slot LCN = 0)

Control code FH is only to be used when de-commissioning an MES or resetting following identified
problems. It is expected that this command will only be used in co-ordination with users, other
assigning LES’s and the Inmarsat NOC. The command may only be issued by the Inmarsat NOC.

No control action means that the MES should continue with the assignment without interruption and
that the control packet is sent as a query in order to illicit a response (acknowledgement) indicating
the current assignment for the indicated slot logical channel number.

Suspend means stop transmitting data reports whilst maintaining the assignment. The assignment is
still valid, though inactive, and may resume on reception of a resume command. Assignments are
suspended on reception of a suspend command, on logging out of an Ocean Region, or logging in to
another Ocean Region within which the assignment is not valid.

Resume means make active following a suspend command in the next available assigned slot for the
current valid assignment. If no suspend was previously received the command is ignored.

Terminate means effectively stop reporting and delete the assignment. The assignment is no longer
active or valid.

Active means a valid assignment that has been accepted and stored at the MES and the MES is
currently data reporting in assigned slots. An inactive (but valid) assignment is one that has been
suspended.

Valid means a current assignment that has been accepted, for which an MES may transmit reports.
An invalid assignment is one that has completed, been terminated or for which unacceptable (e.g. out
of range) parameters have been received.

2.3 Slot Logical Channel Assignment (LCA) Request


This is sent from an MES to an LES when a pre-assigned data reporting program is required. It may
also be sent when a change of programming, e.g. a different interval, is required. The required
interval, number of packets per report and duration of the assignment are requested. The LES will
respond with an assignment that closely matches these requirements as far as possible. The
assignment will also include the remaining details such as slot number and signalling channel. The
Slot Logical Channel Assignment (LCA) Request is sent using unreserved access on an LES
signalling channel.

Type 21H Slot logical channel assignment request

The format of the Slot Logical Channel Assignment Request packet is defined below and illustrated in
Figure 3.

[Slot LCA Request] ::= [MES ID] [LES ID] [Slot Logical Channel Number]
[Packets per Report] [Spare] [Interval] [Duration]

Volume 4: Packet Formats and Usage, Page: 7


Chapter 15: Packet Formats for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN143)

Figure 3: MES Slot Logical Channel Assignment Request Packet

P C Type

MES RTN ID

LES ID
Slot Logical Channel Number
Pkts Spare
Interval Duration

Packet Checksum

Fill

Slot Logical Channel


Assignment Request

2.3.1 Spare (6 bits)


Not used. Set to zero.

2.4 Slot Logical Channel Assignment Control/Query Response/Acknowledgement


This packet is sent in response to a Slot Logical Channel Assignment Control/Query, or as an
acknowledgement following a Slot Logical Channel Assignment. It is sent using unreserved access on
an LES signalling channel.

An LES may only send this to MESs having assignments with that LES.

Type 22H Slot logical channel assignment control/query response/acknowledgement

The format of the Slot Logical Channel Assignment Query Response packet is defined below and
illustrated in
Figure 4.

[Slot LCA Query Response] ::= [MES ID] [LES ID] [Slot Logical Channel Number] [R]
[Next Frame] [Packets per Report] [Slot Number]
[Interval] [Duration] [Signalling channel]

Volume 4: Packet Formats and Usage, Page: 8


Chapter 15: Packet Formats for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN143)

Figure 4: MES Slot Logical Channel Assignment Query Response /


Acknowledgement Packet

P C Type P C Type

MES RTN ID MES RTN ID

LES ID LES ID
Slot Logical Channel Number Slot Logical Channel Number
Sub-type Sub-type 0 Reason code
Next Frame
Packet Checksum
Pkts Slot Number
Interval Duration

Signalling Channel
Fill
Packet Checksum

Fill

Slot Logical Channel Slot Logical Channel


Assignment Query Assignment Query
Response/ Response/
Acknowledgement Acknowledgement
(Sub-type accept) (Sub-type reject)

2.4.1 Sub-Type (2 bits)


The value of this field indicates the packet sub-type and remaining packet format as follows:

00B Slot logical channel assignment acknowledgement (accept)

01B Slot logical channel query/control response (accept)

10B Slot logical channel assignment (reject)

11B Slot logical channel query/control (reject)

2.4.2 Next Frame (16 Bits)


An integer encoded as an unsigned binary number with a decimal range of 0 to 9999. This number
defines the absolute frame number for the next scheduled data report transmission (first packet) as
referred to the frame number given in the bulletin board. If the number received is less than the frame
number of the current bulletin board, the next scheduled transmission is the following day.

2.4.3 Reason Code (5 bits)


If the sub-type field indicates an assignment reject or query/control command reject, then only this
field will be present and include a reason code (for the rejection) as follows:

01H Assignment rejected – reason unspecified

Volume 4: Packet Formats and Usage, Page: 9


Chapter 15: Packet Formats for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN143)

02H MES cannot accept new assignments

03H Conflicting assignment

04H LCN already assigned with this LES

11H Query/control rejected – reason unspecified

12H Query/control rejected – no LCN with commanding LES

13H Resume command for active assignment

14H Suspend command for suspended assignment

2.5 MES Slot Logical Channel Assignment Schedule


The MES Slot Logical Channel Assignment Schedule packet is sent in response to a Slot Logical
Channel Assignment Control/Query packet from an LES when details of all valid assignments are
requested (S flag set to 1). It contains basic details of the currently valid assignments held by the MES
(active or inactive). An MES may have up to 4 current assignments. Each assignment descriptor
includes the next scheduled transmission frame for that assignment, the assigned interval and the
number of reports remaining to be transmitted until the end of the assignment. Information concerning
the assigning LES and slot logical channel number, etc. are not sent.

The purpose of the MES Slot Logical Channel Assignment Schedule packet is to allow an LES to
request information concerning an MES’s current assignments in order that any further assignments
are consistent.

If the MES only has two or fewer assignments, then the schedule may be transmitted in a single
packet. If there are more than two assignments, the MES will transmit the schedule in two packets;
the second being a continuation packet using reserved access. The second packet will also include
the MES return ID and the destination LES ID.

Each assignment descriptor is four bytes. The packet checksum immediately follows the last
descriptor with any remaining unused bytes in the packet set as fill (zero) bytes.

Type 23H Slot logical channel assignment schedule

The format of the MES Slot Logical Channel Assignment Schedule packet is defined below and
illustrated in Figure 5.

[Slot LCA Schedule] ::= [MES ID] [LES ID] [Assignment Descriptor]N
(0 ≤ N ≤ 4)

[Assignment Descriptor]::= [Count] [Next Frame] [Interval] [No. of reports remaining]

Volume 4: Packet Formats and Usage, Page: 10


Chapter 15: Packet Formats for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN143)

Figure 5: MES Slot Logical Channel Assignment Schedule Packets

P C Type P C Type

MES RTN ID MES RTN ID

LES ID LES ID
Count Count
Next Frame Next Frame
Assignment
Interval descriptor Interval
No. of reports No. of reports
remaining remaining
Count Count
Next Frame Next Frame

Interval No. of reports Interval No. of reports


remaining remaining

Packet Checksum Packet Checksum

MES Slot Logical MES Slot Logical


Channel Assignment Channel Assignment
Schedule Schedule
(1 of 2) (2 of 2)

2.5.1 Count (2 bits)


Encoded as an unsigned binary number from 00B to 11B. The (up to 4) assignments in the packet are
each numbered successively from 00B to 11B in time order of assignments, e.g. the oldest is the first
assignment (00B) and the newest (most recent) last.

2.5.2 Next Frame (14 bits)


An integer encoded as an unsigned binary number with a decimal range of 0 to 9999. This number
defines the absolute frame number for the next scheduled data report transmission (first packet) of
that assignment as referred to the frame number given in the bulletin board. If the number received is
less than the frame number of the current bulletin board, the next scheduled transmission is the
following day.

2.5.3 Number of Reports Remaining (13 bits)


An integer encoded as an unsigned binary number with a decimal range of 0 to 7000. This is a count
of the number of data report transmissions left until the assignment is completed. Zero is used to
indicate an open-ended assignment.

2.6 Enhanced Data Reports


Enhanced pre-assigned data reporting will make use of enhanced data reporting format packets for
conveying user data.

Type 24H Enhanced Data Report

Volume 4: Packet Formats and Usage, Page: 11


Chapter 15: Packet Formats for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN143)

The format of the Enhanced Data Report packets are defined below and illustrated in Figure 6.

[Enhanced Data Report] ::= [MES ID] [LES ID] [Sequence] [Length] [A] [R] [Control
type] [Control length] [Control information] [Data] or
[Data] or
[Data] [Data Report Checksum]

For the first packet in a Data Reporting sequence, the MES ID, LES ID, Sequence, Length, A, Control
type, Control length and Control field are included. The remaining packet(s) in the sequence may
contain only the [Data] field.

Figure 6: MES Enhanced Data Report Packets

P C Type P C Type P C Type

MES RTN ID

Data
LES ID
Seq Length
A R Ctrl Ctrl len
Data
DR checksum

Additional Control/Data
Fill

Packet
Packet Checksum Packet Checksum
Checksum

First Enhanced Data Second or third Fourth or last


Report Packet Enhanced Data Enhanced Data
Report Packet Report Packet

2.6.1 Sequence (2 bits)


Not used for pre-assigned data reporting. Set to zero. Note however, that this will not be the case if
the data report fails and is re-transmitted using unreserved access.

2.6.2 Length (6 bits)


Defines the length, in bytes, of the data contents of the data report (excludes control information – see
below).

2.6.3 A - Acknowledgement Requested (1 bit)


Not used for pre-assigned data reporting. Set to zero. However, for re-transmissions of lost pre-
assigned data reports using unreserved access, an acknowledgement may be requested.

Volume 4: Packet Formats and Usage, Page: 12


Chapter 15: Packet Formats for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN143)

2.6.4 R – Pre-Assigned Re-Transmission (1 bit)


Set to zero except if retransmitting a lost scheduled pre-assigned data report in which case the bit is
set to one.

2.6.5 Control Type (3 bits)


Defines the type and structure of information provided in the control field. The field is coded as
follows:

0H DNID & member number supplied. Control length = 4H or 6H if a re-transmission of a lost


scheduled pre-assigned data report.

1H Pre-assigned data reporting with a fixed single preset address (associated with the MES
ID and slot logical channel number). Control length = 1H or 3H if a re-transmission of a
lost scheduled pre-assigned data report.

2H – 7H [TBD]

2.6.6 Control Length (3 bits)


Defines the length of the control information field in bytes.

0H – 6H Control information field length in bytes (0 – 6 bytes)

7H Not used

2.6.7 Control Information


The control information filed (with length in bytes defined in the control length field) provides pre-
defined control information in accordance with the control type field.

For 0H the control information consists of the DNID followed by the member number. For pre-
assigned data reporting, the length field is 4 bytes and the last byte is used for the slot logical channel
number.

For 1H the control information consists of the slot logical channel number (1 byte).

If the R bit is set to 1 (indicating that the data report is a re-transmission of a lost pre-assigned data
report), the control length will be increased by two bytes. The last two bytes of this field will then
indicate the frame number of the lost scheduled transmission (2 bytes). If the frame number is greater
than the current frame number then it will refer to the previous day. Table 1 illustrates how the control
field is formatted for the different Control types currently defined.

Table 1: Control Field Formats

Contro Control
Control Field Format R EDR/EPADR
l Type Length
0H 3H [DNID][Member No.] 0 EDR
4H [DNID][Member No.][Slot LCN] 0 EPADR
6H [DNID][Member No.][Slot LCN][Frame No.] 1 EDR (re – Tx)
1H 0H 0 EDR
1H [Slot LCN] 0 EPADR
3H [Slot LCN][Frame No.] 1 EDR (re – Tx)

Volume 4: Packet Formats and Usage, Page: 13


Chapter 15: Packet Formats for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN143)

2.6.8 Data Report Checksum (16 Bits)


A Checksum is calculated as defined in Volume 4, Chapter 1, Fig. 1-1 (Error Detection Coding
Algorithm). This field is only present if the enhanced data report includes two or more packets. The
position of the [checksum] field depends on the number of packets comprising the data report and the
quantity of data as defined in the [length] field. The Data Report Checksum is calculated over all
contents fields of the data report for all packets comprising the data report, including MES ID, LES ID,
etc. If the enhanced data report size is such that it may use a single packet, no data report checksum
is added, i.e. the data report checksum is only added in data reports consisting of two or more
packets. Each packet will always include a packet checksum.

2.6.9 Fill
Fill bits (all zeroes) may be included after the data report checksum and before the packet checksum.
These fill bits are not taken into account when the data report checksum is calculated, but are
included in calculating the packet checksum.

Note: If the last packet checksum indicates an error, it is possible that the errors occurred in the fill
bits and/or packet checksum. A valid data report may still be recovered if the data report checksum is
valid.

2.6.10 Packet Checksum (16 Bits)


A Checksum is calculated as defined in Volume 4, Chapter 1, Fig. 1-1 (Error Detection Coding
Algorithm). The [checksum] field is at the end of the packet.

2.7 Common Field Descriptions

2.7.1 MES ID (24 BITS)


The number allocated by INMARSAT for use in the return direction, uniquely identifying a particular
mobile earth station.

2.7.2 LES ID (8 Bits)


A number uniquely identifying a particular land earth station.

2.7.3 Slot Logical Channel Number (8 bits)


Each concurrent assignment at an MES will have a unique slot logical channel number. In contrast to
messaging, the slot logical channel numbers given for pre-assigned data reporting assignment do not
have to be unique between MES’s. The slot LCN field is used as a count of the assignments made to
an individual MES (modulo-255) by an LES as an aid to synchronisation and control.

Slot LCN values are assigned modulo-255: 1≤LCN≤255. Value 00H is reserved.

If the MES is requesting a new assignment, the slot LCN number will be set to the last (or current) slot
LCN + 1. If the MES is requesting a first assignment (i.e. no previous assignment has been received
from that LES), then the slot LCN will be set to 00H.

2.7.4 Start Frame (14 Bits)


An integer encoded as an unsigned binary number with a decimal range of 0 to 9999. This number
defines the absolute frame number for the start of the assignment (transmission of the first packet of
the first data report) as referred to the frame number given in the bulletin board. If the number
received is greater than the frame number of the current bulletin board, the assignment starts in the
current day. If the received number is less, then the assignment starts in the following day.

Volume 4: Packet Formats and Usage, Page: 14


Chapter 15: Packet Formats for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN143)

2.7.5 Packets per Report (2 Bits)


Encoded as follows:

00B 1 packet per report

01B 2 packets per report

10B 3 packets per report

11B 4 packets per report

2.7.6 Slot Number (6 Bits)


The slot number within the assigned frame encoded as an unsigned binary number. The integer has a
decimal range of 1 to 14 for first generation satellite operation and 1 to 28 for second generation.

2.7.7 Interval (3 Bits)


This field defines the interval between data reporting transmissions as a frame count. The values are
preset according to Table 2.

Table 2: Coding for Preset Intervals

Number
Interval value Interval (frames) Interval (time)
per day
0 10000 24 hours 1
1 5000 12 hours 2
2 2500 6 hours 4
3 1250 3 hours 8
4 500 1 hour, 12 mins 20
5 250 36 mins 40
6 125 18 mins 80
7 100 14 mins, 24 secs 100

The minimum interval is 100 frames.

Example: If the start frame number is 9521 and the interval is 500 frames (4H), transmissions occurs
in frames 9521, 9921, 421, 921, 1421, 1921, 2421, 2921 ...etc.

2.7.8 Duration (5 Bits)


This field defines the duration for which the assignment is requested. It is given as a count of the
number of data reports which are required to be transmitted.

[Duration] ::= [x100 Multiplier] [x10 Multiplier] [Unit Count]

1–7 Increments of 1

10 – 70 Increments of 10

100 – 700 Increments of 100

Volume 4: Packet Formats and Usage, Page: 15


Chapter 15: Packet Formats for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN143)

1000 – 7000 Increments of 1000

[Unit Count] is a three bit unsigned binary number representing values of 0 – 7. The two multiplier
flags allow the duration to be extended with an accompanying loss in resolution. Each flag is one bit
and when set (i.e. =1), indicates that [Unit Count] should be multiplied by 10, 100 or 1000. For
example, the binary value 10010 would indicate a duration of 200 reports. The all zeroes duration is
used to indicate an open ended assignment, i.e. no duration limit.

The actual time duration of the assignment in seconds is:

[Duration value] * [Interval value -1] * 8.64

2.7.9 Signalling Channel (16 Bits)


The satellite frequency code of the signalling channel to be used for the assignment.

2.7.10 LES TDM (16 bits)


This field indicates the satellite channel being used for the LES TDM to which the MES must tune
when sending pre-assigned data reports. It is the TDM channel with which the signalling channel is
associated.

[LES TDM] ::= [Satellite Frequency Code] or


[Demand Assigned]

Demand assigned is not applicable in this context, since LES’s operating TDM’s in demand assigned
cannot support enhanced pre-assigned data reporting.

Volume 4: Packet Formats and Usage, Page: 16


Chapter 15: Packet Formats for the Enhanced Pre-Assigned Data Reporting Service
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 1: Introduction

Contents

1 Introduction ............................................................................ 2

2 Constants Referred to in This Volume ..................................... 2


2.1 Chapter 2 (LES SDL) ........................................................................................2
2.2 Chapter 3 (MES SDL) .......................................................................................3
2.3 Chapter 4 (NCS SDL) .......................................................................................3

3 Structure Information .............................................................. 4

4 System SDL ............................................................................. 8


Figure 1: System Inmarsat_C, Sheet 1 of 6 ............................................................9
Figure 1: System Inmarsat_C, Sheet 2 of 6 .......................................................... 10
Figure 1: System Inmarsat_C, Sheet 3 of 6 .......................................................... 11
Figure 1: System Inmarsat_C, Sheet 4 of 6 .......................................................... 12
Figure 1: System Inmarsat_C, Sheet 5 of 6 .......................................................... 13
Figure 1: System Inmarsat_C, Sheet 6 of 6 .......................................................... 14

Volume 5: SDL, Chapter 1: Introduction Page: 1


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
This volume contains diagrams which illustrate the Inmarsat-C message protocols in functional
Specification and Description Language (SDL), which is an international standard specified by the
CCITT (see CCITT Blue Book Recommendation Z.100 and Annexes A to F).

These SDL diagrams illustrate the protocol elements only and should not be interpreted as
implementation design documents. The diagrams are not strict SDL in that blocks and processes,
rather than channels, are used to identify the sources and destinations of signals and no distinction
has been made between block and process where there is one process per block. In addition, certain
features have been omitted in order to simplify the description. These include:

(a) details of interactions outside the protocol domain such as the message handling system on the
LES and the input/output devices (DTE or indicators) on the MES;

(b) obvious parameters such as earth station identifiers, frequency and slot numbers;

(c) the algorithms and signals used for congestion control on the LESs;

(d) the choice by the LES of reserved slots in the signalling and message channels;

(e) detection of unique words, bulletin boards, and so on. Also omitted are timing processes at the
framing level; and

(f) interactions between different activities — for example, a distress alert occurring during a
message transfer.

Structure information for the system is given in section 3 of this chapter. Block/process diagrams and
SDLs for the LES, MES, and NCS are given in Chapters 2, 3, and 4 respectively. The SDL for the
polling protocol (LES) is in Chapter 5.

Detailed SDL diagrams are provided at two levels: the channel level and the message service level.

At the channel level the operation of the signalling channel is described in three diagrams. Chapter 3 -
Figure 6 gives the operation at the MES, Chapter 2 - Figure 5 details the states of a single multislot as
seen at a land earth station, and Chapter 2 - Figure 6 gives the operation of the overall slot control at
a land earth station for each MES signalling channel.

At the message service level, Chapter 3 - Figure 5 gives the MES actions, Chapter 2 - Figure 3 and
Chapter 4 - Figure 3 detail the LES and NCS actions as they affect a particular MES (there is one
such process for each MES).

Chapter 4 - Figre 2 gives the SDL for the NCS process which handles demand assignment of TDM
channels.

2 Constants Referred to in This Volume


This Section contains constants that are referred to in other chapters of this volume. They are liable to
change in the light of operational experience, so it is recommended that all of these values are
implemented in such a way that they can be altered readily.

2.1 Chapter 2 (LES SDL)

LES MES Control (Chap 2, Figure 3)

Chap 2, Sect 2.3.3: MaxA: 3


MaxL: 3

Volume 5: SDL, Chapter 1: Introduction Page: 2


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

MaxM: 3
MaxN: 3
MaxPV: 3
MaxRC: 5
MaxRR: 3
MaxS: 3
T11: T0 + 70 secs
T12: T33 + T15/MaxL
T14: 45 secs
T15: [MaxC x (Randomizing Interval +3)] x Frame duration
T16: Calculated end of message+T33
T17: Time offset to start of Reservation + duration of Reservation
(Note: T17 x (MaxRR+1) should be approximately 5 mins)
T18: T15
T19: T15 + T30
T23: 600 secs
T32: 45 secs
T33: 25 secs
T34: 5 mins

LES Multislot Control (Chap 2, Figure 5)

Chap 2, Sect 2.5.3 MaxP: MaxF

2.2 Chapter 3 (MES SDL)

MES Process Control (Chap 3, Figure 5)

Chap 3, Sect 2.3.3 MaxCC: 4


MaxCD: 4
MaxPVT: 3
N_Ack: 10
T0: 60 secs
T1: 20 mins
T3: T0
T4 60 secs
T6: T0 + 5 mins
T30: 2 mins
T31: 2 mins

Signalling Channel Control (Chap 3, Figure 6)

Chap 3, Sect 2.4.3: MaxA: 3


MaxC: 9
MaxD: 25
MaxE: 5
MaxF: 2

2.3 Chapter 4 (NCS SDL)

NCS MES Control (Chap 4, Figure 3)

Chap 4, Sect 2.3.3 T20: 20 mins


T21: 50 secs

Volume 5: SDL, Chapter 1: Introduction Page: 3


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

T22 T12 + 12 secs


T35: 30 secs

3 Structure Information
Throughout this Volume, the SDL pages have individual figure numbers arranged as follows:

System Figure #[D]

Block/Process/Macro Figure #[D]

Procedure Figure #z[D]

Where D is the page number for that diagram. In the top right hand corner, within the border of each
figure is the figure number repeated as A.b.c[D](E). E is the total number of pages for that diagram
regardless of its hierarchical level, i.e. each individual figure page is D within the diagram of E pages,
be it system, block, process or procedure.

The Structure Information for the System is as follows:

System INMARSAT_C

Chap 1, Figure 1[1]


Chap 1, Figure 1[2]
Chap 1, Figure 1[3]
Chap 1, Figure 1[4]
Chap 1, Figure 1[5]
Chap 1, Figure 1[6]

Block LES

Chap 2, Figure 1[1]


Chap 2, Figure 1[2]

Process Demand_Assignment

Chap 2, Figure 2[1]

Process MES_Control

Chap 2, Figure 3[1]


Chap 2, Figure 3[2]
Chap 2, Figure 3[3]
Chap 2, Figure 3[4]
Chap 2, Figure 3[5]
Chap 2, Figure 3[6]
Chap 2, Figure 3[7]
Chap 2, Figure 3[8]
Chap 2, Figure 3[9]
Chap 2, Figure 3[10]

Procedure Announce

Chap 2, Figure 3a[1]


Chap 2, Figure 3a[2]
Chap 2, Figure 3a[3]
Chap 2, Figure 3a[4]

Volume 5: SDL, Chapter 1: Introduction Page: 4


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Procedure Anomaly_SC

Chap 2, Figure 3b[1]

Procedure Distress

Chap 2, Figure 3c[1]

Procedure From_MES_Message_L (LES)

Chap 2, Figure 3d[1]


Chap 2, Figure 3d[2]
Chap 2, Figure 3d[3]

Procedure Test

Chap 2, Figure 3e[1]


Chap 2, Figure 3e[2]
Chap 2, Figure 3e[3]
Chap 2, Figure 3e[4]
Chap 2, Figure 3e[5]

Procedure To_MES_Message_L (LES)

Chap 2, Figure 3f[1]


Chap 2, Figure 3f[2]
Chap 2, Figure 3f[3]
Chap 2, Figure 3f[4]

Procedure Enhanced Data Report

Chap 2, Figure 3g[1]

Process MES_Sig

Chap 2, Figure 4[1]

Process Multislot_Control

Chap 2, Figure 5[1]


Chap 2, Figure 5[2]

Procedure Anomaly_MC

Chap 2, Figure 5a[1]

Process Slot_Control

Chap 2, Figure 6[1]


Chap 2, Figure 6[2]
Chap 2, Figure 6[3]

Procedure Anomaly_SL

Chap 2, Figure 6a[1]

Procedure Convert_Data_to_Signal

Volume 5: SDL, Chapter 1: Introduction Page: 5


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chap 2, Figure 6b[1]

Process TDM_Generator

Chap 2, Figure 7[1]

Macro Idle_Wait

Chap 2, Figure 8[1]

Macro Clear_Idle_Wait

Chap 2, Figure 9[1]

Block MES

Chap 3, Figure 1[1]


Chap 3, Figure 1[2]

Process LES_NCS_Sig

Chap 3, Figure 2[1]

Process MES_MSG

Chap 3, Figure 3[1]

Process MES_Sig_O_P

Chap 3, Figure 4[1]


Chap 3, Figure 4[2]

Process Process_Control

Chap 3, Figure 5[1]


Chap 3, Figure 5[2]
Chap 3, Figure 5[3]

Procedure Data_Report

Chap 3, Figure 5a[1]

Procedure Forced_Clear

Chap 3, Figure 5b[1]

Procedure From_MES_Message_M (MES)

Chap 3, Figure 5c[1]


Chap 3, Figure 5c[2]
Chap 3, Figure 5c[3]

Procedure Login

Chap 3, Figure 5d[1]

Procedure Logout

Chap 3, Figure 5e[1]

Volume 5: SDL, Chapter 1: Introduction Page: 6


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Procedure MES_Distress

Chap 3, Figure 5f[1]


Chap 3, Figure 5f[2]

Procedure MES_Test

Chap 3, Figure 5g[1]


Chap 3, Figure 5g[2]
Chap 3, Figure 5g[3]

Procedure Poll

Chap 3, Figure 5h[1]

Procedure Test_Setup

Chap 3, Figure 5i[1]

Procedure To_MES_Message_M (MES)

Chap 3, Figure 5j[1]


Chap 3, Figure 5j[2]

Procedure Data Report with Ack

Chap 3, Figure 5k[1]

Procedure Enhanced Data Report

Chap 3, Figure 5l1]

Process Sig_Ch_Control

Chap 3, Figure 6[1]


Chap 3, Figure 6[2]
Chap 3, Figure 6[3]
Chap 3, Figure 6[4]

Procedure Anomaly_SCH

Chap 3, Figure 6a[1]

Procedure Select_Next_Frame_Offset

Chap 3, Figure 6b[1]

Macro Timeout

Chap 3, Figure 7[1]

Process Receive LES TDM Descriptor

Chap 3, Figure 8[1]

Block NCS

Chap 4, Figure 1[1]

Volume 5: SDL, Chapter 1: Introduction Page: 7


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chap 4, Figure 1[2]

Process NCS_Demand_Assign

Chap 4, Figure 2[1]


Chap 4, Figure 2[2]

Process NCS_MES_Control

Chap 4, Figure 3[1]


Chap 4, Figure 3[2]
Chap 4, Figure 3[3]
Chap 4, Figure 3[4]
Chap 4, Figure 3[5]
Chap 4, Figure 3[6]
Chap 4, Figure 3[7]
Chap 4, Figure 3[8]
Chap 4, Figure 3[9]
Chap 4, Figure 3[10]
Chap 4, Figure 3[11]

Procedure NCS_Announce

Chap 4, Figure 3a[1]

Procedure NCS_Distress

Chap 4, Figure 3b[1]

Procedure NCS_Login

Chap 4, Figure 3c[1]

Polling

Process Closed_Network_Control

Chap 5, Figure 1[1]

4 System SDL
The SDL for the INMARSAT-C System is shown in Figure 1. This comprises one instance only of
each of the blocks; NCS, LES and MES.

Volume 5: SDL, Chapter 1: Introduction Page: 8


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: System Inmarsat_C, Sheet 1 of 6

Syste m INMARS AT_C 1[1](6)

SIG NAL /* INMARSAT_C SATEL LITE SI GNAL S */ SIGNAL /* NCS O UTPUT SIGNALS */
Ack_Requ est, Alarm,
Ann ouncemen t(INTEGER), Operato r_Alarm,
Cancel_ An noun ceme nt, PVT_ Result,
Cle ar, Sta tus_Idle_ Fro m,
Lo gical_Chann el_As sign ment(INTEGER) , Un expected_L ES;
Ack,
Distress_ Alert_Ack ,
Log in_Ack(INTEG ER),
Lo gout_Ac k,
LES_For ced_Cle ar(INTEGER), SIGNAL /*LES INPUT SIG NAL */
Distress_ Test_ Req uest, To_MES_Me ssa ge;
Confirma tion ,
Me ssag e_ Status,
M essage_ Data ,
Reque st_Sta tu s(INTEG ER),
Te st_Result(INTEG ER), SIG NAL /* L ES O UTPUT SIGNALS */
Registration(INTEGER), Co nges tion_ Clea red,
Commission_Reque st, C annot_ De liver(INTEGER) ,
MES_Statu s(INTEG ER), C annot_ Announce(INTEG ER),
MES_Statu s_Request, D eliver ed_O K,
M ES_ Stat us_Requ est_ An nou nceme nt, Ca nnot_ Po ll(INTEG ER),
TDM_ Re le ase_Ack, Po ll_Success,
TDM_Relea se , Infor m_RCC;
TDM_ Re lease_R eques t,
TDM_Requ est(INTEG ER),
TDM_ Req uest_ Re sponse(INTEG ER),
Annou ncement_Resp on se,
Assignm ent_Resp onse , SIG NAL /*MES INPUT SIG NALS*/
Distress_Alert, Fro m_MES_M essa ge,
Distre ss_Alert_Test , O pera tor_Resp onse ,
M ES_ Forced _Cle ar(INTEGER), Force d_Clear_Reque st;
Lo gin_ Req ues t,
Lo gout_ Req uest,
M essage_ Sta tus_ Req uest,
Test_Request, SIG NAL /* M ES O UTPUT SI GNALS */
Te st_Result_Ack, C all_Pend ing(INTEGER),
Tran sfe r_Sta tus_Requ est(INTEGER), Ca ll_Rejected(INTEGER) ,
Assign ment_ Req uest, Fro m_MES_Failed(INTEG ER),
M essage_ Pa cket, To_M ES_ Failed(INTEGER),
Individ ua l_ Po ll_ Req uest, D ata_Repo rt_ Se nt,
Individua l_Poll, MES_ Sig_Failure(INTEG ER),
Data _Report(I NTEGER), Succe ssful_L ogin ,
M ES_ Sta tus_Chan ge(INTEG ER,INTEG ER,INTEG ER), Succe ssful_L ogo ut,
Poll_Requ est(INTEG ER), Inpu t_ Req uest,
Network_Upda te, Test_ Failure(INTEGER) ,
SCD(INTEGER,INTEG ER); D istress_Ale rt_ OK,
Distress_Alert_un su ccessfu l,
Awaiting_ Message_ Transfer(I NTEGER),
Force d_Clear(INTEG ER),
Timeou t,
Sta tus(INTEGER);

Volume 5: SDL, Chapter 1: Introduction Page: 9


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: System Inmarsat_C, Sheet 2 of 6

Syste m INMARS AT_C 1[2](6)

SIG NALLI ST NCS_CC_L IST= SIGNALLIST TDM_LES_L IST=


Annou ncement, Ack_Requ est,
Clear, Cle ar,
Distress_ Alert_Ack, L ogic al_Chan nel_Assig nment,
Lo gin_Ack, Ack,
Lo gou t_Ac k, Distress_ Alert_Ack,
LES_Fo rced_Clear, LES_Fo rced_Clear,
Confirmation , Distress_ Tes t_ Req uest,
Me ssa ge_ Status, M ess age_ Da ta ,
Requ est_ St atus, M ess age_ Pa ck et,
I ndividua l_Poll, M obile_Ba se _Poll,
Poll_Request, /*fo r CN13 2 co mpliant LES */
Network_Upda te; M obile _Mob ile _Poll,
/*fo r CN1 32 compliant LES*/
Requ est_ Status,
SIGNALLIST NCS_ SIG_L IST= Tes t_Result;
Distress_ Alert,
Distre ss_ Alert_Test,
MES_Fo rced_Cle ar, SIGNALLIST LES_SIG _LIST=
Lo gin_ Req uest, Ack,
Lo gou t_ Req uest, Annou ncement_Resp on se,
M essag e_Sta tus_ Req ues t, Ass ignm ent_Resp onse ,
Test_Request, Data_Rep ort ,
Tra nsfe r_Sta tu s_ Req uest, /*Distress_Ale rt, */
Assign ment_ Req uest , Distre ss_Alert_Test,
Data_Rep ort; MES_Fo rce d_Clear ,
M ess age_ Sta tus_ Req uest,
Te st_Result_Ack,
SIGNALLIST NCS_I SL_LIST= Tra nsfe r_Sta tu s_ Req uest,
LES_Fo rced_Clear, M obile_ Mobile_ Data_ Rep ort,
MES_Fo rced_Cle ar, /* for CN1 32 comliant L ES */
Confirmation , Assign ment_ Req uest;
Me ssa ge_ Status,
Requ est_ St atus,
Test_Result, SIG NALLIST L ES_ISL_LIST=
Distress_ Alert_Ack, Registration ,
Distress_ Alert, Registration _Up date_ Req uest.
I ndividua l_Poll, /*for CN13 1 Complia nt LES*/
M ES_ Stat us, Commis sion_Reque st,
M ES_Sta tus_Chan ge , Distress_Alert,
MES_Statu s_Requ est, Distress_ Alert_Ack,
M ES_Stat us_Requ est_ An nou nceme nt, M ES_ Status,
Cancel_ An nou nceme nt; MES_Statu s_Request,
Assign ment_ Req uest,
SIG NALLI ST NCS_ISL_LIST2 = M ess age_ Sta tus_ Req uest,
TDM_Rele ase , Tes t_Request,
TDM_ Req uest; MES_Fo rce d_Clear ,
Data_Rep ort ;

SIGNALLIST LES_ISL _LIST2=


TDM _Re le as e_Ack,
TDM _Re leas e_Request,
TDM_ Re quest_Re spon se;

SIG NALL IST M SG_L IST=


M ess age_ Pa ck et;

Volume 5: SDL, Chapter 1: Introduction Page: 10


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: System Inmarsat_C, Sheet 3 of 6

Syste m INMARS AT_C 1[3](6)

SIGNALLI ST M ES_ INPUT_LIST= SIGNAL LIST LES_INPUT_L IST=


Lo gin_ Req uest, To_MES_M essa ge ,
Fro m_ MES_Mes sag e, Messa ge_status,
M essag e_Sta tus_ Req ues t, Individ ual_ Po ll_Request;
Distress_ Alert,
Test_Request,
Data_Rep ort,
For ced_Cle ar_ Re quest,
Lo gou t_ Req uest,
O pera to r_Re spon se ;

SIGNALLIST MES_O UTPUT_L IST= SIGNALLIST LES_O UTPUT_LIST=


M essage _Da ta , Me ssage_Packet,
Succe ssful_L ogin , Delivered_ OK,
Succe ssful_L ogout , Cann ot_De liv er,
Confirmation , Cann ot_Anno unce ,
Me ssa ge_ Status, Cann ot_Poll,
Status, Po ll_Su ccess ,
Awaiting_M essa ge_ Tran sfer , Dat a_Report,
Fo rced_Clear, Me ssage_Sta tu s_ Req uest ,
Timeout, Inform_RCC;
Call_ Pendin g,
Call_ Re jected,
Fro m_ MES_Failed,
To_M ES_Faile d,
M ES_ Sig _Failure,
Dat a_Report_Sent , SIG NALLIST NCS_O UTPUT_L IST =
Poll_Request, Test_ Res ult,
I nput_ Req uest , PVT_ Res ult,
Test_Result, Alarm,
Test_Failure, Opera tor_Alarm,
Distress_Alert_O K, MES_Sta tus_Chan ge;
Distress_ Alert_un successful;

Volume 5: SDL, Chapter 1: Introduction Page: 11


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: System Inmarsat_C, Sheet 4 of 6

Syste m INMARS AT_C 1[4](6)

/* All du rations in s econds */


SYNO NYM Frame_ Lengt h Dur ation = 8.64 ;
SYNO NYM Slot_Per iod Duration = F ram e_Leng th/28 .0 ;
SYNO NYM T0 Duratio n = 6 0.0;
SYNO NYM T1 Dura tion = 20.0*60 .0 ;
SYNO NYM T3 Duratio n = 6 0.0;
SYNO NYM T4 Duratio n = 6 0.0;
SYNO NYM T6 Duration = T0 +5.0*60.0 ;
SYNO NYM T30 Duration = 2.0*60.0 ;
SYNO NYM T3 1 Dura tion = 120 .0;
SYNO NYM T32 Duration = 45.0 ;
SYNO NYM T11 Duration = T0+70.0 ;
SYNO NYM T12 Duration = T33+(T15/3 .0) ; /* T33 +(T15/MaxL) */
SYNO NYM T14 Duration = 45.0 ;
SYNO NYM T1 5 Dura tion = Frame_L eng th *3 6.0; /* MaxC*(Retran smission Period+3) */
SYNO NYM T16 Du rat ion = Frame_L ength *2. 0+T3 3; /* Ca lculated en d of messa ge+T 33 */
SYNO NYM T17 Dura tion = 75; /* Time offset to start of Reservation */
/* + duration of Rese rvation (=300/(MaxRR+1 )*/
SYNO NYM T18 Duration = T15;
SYNO NYM T19 Duration = T15+120 .0 ;
SYNO NYM T33 Duration = 25.0 ;
SYNO NYM T34 Duration = 5.0*60.0 ;
SYNO NYM T2 0 Dura tion = 20.0*60 .0;
SYNO NYM T21 Duration = 50.0 ;
SYNO NYM T22 Du rat ion = T12+12.0 ;
SYNO NYM T35 Duration = 30.0 ;
SYNO NYM Ta Dura tion = 30.0*60 .0 ; /* Set by NCS Op erator */

SYNO NYM Nil Integer = 0;


SYNO NYM O _K Integ er = 1 ;
SYNONYM Fa il Integ er = 2 ;
SYNO NYM O th er Integ er = 3 ;
SYNONYM Idle Integ er = 4 ;
SYNO NYM Busy Integ er = 5;
SYNO NYM Barred In teger = 6;
SYNO NYM Real_Distress Integ er = 7 ;
SYNO NYM Test Integ er = 8 ;
SYNO NYM Pend ing Integer = 9;
SYNO NYM Rejected Intege r = 10 ;
SYNO NYM Data_Repo rting Integer = 11;
SYNO NYM Not_In_O R Intege r = 12 ;
SYNO NYM Unres erved I ntege r = 13 ;
SYNO NYM Reserved Int eger = 14;
SYNONYM NCS Intege r = 15 ;
SYNO NYM LES Integer = 16;
SYNO NYM MES_Sig I nteger = 17;
SYNO NYM MES Inte ger = 17 ;
SYNO NYM Forced_Clea r In teger = 18;
SYNO NYM W aitin g_For_Ac k Integer = 19;
SYNONYM W aitin g_For_Ac kno wle dgem ent Intege r = 19 ;
SYNO NYM W aitin g_For_Clea r I ntege r = 20 ;
SYNO NYM W aitin g_For_Message Int eger = 21;
SYNO NYM W aitin g_For_Te st_Results Int eger = 22;

Volume 5: SDL, Chapter 1: Introduction Page: 12


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: System Inmarsat_C, Sheet 5 of 6

System INMARS AT_C 1[5](6)

SYNONYM MaxCC Integ er = 4 ;


SYNONYM MaxCD Integ er = 4 ;
SYNONYM Ma xPVT Int eger = 3;
SYNONYM Ma xA Int eger = 3;
SYNONYM M axC Integer = 9;
SYNONYM Ma xD Integer = 25;
SYNONYM Ma xE Int eger = 5;
SYNONYM M axF Integ er = 2 ;
SYNONYM M axL Integ er = 3 ;
SYNONYM Ma xM Integ er = 3 ;
SYNONYM M axN Integer = 3;
SYNONYM Ma xPV Integer = 3;
SYNONYM Ma xS Int eger = 3;
SYNONYM Ma xP Int eger = 2;
SYNONYM M ax_Test_Res_ Ctr Integ er = 3 ;
SYNONYM MaxRC Integ er = 5 ;
SYNONYM MaxRR Integ er = 3 ;
SYNONYM TDM_Lo st_M ax = 4 ;
SYNONYM N_ACK=10 ;
/*fo r CN132 compliant MES*/

SYNONYM Cong ested Intege r = 23 ;


SYNONYM Conge stion Intege r = 23 ;
SYNONYM PV Intege r = 24 ;
SYNONYM To_ MES Intege r = 25 ;
SYNONYM Fro m_MES Intege r = 26 ;
SYNONYM Anno uncement_ Respon se In teger = 27;
SYNONYM Assignm ent_Response Inte ger = 2 8;
SYNONYM Assignme nt_Reque st Int eger = 29;
SYNONYM Test_Reque st Int eger = 30;
SYNONYM Not_Commissio ned In teger = 31;
SYNONYM Deco mmissio ned Integer = 32;
SYNONYM Idle_Anno unce ment_In_Qu eue Integer = 33;
SYNONYM Busy_Anno unce ment_I n_Qu eue Int eger = 34;
SYNONYM W aiting_For_ Distress Intege r = 35 ;
SYNONYM W aiting_For_ Distre ss _Test I ntege r = 36 ;
SYNONYM Anno uncement Intege r = 37;
SYNONYM No_TDM_ Assignment I ntege r = 38;
SYNONYM Pen ding_ Re que st_In_Q ueue Intege r = 39 ;
SYNONYM Conf irmation Intege r = 40 ;
SYNONYM Poll Integ er = 41 ;
SYNONYM Tra nsf er_Status_ Re quest Intege r = 42 ;
SYNONYM O K Bo olea n = True ;
SYNONYM Yes Boo lean = True ;
SYNONYM No Boolean = False;

Volume 5: SDL, Chapter 1: Introduction Page: 13


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: System Inmarsat_C, Sheet 6 of 6

System IN MARS AT_C 1[6](6)

MES _O (NCS_CC_LIST)
( MES_O UTPUT_L IST) NCS _C C

MES

MES _I NCS_ SIG


(MES_INPUT_ LIST) (NCS_ SIG_L IST)

LES_ SIG
(LES_SIG_ LIST),
MS G Dis tress_Alert
(MSG_L IST)
(TDM_ LES_LIST), LES_ISL
SCD
(LES_ISL_LIST),
L ES_TD M (LES_ISL_LIST2 )

LES NC S

N CS_ISL NCS _O
(NCS_ISL_ LIST), (NCS_O UTPUT_L IST)
(NCS_ISL _LIST2)

LES _O LES _I

(L ES_ OUTPUT_LIST), (LES_INPUT_L IST)


Congestio n_Cleared

Volume 5: SDL, Chapter 1: Introduction Page: 14


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Chapter 2: Land Earth Station SDL

Contents

1 Introduction ............................................................................ 4

2 Land Earth Station SDL ........................................................... 4


2.1 Process and Blocks ..........................................................................................4
2.2 Signals ..............................................................................................................4
2.3 LES MES Control (Figure 3) .............................................................................6
2.3.1 Variables ........................................................................................................6
2.3.2 Timers ............................................................................................................6
2.3.3 Constants .......................................................................................................7
2.4 LES MES Signalling Channel Control (Figure 4) ...............................................8
2.4.1 Variables ........................................................................................................8
2.4.2 Timers ............................................................................................................8
2.4.3 Constants .......................................................................................................8
2.5 LES Multislot Control (Figure 5) ........................................................................8
2.5.1 Variables ........................................................................................................8
2.5.2 Timers ............................................................................................................8
2.5.3 Constants .......................................................................................................8
2.6 LES Slot Control (Figure 6) ...............................................................................8
2.6.1 Variables ........................................................................................................8
2.6.2 Timers ............................................................................................................9
2.6.3 Constants .......................................................................................................9

3 Block LES SDL ........................................................................ 9


Figure 1: Block LES, Sheet 1 of 2 ......................................................................... 11
Figure 1: Block LES, Sheet 2 of 2 ......................................................................... 12
Figure 2: Process Demand_Assignment ............................................................... 13
Figure 3: Process MES_Control, Sheet 1 of 10 .................................................... 14
Figure 3: Process MES_Control, Sheet 2 of 10 .................................................... 15

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 1
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3: Process MES_Control, Sheet 3 of 10 .................................................... 16


Figure 3: Process MES_Control, Sheet 4 of 10 .................................................... 17
Figure 3: Process MES_Control, Sheet 5 of 10 .................................................... 18
Figure 3: Process MES_Control, Sheet 6 of 10 .................................................... 19
Figure 3: Process MES_Control, Sheet 7 of 10 .................................................... 20
Figure 3: Process MES_Control, Sheet 8 of 10 .................................................... 21
Figure 3: Process MES_Control, Sheet 9 of 10 .................................................... 22
Figure 3: Process MES_Control, Sheet 10 of 10 .................................................. 23
Figure 3(a): Procedure Announce, Sheet 1 of 4.................................................... 24
Figure 3(a): Procedure Announce, Sheet 2 of 4.................................................... 25
Figure 3(a): Procedure Announce, Sheet 3 of 4.................................................... 26
Figure 3(a): Procedure Announce, Sheet 4 of 4.................................................... 27
Figure 3(b): Procedure Anomaly_SC .................................................................... 28
Figure 3(c): Procedure Distress ............................................................................ 29
Figure 3(d): Procedure From_MES_Message_L, Sheet 1 of 3 ............................. 30
Figure 3(d): Procedure From_MES_Message_L, Sheet 2 of 3 ............................. 31
Figure 3(d): Procedure From_MES_Message_L, Sheet 3 of 3 ............................. 32
Figure 3(e): Procedure Test, Sheet 1 of 5 ............................................................. 33
Figure 3(e): Procedure Test, Sheet 2 of 5 ............................................................. 34
Figure 3(e): Procedure Test, Sheet 3 of 5 ............................................................. 35
Figure 3(e): Procedure Test, Sheet 4 of 5 ............................................................. 36
Figure 3(e): Procedure Test, Sheet 5 of 5 ............................................................. 37
Figure 3(f): Procedure To_MES_Message_L, Sheet 1 of 4 .................................. 38
Figure 3(f): Procedure To_MES_Message_L, Sheet 2 of 4 .................................. 39
Figure 3(f): Procedure To_MES_Message_L, Sheet 3 of 4 .................................. 40
Figure 3(f): Procedure To_MES_Message_L, Sheet 4 of 4 .................................. 41
Figure 3(g): Procedure Enhanced_Data_Report ................................................... 42
Figure 4: Process MES_Sig .................................................................................. 43
Figure 5: Process Multislot_Control, Sheet 1 of 2 ................................................. 44
Figure 5: Process Multislot_Control, Sheet 2 of 2 ................................................. 45

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 2
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5(a): Procedure Anomaly_MC ................................................................... 46


Figure 6: Process Slot_Control, Sheet 1 of 3 ........................................................ 47
Figure 6: Process Slot_Control, Sheet 2 of 3 ........................................................ 48
Figure 6: Process Slot_Control, Sheet 3 of 3 ........................................................ 49
Figure 6(a): Procedure Anomaly_SL ..................................................................... 50
Figure 6(b): Procedure Convert_Data_To_Signal ................................................. 51
Figure 7: Process TDM_GEN ............................................................................... 52
Figure 8: Macrodefinition Idle_Wait ....................................................................... 53
Figure 9: Macrodefinition Clear_Idle_Wait ............................................................ 54

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 3
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

1 Introduction
A block/process diagram illustrating the LES functions is given in Figure 1. The illustrations which
follow it are SDLs for the Land Earth Station: they should be used with the explanatory notes given in
Section 2.

2 Land Earth Station SDL

2.1 Process and Blocks


1. Demand Assignment Handles demand assignment of LES channels (TDMs).

2. LES MES control One instance for each MES. Handles protocols for messaging
and other services (see Section 2.3 and Figure 3)

3a. MES Signalling I/P One instance per signalling channel input. Handles input from
these channels.

3b. LES Multislot Control One instance per multislot per signalling channel. Handles
reservation on a multislot and input from this multislot (see
Section 2.5 and Figure 5).

3c. LES Slot Control One instance for each MES. Handles reservation on the
signalling channel, input from this channel and congestion
control (see Section 2.6 and Figure 6).

4. LES TDM Handles access control and output to the LES TDM channel.

2.2 Signals
Name Function

I/O to MES Control (LES_I)

To-Mobile message A message for this MES is ready for sending.

Individual poll request An individual poll request for the MES has arrived.

Message Status A message status report has arrived.

MES Control to I/O (LES_IO)

Anomaly A protocol error has occurred.

Cannot deliver message Message cannot be sent.

Cannot poll Poll cannot be sent.

Data Report A message in data reporting mode has been received.

Delivered OK Message has been successfully delivered.

Inform R.C.C. Inform the rescue coordination centre that a distress alert has
been received.

Message Status Request Message Status is requested for the specified


message.

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 4
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Poll success Poll has been successfully sent.

NCS to MES Control (LES_ISL)

Various Packets Packet from NCS referring to this MES has arrived.

MES Control to NCS (NCS_ISL)

Various Packets Send this packet to the NCS.

MES Control to TDM (LES_TDM)

Various Packets Send this packet to the TDM channel.

MES Message to MES Control (MSG)

Message Message from this MES has arrived.

MES Control to Slot Control (SC1)

Reserve Slot Request to reserve a signalling channel slot.

Reserve Confirm Confirmation that the reserving packet has been sent on the
TDM channel.

Slot Control to MES Control (SC2)

Data Packets A packet has arrived from this MES or logical channel.

Slot Reserved A signalling channel slot has been reserved. The parameters
give details of the slot.

Slot Lost An MES in a slot which had been reserved (either explicitly or
via a continuation marker) has failed to send more data.

TDM to Slot Control (T_R)

SCD gone The current Signalling Channel Descriptor is being transmitted


and no further updates are allowed.

Slot Control to Multislot Control (MC1)

SCD gone The Signalling Channel Descriptor for this multislot cannot be
updated.

Next Slot The external event from the TDM, "SCD Gone", is multiplexed
to all frequencies and slots. The multislot that was last current,
the multislot that becomes current and the next multislot to
become current must all be informed. The last multislot must
be informed that its turn is over, the new current multislot must
be informed that its turn to receive has come, and the next
multislot must be informed so that it can accept Reserve
Requests and set the reservation bit in the current slot. This
last action is performed by the signal "Next slot".

Reserve Request Request to reserve this multislot.

Reserve Confirm Confirmation that the reserved multislot is ready to expect data.

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 5
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Multislot Control to Slot Control (MC2)

Data A data packet has arrived.

MS free The multislot may be reserved slot has failed to respond or has
persistent errors.

Slot lost A reserved slot has been lost.

Signalling I/P to Multislot Control (SS1)

Data Data has arrived on this multislot.

Error Something arrived in this multislot, but there was a checksum


failure.

Nothing There was no carrier in this multislot.

Demand Assignment (DA2)

Congestion cleared The MES signalling channels are no longer congested.

2.3 LES MES Control (Figure 3)

2.3.1 Variables
Clear Wait: boolean Set to T if waiting on timer t1.

L: integer Count of announcement attempts.

Message Heard: boolean Set to T if any incoming From-Mobile message blocks


have been received.

N: integer Count of PVT attempts in Distress Test.

PV1: integer Count of PVT attempts in To-Mobile test.

PV2: integer Count of PVT attempts in From-Mobile test.

Repeat Count: integer Number of attempts to complete receiving a message.

Reserve Repeat: integer Number of attempts to reserve a slot.

Retries: integer Number of attempts to complete sending a message.

S: integer Count of attempts to retry NCS for announcements or


polls.

Test_Res_Counter: integer Number of attempts to send a Test Result.

Whole Message Flag: boolean Set to T means necessary to transmit whole message.

2.3.2 Timers
t1 Timer waiting for MES to be deemed idle after activity.

t2 Timer waiting for response from MES.

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 6
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

t3 Timer waiting for response from NCS.

t4 Timer waiting for NCS Announcing.

2.3.3 Constants
The values of these constants are given in Chapter 1. It is recommended that they are implemented in
such a way that they can changed as a result of operational experience.

MaxL: integer Maximum number of announcements to try.

MaxN: integer Maximum number of distress test attempts.

MaxPV: integer Maximum number of PVT attempts.

MaxRC: integer Maximum number of times to attempt to reserve a slot.

MaxRR: integer Maximum number of times to send an acknowledgement


during a From-Mobile call.

MaxS: integer Maximum number of attempts to retry NCS for


announcement or polls.

Max Res Ctr: integer Maximum number of attempts to send a Test Result.

T11: duration Time for MES to be deemed idle after contact.

T12: duration Time to wait for MES announcement response.

T14: duration Time to wait for NCS response to announcement or poll


request.

T15: duration Time to wait for MES unreserved access to signalling


channel.

T16: duration Time to wait for MES message; transmission and re-
acquisition of TDM.

T17: duration Time to wait for MES reserved access to signalling


channel.

T18: duration Time to wait for MES test response.

T19: duration Time to wait for MES distress test.

T23: duration Time between second and subsequent announcements.

T32: duration Time to wait for NCS response to distress alert or EGC
message.

T33 duration Time to wait for MES to re-acquire TDM after message
transmission.

T34: duration Time to wait for NCS to Announce when MES Busy.

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 7
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

2.4 LES MES Signalling Channel Control (Figure 4)

2.4.1 Variables
None

2.4.2 Timers
t Timer waiting for a signalling channel burst in a slot.

2.4.3 Constants
Slot_Period: duration An absolute time interval of 370 TDM symbols/616.66
mS (2nd Generation) or 740 TDM symbols/308.33 mS
(1st Generation).

2.5 LES Multislot Control (Figure 5)

2.5.1 Variables
P: integer Count of number of multislots with errors or data after a
reservation.

Slot Turn: boolean Indicates whether an incoming slot or an outgoing


Signalling Channel Descriptor is expected next. Slot turn
is set true when it becomes the turn of a given Multislot
to receive. It is set false, when its turn expires and
remains false until the remaining Multislots (for that slot)
have had their turns.

Waiting for Input: boolean Data input is expected from the Signalling Channel.

SCD: Slot state This is a reference to the Signalling Channel Descriptor


entry for the multislot. It is owned by Slot Control.

2.5.2 Timers
None

2.5.3 Constants
The values of these constants are given in Chapter 1. It is recommended that they are implemented in
such a way that they can be changed as a result of operational experience.

MaxP: integer Maximum number of multi frames to wait for reserved


access before giving up. This number must be equal to
MaxF in Signalling Channel Control (see Chapter 3,
Section 2.4.3).

2.6 LES Slot Control (Figure 6)

2.6.1 Variables
f: frequency Refers to the frequency of the signalling channel being examined.

s: slot number Refers to the slot number of the signalling channel slot being
examined.

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 8
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

p: multislot number Refers to the multislot number of the signalling channel multislot
being examined.

x: MES identity

Multislot State: array [frequency, slot, multislot] Set to unused if the multislot can be
of (Used, Unused) reserved by the ground-based earth station.

Current Multislot array [frequency, slot] of multislot Gives the number of the multislot which is
to receive: expected to be received in the next
Signalling Channel Descriptor.

MES ID: array [frequency, slot, multislot] Gives the identity of the MES for which
of (MES identity or null) each multislot is reserved.

In Chain: array [frequency, slot, multislot] Set true if data with a continuation marker
of boolean has arrived in the multislot.

Queue: queue of MES ID A queue of MES identities awaiting a


reservable multislot.

SCD: The current Signalling Channel Descriptor


being assembled for transmission. It is
shared by the TDM output and multislot
control.

2.6.2 Timers
none

2.6.3 Constants
FrameCount: array [slot] of integer Contains 2 or 3 for 2-frame or 3-frame slots
respectively.

3 Block LES SDL


The figures are arranged as follows:

LES block Figure 1

Process Demand Assignment Figure 2

Process MES Control Figure 3

Procedure Announce Figure 3(a)

Procedure Anomaly Sig. Channel Figure 3(b)

Procedure Distress Figure 3(c)

Procedure From-MES Message Figure 3(d)

Procedure Test Figure 3(e)

Procedure To-MES Message Figure 3(f)

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 9
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Procedure Enhanced Data Report Figure 3(g)

Process MES Signalling I/P Figure 4

Process Multislot Control Figure 5

Procedure Anomaly Multislot Control Figure 5(a)

Process Slot Control Figure 6

Procedure Anomaly Slot Control Figure 6(a)

Procedure Convert Data to Signal Figure 6(b)

Process TDM Generator Figure 7

Macro Idle Wait Figure 8

Macro Clear Idle Wait Figure 9

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 10
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 1: Block LES, Sheet 1 of 2

Block LES 2.1[1](2)

SIGNAL /* LES LOCAL SIG. */ CONNECT LES_SIG and LES_SIG;


Congested, CONNECT NCS_ISL and NCS_ISL,NCSISL;
Nothing, CONNECT LES_ISL and LES_ISL,LESISL;
Slot_Error, CONNECT MSG and MSG;
Data(INTEGER), CONNECT LES_TDM and LES_TDM,TDM;
Next_Slot(INTEGER), CONNECT LES_O and LES_IO,LESIO;
Slot_Lost(INTEGER), CONNECT LES_I and LES_I;
Multislot_Free,
SCD_Gone(INTEGER),
Reserve_Slot,
Slot_Reserved(INTEGER),
Reserve_Confirm(INTEGER),
Reserve_Request(INTEGER),
NCS_Test_Request,
NCS_Commission_Request,
Call_Cleared;

SYNONYM TDM_Channel_error Integer = 50;


SYNONYM Burst_Received_OK Integer = 51;
SYNONYM No_Burst_Seen Integer = 52;
SYNONYM Unsuccessful_Transfer Integer = 53;
SYNONYM No_Response_From_NCS Integer = 54;
SYNONYM MES_Timeout Integer = 55;
SYNONYM Protocol_Error Integer = 56;
SYNONYM MES_Not_Logged_In Integer = 57;
SYNONYM MES_Protocol_Error_Detected Integer = 59;
SYNONYM Unexpected_Status Integer = 60;
SYNONYM MES_Calling Integer = 61;
SYNONYM No_TDM Integer = 62;
SYNONYM Status_Code Integer = 63;
SYNONYM Param Integer = 64;
SYNONYM Done Integer = 65;
SYNONYM Idle_Announcing Integer = 66;
SYNONYM Unecpected_Signalling_Packet Integer = 67;
SYNONYM No_Announcement_In_Queue Integer = 68;
SYNONYM Timeout_Waiting_On_NCS_Announcement Integer = 69;
SYNONYM MES_Lost Integer = 70;
SYNONYM No_Distress_Alert_Ack Integer = 71;
SYNONYM MES_Hardware_Error_Detected Integer = 72;
SYNONYM MES_Waiting_For_Acknowledgement Integer = 73;
SYNONYM LES_Timeout Integer = 74;
SYNONYM Unexpected_Status_In_Test_Announcement Integer = 75;
SYNONYM Failure_In_Distress_Test Integer = 76;
SYNONYM Failure_In_To_MES Integer = 77;
SYNONYM Failure_In_From_MES Integer = 78;
SYNONYM No_Response_In_To_MES Integer = 79;
SYNONYM No_Valid_Response Integer = 80;

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 11
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 1: Block LES, Sheet 2 of 2

Block LES 2.1[2](2)


LES_IO
(LES_OUTPUT_LIST)

LES_TDM
(TDM_LES_LIST)
LES_I
(LES_INPUT_LIST)
LESIO
Congestion_Cleared

DA3
NCS_Test_Request,
NCS_Commission_Request
MSG NCS_Test_Request,
NCS_Commission_Request
(MSG_LIST)

NCS_ISL NCSISL
(NCS_ISL_LIST)
DA2 (NCS_ISL_LIST2)
Congestion_Cleared

LES_ISL
(LES_ISL_LIST)
MES_ Demand_
_Control(1,1) _Assignment(1,1)
DA1
Congested,
LESISL
SC2 (LES_ISL_LIST2)
Call_Cleared,
(LES_SIG_LIST), Congestion_Cleared
SC1 Distress_Alert,
Reserve_Slot, Slot_Reserved,
Reserve_Confirm Slot_Error,
Slot_Lost

T_R TDM
SCD_Gone SCD
Slot_
_Control(1,1) TDM_GEN(1,1)

MC1
Next_Slot,
MC2
Reserve_Request, Data,
Reserve_Confirm, Multislot_Free,
SCD_Gone Slot_Lost

Multislot_
_Control(1,1)

SS1
Data,
Nothing,
Slot_Error

MES_Sig(1,1)
LES_SIG
(LES_SIG_LIST),
Distress_Alert

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 12
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 2: Process Demand_Assignment

Process Demand_assignment 2.2[1](1)


DCL
Need_Permanent_TDM,
Need_TDM,
Still_Need_TDM,
Congestion,
A_TDM_marked_as_Awaiting_Release_will_ Still_In_Use,
not_be_used_for_any_further_calls_and Awaiting_Release Boolean:=False,
when_all_calls_are_completed_it_will_be_ inf Integer:=0,
released MES_Control,
LES_I_O PId;
Need_ (true)
_Permanent_
_TDM

(false)
TDM_
_Request(inf)
VIA NCSISL

1_Idle

TDM_Request_ TDM_Release_ TDM_Release_


_Response(inf) Congested _Request _Ack
/*NCS*/ /*NCS*/ /*NCS*/

Still_ (false) (true)


Still_ 'Update_
_Need_
_In_Use _Database'
_TDM
(false)
(true)
TDM_ TDM_ 'Mark_This_TDM_
_Release _Release _As_Awaiting_
VIA NCSISL VIA NCSISL _Realease'

- -

(true)
Congestion 1_Idle

(false)
Congestion_ (false)
Need_ Call_ Congestion_
_Cleared
_TDM _Cleared _Cleared
TO MES_Control
(true)
Congestion_ TDM_ (false) Congestion_
Awaiting_
_Cleared _Request(inf) _Cleared
_Release
TO LES_I_O VIA NCSISL TO MES_Control
(true)
(true) Congestion_
Still_
- _Cleared
_In_Use
TO LES_I_O
(false)
TDM_
_Release
VIA NCSISL

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 13
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3: Process MES_Control, Sheet 1 of 10

Process MES_Control 2.3[1](10)


DCL
Clear_Wait,
TDM_Available,
Accept,
Distress_Priority,
Congested,
PVT Boolean:=False,
MES_Forced_Clear,
MES_Not_Logged_In,
Unexpected_Status,
Clear_Wait Real_Distress,Test,
:=false S,inf,Status,Reply,
Source,Result,
MES_Status,Param,
Packet,
1_Not_in_ Stage Integer:=0,
_OR Demand_Assignment,
MES_Control,
MES_Sig,LES_I_O PId;
Commission_ NCS_Commission_ Enhanced_ Enhanced_ Registration TIMER t1,t2,t3,t4;
_Request _Request Registration Registration (inf)
/*NCS*/ /*MES_C*/ (AA_Code) (ISP_Code) /*NCS*/

(not_
(false) _commissioned) (other)
TDM_ MES_
_Available _Status
(true) (idle)
NCS_Commission_ Anomaly_SC
Test
_Request 2_In_OR (Unexpected_
(status)
TO SELF _Status)

Congested
Clear_Idle_Wait TO Demand_ -
_Assignment

1_Not_In_
_OR

MES_Status_ To_MES_Message,
Assignment_
_Request Message_status,
_Request
/*NCS*/ Individual_Poll_Request
/*I/O*/

Anomaly_SC MES_Status
(MES_not_ (not_in_OR)
_logged_in) VIA NCS_ISL

(NCS) Cannot_Deliver
Source (not_in_OR)
TO LES_I_O
(MES)
Request_Status Request_Status
(MES_not_logged_in) (MES_not_logged_in) -
VIA LES_TDM VIA NCS_ISL

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 14
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3: Process MES_Control, Sheet 2 of 10

Process MES_Control 2.3[2](10)

2_In_OR,3_Wait,
1_Not_In_ 6_Wait_
4_Wait_For_ 2_In_OR
_OR _For_NCS
_Congestion

Distress_
Distress_ Distress_ Distress_
_Alert_Test
_Alert _Alert _Alert
/*MES_Sig*/

(NCS) (NCS) (NCS)


Source Source Source

(MES) (MES) (MES)

RESET(t3)

Clear_Idle_Wait Clear_Idle_Wait Clear_Idle_Wait

Inform_ Inform_ Inform_


Distress Distress Distress Distress
_RCC _RCC _RCC
(Real_Distress) (Real_Distress) (Real_Distress) (test)
TO LES_I_O TO LES_I_O TO LES_I_O

Distress_ Distress_ Distress_


Idle_Wait _Alert_Ack Idle_Wait _Alert_Ack Idle_Wait _Alert_Ack Idle_Wait
VIA NCS_ISL VIA NCS_ISL VIA NCS_ISL

2_In_OR 2_In_OR 2_In_OR - 2_In_OR - -

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 15
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3: Process MES_Control, Sheet 3 of 10

Process MES_Control 2.3[3](10)

2_In_OR

Assignment_
_Request

(NCS)
D Source

(MES)

Clear_Idle_
B
_Wait

MES_Status
(busy)
VIA NCS_ISL

(true)
PVT

(false)
(false)
Accept

(true)
(true) Request_Status
Distress_
(status_code)
_Priority
VIA LES_TDM
(false)
(true)
Congested Idle_Wait
(false)

From_MES_ Congested
_Message_L TO Demand_ 2_In_OR
(result) A Network Record _Assignment
should be available for
forwarding to the NCS on
exiting this procedure Request_Status
(pending)
VIA LES_TDM

Idle_Wait

(not_in_OR)
4_Wait_For_
Result
_Congestion
(other)
Congestion_
1_Not_In_
Idle_Wait _Cleared
_OR
/*Demand_A*/

2_In_OR A

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 16
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3: Process MES_Control, Sheet 4 of 10

Process MES_Control 2.3[4](10)

(false)
Accept

(true)
(false) Request_Status
TDM_
(status_code)
_Available
VIA NCS_ISL
(true)
(true)
A Congested 2_In_OR

(false)
Announce (From_ Congested
_MES,status, TO Demand_
reply,source) _Assignment

(fail) (not_in_or) Request_Status


Status (pending)
VIA NCS_ISL
(O_K)

1_Not_In_
2_In_OR 3_Wait
_OR

(assignment_request,
(other) test_request) Congestion_ Assignment_ MES_Forced_
Reply _Cleared _Request _Clear(inf)
(announcement_ /*Demand_A*/ /*NCS*/ /*NCS*/
_response)
MES_Status LES_Forced_
(busy) 2_In_OR A B _Clear()
VIA NCS_ISL VIA NCS_ISL

(test_request)
Clear_Idle_
Packet 2_In_OR
_Wait
(assignment_
_request)
From_MES_
_Message_L E
(result)

Network Record (not_in_or) (NCS)


ould be available for Result Source
warding to the NCS on
ing this procedure (other) (MES)

1_Not_In_
Idle_Wait D B
_OR

2_In_OR

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 17
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3: Process MES_Control, Sheet 5 of 10

Process MES_Control 2.3[5](10)

2_In_OR

To_MES_
_Message
/* I/O*/

(false)
TDM_
_Available
(true)
Announce Cannot_Deliver
(To_MES, (no_TDM)
status,reply,source) TO LES_I_O

(fail) (not_in_or) Congested


Status TO Demand_
_Assignment
(O_K)

Clear_Idle_
- -
_Wait

1_Not_In_
_OR

(assignment_request,
(other) test_request)
Reply
(assignment_
_response,
transfer_
_status_ MES_Status Cannot_ TO LES_I_O
(busy) - _Deliver /*I/O process may re-
_request)
VIA NCS_ISL (MES_calling) initiate the To_
MES message when the
MES has completed the
Clear_Idle_ From_MES call.*/
_Wait

To_MES_ (test_request)
_Message_L Packet
(result)
(assignment_
_request)
Network Record (fail) (not_in_or)
ould be available for Result E
warding to the NCS on
ing this procedure (O_K)
Delivered_ Cannot_Deliver (NCS)
_OK (unsuccessful_ Source
TO LES_I_O _transfer) TO LES_I_O
(MES)

Idle_Wait D B

1_Not_In_
-
_OR

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 18
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3: Process MES_Control, Sheet 6 of 10

Process MES_Control 2.3[6](10)

2_In_OR

MES_Status_ MES_
_Request _Status(inf)
/*NCS*/ /*NCS*/

(false)
Clear_ Clear_Idle_
_Wait _Wait
(not_commissioned,
(true) not_in_OR,
(other) decommissioned)
MES_Status MES_Status
(busy) (idle) Status
VIA NCS_ISL VIA NCS_ISL
(idle,
busy)
Anomaly_SC
1_Not_In_
- (unexpected_
_OR
_status)

2_In_OR

Registration Test_ NCS_Test_


(inf) _Request _Request
/*NCS*/ /*NCS*/ /*MES_Control*/

(false)
Clear_Idle_ TDM_
E
_Wait _Available
(true)
(not_commissioned,
(other) not_in_OR) NCS_Test_
Test
Status _Request
(status)
TO SELF
(idle,
busy)
Anomaly_SC Congested
1_Not_In_
(unexpected_ TO Demand_
_OR
_status) _Assignment

It is recommended (not_in_OR) (fail)


- that messages Status
queued for
transmission be (done)
held for a length
of time to maximise
the probability of Idle_Wait
delivery.

1_Not_In_
2_In_OR
_OR

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 19
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3: Process MES_Control, Sheet 7 of 10

Process MES_Control 2.3[7](10)

2_In_OR

Transfer_Status_ MES_Forced_ Message_


_Request (param) _Clear(inf) _Status_
/*MES_Sig*/ /*MES_Sig*/ _Request

MES_Status (NCS)
Clear_Idle_
(busy) Source
_Wait
VIA NCS_ISL
(MES)
(other) MES_Status
Clear_Idle_
Stage (busy)
_Wait
VIA NCS_ISL

(waiting_for_ack,
waiting_for_clear) LES_Forced_Clear MES_Status
(MES_forced_clear) (busy)
VIA LES_TDM VIA NCS_ISL

LES_Forced_Clear Message_Status_ Message_Status


Clear
(protocol_error) _Request _Request
VIA LES_TDM
VIA LES_TDM TO LES_I_O TO LES_I_O

Idle_Wait Idle_Wait -

- -

4_Wait_For_
_Congestion

Assignment_
MES_Forced_ *
_Request
_Clear(inf) /*MES_Sig*/
/*MES_Sig*/

(NCS)
SENDER=
D Source
MES_sig
(MES)
LES_Forced_Clear LES_Forced_ LES_Forced_Clear
(MES_forced_clear) _Clear() (MES_protocol_error_
VIA LES_TDM VIA NCS_ISL _detected) VIA LES_TDM

Clear_Idle_
Idle_Wait Idle_Wait
_Wait

2_In_OR

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 20
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3: Process MES_Control, Sheet 8 of 10

Process MES_Control 2.3[8](10)

3_Wait,
3_Wait 4_Wait_For_
_Congestion

MES_ Transfer_Status_
_Status(inf) _Request(inf)
/*NCS*/ /*MES_Sig*/

(not_commissioned,
(other) not_in_OR) LES_Forced_Clear
Status (MES_Timeout)
VIA LES_TDM

(idle,
busy) Anomaly_SC
Clear_Idle_
(unexpected_ Idle_Wait
_Wait
_status)

1_Not_In_
2_In_OR 2_In_OR
_OR

2_In_OR,3_Wait,
4_Wait_For_
4_Wait_For_Congestion,
_Congestion
6_Wait_For_NCS

MES_
_Status(inf) t1
/*NCS*/

(not_commissioned,
(other) not_in_OR) MES_Status
Status (idle)
VIA NCS_ISL

(idle,
busy) Anomaly_SC
Clear_Idle_ Clear_Wait
(unexpected_
_Wait :=False
_status)

Clear_Idle_ 1_Not_In_
-
_Wait _OR

- 2_In_OR

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 21
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3: Process MES_Control, Sheet 9 of 10

Process MES_Control 2.3[9](10)

2_In_O R
For CN 132
compliant
LES only
Individual_ Data_ From NC S_
_Poll_Request _Report and_
/*I/O*/ (inf) MES_Sig
Mobile_Mobile_
Data_R epor t
C S:=0 /*MES_Sig*/

Individual_ Data_Report
_Poll ()
VIA NCS_ISL TO LES_I_O

SET(NOW+
T14,t3)
-

6_Wait_
_for_NCS

MES_ Message_ (LES_SIG_LIST)


_Status(inf) _Status /*MES_Sig*/ t3
/*N CS*/ /*I/O */

Message_
RESET(t3) _Status S:=S+1
VIA N CS_ISL

(false)
- S<MaxS

(true)
Cannot_Poll (no_
C _response_from_
(idle_ (busy _ _NCS) TO LES_I_O
_announcement_ _announcement_
_in_queue) _in_queue) (not_in_OR)
Status 2_In_O R

(idle_
_announcing)
Cannot_Poll
(not_in_O R)
TO LES_I_O

Poll_ Clear_Idle_
_Success - -
_Wait
TO LES_I_O

1_Not_In_
2_In_O R
_OR

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 22
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3: Process MES_Control, Sheet 10 of 10

Process MES_Control 2.3[10](10)

Distress

To_MES_
_Message_L

Announce

From_MES_
_Message_L

Test

Anomaly_SC

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 23
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3(a): Procedure Announce, Sheet 1 of 4

Procedure Announce 2.3.1[1](4)


DCL
; FPAR IN class INTEGER,
Clear_Wait Boolean := False,
IN/OUT status,reply,source INTEGER;
L,S,inf,Direction,Distress,
Real_Distress,
MES_Forced_Clear,
Origin,Reason,MES_Lost,
Unexpected_Signalling_Packet,
Packet Integer := 0,
MES_Sig,LES_I_O PId;

L:=0,
S:=0

MES_Status_Request_
_Announcement
VIA NCS_ISL

SET(NOW+
T14,t3)

71_Wait_for_
_NCS

MES_
_Status(inf)
/*NCS*/ (idle_announcement_
_in_queue,
busy_announcement_ (not_commissioned,
not_in_OR) (no_TDM_assignment)
_in_queue)
Status

(idle_announcing)
(other)
RESET RESET
RESET(t3) Direction
(t3,t4) (t3,t4)

(To_MES)
Cannot_Announce
SET(NOW+ SET(NOW+
(not_in_OR)
T12,t2) T34,t4)
TO LES_I_O

Cannot_Announce
72_Wait_For_ Status:=
- (no_TDM)
_MES_Reply Not_In_OR
TO LES_I_O

Assignment_ Announcement_
Clear_Idle_ RESET
_Response _Response
_Wait (t3,t4)
/*MES_Sig*/ /*MES_Sig*/

Status:=
RESET(t2)
Fail

Status:=O_K,
Reply:=Packet,
Source:=MES

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 24
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3(a): Procedure Announce, Sheet 2 of 4

Procedure Announce 2.3.1[2](4)

; FPAR IN class INTEGER,


IN/OUT status,reply,source INTEGER;

72_Wait_For_
71_Wait_for_
_MES_Reply,
_NCS
73

Commission_ MES_Forced_
Announcement_Response, MES_Forced_
t3 _Request t4 _Clear Assignment_Response _Clear(inf)
/*NCS*/ (inf) /*MES_Sig*/ /*MES_Sig*/

S:=S+1
(MES)
Origin
Cancel_
RESET (NCS)
_Announcement
(t3,t4) MES_Status
VIA NCS_ISL
(busy)
VIA NCS_ISL

(false) LES_Forced_Clear LES_Forced_Clear


S< RESET
(MES_forced_ (MES_Forced_Clear)
MaxS (t3)
_clear) VIA LES_TDM
(true) VIA NCS_ISL

MES_Status_Request_ Cannot_Announce Cannot_Announce


Status:=
_Announcement (MES_forced_ (MES_forced_
Fail
VIA NCS_ISL SET(NOW+ _clear) TO LES_I_O _clear) TO LES_I_O
T14,t3)
Cannot_Announce
SET(NOW+ RESET
(no_response_from_ RESET(t3,t4)
T14,t3) (t2,t3,t4)
_NCS) TO LES_I_O

Status:=
- 73 Status:=Fail
Fail

73 Idle_Wait

MES_Status
(LES_SIG_LIST)
(reason) t3 *
/*MES_Sig*/
/*NCS*/

(no_Announcement_in_Queue)
Reason t1

(idle_Announcing)
Cannot_Announce MES_Status
SET(NOW+
(timeout_waiting_ (idle)
T12,t2)
_on_NCS_Announcement) VIA NCS_ISL
TO LES_I_O

72_Wait_for_ Status:= Clear_Wait


_MES_Reply Fail :=False

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 25
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3(a): Procedure Announce, Sheet 3 of 4

Procedure Announce 2.3.1[3](4)

; FPAR IN class INTEGER,


IN/OUT status,reply,source INTEGER;

72_Wait_For_
_MES_Reply

Commission_ MES_Status Transfer_Status_


*
_Request t2 (inf) _Request(stage)
/*MES_Sig*/
/*NCS*/ /*NCS*/ /*MES_Sig*/

SENDER=
RESET(t2) L:=L+1 Stage
MES_sig
(Other)
(Waiting_for_
_message)
(true) LES_Forced_Clear
L<
RESET(t2) (MES_protocol_error_
MaxL
_detected) VIA LES_TDM
(false)
Cannot_Announce Status:=O_K, Cannot_Announce
(MES_lost) Reply:=Packet, (unexpected_signalling_
TO LES_I_O Source:=MES _packet) TO LES_I_O

MES_Status
Status:=
(busy)
Fail
VIA NCS_ISL

Anomaly_SC
(unexpected_
_signalling_packet)

(idle) (other)
Status RESET(t2)
(busy)

(true)
L= Status:= Status:= Status:=
-
MaxL - 1 Fail Not_In_OR Fail

(false)
Clear_Idle_
Idle_Wait
_Wait

RESET(t2)

MES_Status_ MES_Status_
_Request_Announcement
_Request_Announcement
VIA NCS_ISL VIA NCS_ISL Anomaly_SC
(MES_lost)

SET(NOW+ SET(NOW+
T14,t3) T23,t3) Cannot_Announce
(MES_lost)
TO LES_I_O
71_Wait_For_ 71_Wait_For_
_NCS _NCS

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 26
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3(a): Procedure Announce, Sheet 4 of 4

Procedure Announce 2.3.1[4](4)

; FPAR IN class INTEGER,


IN/OUT status,reply,source INTEGER;

Test_ Distress_
Assignment_
_Request _Alert
_Request
/*NCS*/ /*MES_Sig*/

(MES)
RESET
Origin
(t2,t3,t4)
(NCS)

Source:= Source:= Source:=


Status:=Fail
NCS MES NCS

(NCS)
RESET
Origin
(t2,t3,t4)
(MES)
Status:=Fail, Inform_
Clear_Idle_
Reply:= _RCC
_Wait
Packet TO LES_I_O

Distress_
Distress
_Alert_Ack
(Real_Distress)
VIA NCS_ISL

Cannot_Announce
* (distress)
TO LES_I_O

Message_ MES_Status_ To_MES_


_Status_ _Request _Message Idle_Wait
_Request /*NCS*/ /*other_I_O*/

(MES) (false)
Clear_
Origin
_Wait
(NCS) (true)
MES_Status MES_Status MES_Status
(busy) (busy) (idle)
VIA NCS_ISL VIA NCS_ISL VIA NCS_ISL

Idle_Wait -

Message_Status_
_Request
TO LES_I_O

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 27
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3(b): Procedure Anomaly_SC

Procedure Anomaly_SC 2.3.2[1](1)

; FPAR IN cause INTEGER;

'Inform_
_Operator'

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 28
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3(c): Procedure Distress

Procedure Distress 2.3.3[1](1)


; FPAR DCL
IN No_Distress_Alert_Ack,
class Source Integer := 0,
INTEGER; LES_I_O PId;

Real or test

Distress_
_Alert_Ack
VIA LES_TDM

(test)
Class
(real_distress)

Inform_ MES_Status
_RCC (busy)
TO LES_I_O VIA NCS_ISL

Distress_
_Alert
VIA NCS_ISL

MES_Status
(busy)
VIA NCS_ISL

SET(NOW+
T32,t3)

75_Wait_
_For_Ack

Distress_ MES_Sig_
Distress_
_Alert_Ack t3 * _and_NCS_
_Alert
/*NCS*/ _and_I_O

(MES) Anomaly_SC
RESET(t3) Source (no_distress_
_alert_ack)
(NCS)
Distress_Alert_ Distress_
_Ack _Alert_Ack
VIA NCS_ISL VIA LES_TDM

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 29
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3(d): Procedure From_MES_Message_L, Sheet 1 of 3

Procedure From_MES_Message_L 2.3.4[1](3)


DCL
; FPAR IN/OUT result INTEGER; Whole_Message_Flag,
Message_Heard Boolean := False,
Percent_Success,Stage,
Source,Status,MES_Lost,
MES_Forced_Clear,
Real_Distress,
Repeat_Count,inf Integer := 0,
LES_I_O PId;
Whole_Message_
_Flag:=True, H
Repeat_Count:=0

Logical_Channel_
_Assignment (From_
_MES) VIA LES_TDM

Result:=Fail,
Message_Heard
:=False

SET(NOW+
T16,t2)

21_Wait_For_
_Message

Message_
_Packet t2 J
/*MES_Mes*/

(<25) (<100, >=25)


percent_
'Process'
_success
(=100)
Message_
Result:= repeat_count:= Whole_Message_
_Heard
O_K repeat_count+1 _Flag:=False
:=True Of current
transmission
(false)
Clear Repeat_
-
VIA LES_TDM _Count<MaxRC
(true)
(false) LES_Forced_Clear
Whole_
(MES_hardware_error_
_Message_Flag
_detected) VIA LES_TDM
(true)

Ack
H
VIA LES_TDM

SET(NOW+
T16,t2)

21_Wait_For_
_Message

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 30
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3(d): Procedure From_MES_Message_L, Sheet 2 of 3

Procedure From_MES_Message_L 2.3.4[2](3)

; FPAR IN/OUT result INTEGER;

21_Wait_For_
_Message

Transfer_Status_ Assignment_ Announcement_


Distress_
_Request (stage) _Request _Response
_Alert
/*MES_Sig*/ /*MES_Sig*/ /*MES_Sig*/

RESET(t2) RESET(t2) RESET(t2)

(other) (NCS)
Stage Source
(MES_Sig)
(MES_waiting_
_for_ Inform_
Distress
_acknowledgement) _RCC
(Real_Distress)
TO LES_I_O

LES_Forced_Clear Distress_
(MES_protocol_error_ _Alert_Ack
_detected) VIA LES_TDM VIA NCS_ISL

(true)
Message_
_Heard

(false)

'Cancel_
_Allocated_
_Resources'

Logical_Channel_
_Assignment (From_
_MES) VIA LES_TDM

Result:=Fail,
Message_Heard
:=False

SET(NOW+
T16,t2)

21_Wait_For_
_Message

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 31
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3(d): Procedure From_MES_Message_L, Sheet 3 of 3

Procedure From_MES_Message_L 2.3.4[3](3)

; FPAR IN/OUT result INTEGER;

21_Wait_For_
_Message

MES_ MES_Status_ Message_ MES_Forced_


(LES_INPUT_LIST)
_Status(inf) _Request _Status_ _Clear
/*I/O*/
/*NCS*/ /*NCS*/ _Request (inf)

MES_Status (MES_Sig) (NCS)


(busy) Source Source
VIA NCS_ISL
(NCS) (MES_Sig)
MES_Status
- (busy) RESET(t2) RESET(t2)
VIA NCS_ISL

Message_Status_ LES_Forced_Clear
_Request (MES_forced_clear)
TO LES_I_O VIA LES_TDM

LES_Forced_Clear
- (MES_forced_clear)
VIA NCS_ISL

(idle) (other)
Status

(busy)

Result:= Result:=
-
Fail Not_In_OR

RESET(t2)

Anomaly_SC
(MES_lost)

Cannot_Deliver
(MES_lost)
TO LES_I_O

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 32
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3(e): Procedure Test, Sheet 1 of 5

Procedure Test 2.3.5[1](5)


DCL Accept,Waiting_For_Clear,
; FPAR IN/OUT status INTEGER; Clear_Wait Boolean := False,
Unexpected_Status_In_Test_Announce,
Protocol_Error,Real_Distress,
PV,PV1,N,PV2,reply,
Test_Res_Counter,result,
Stage,Source,inf,Test,
status_code,pass Integer := 0,
Slot_Control,
MES_I_O PId;
D PV1:=0

Announce
(PV,status,
reply,test)

(fail) (not_in_OR)
Status

(O_K)
(test_
_request) Anomaly_SC
Reply (other) (unexpected_status_
(assignment_ _in_test_announce)
_response)
Test_Result
Clear_Idle_
PV1:=PV1+1 (not_in_OR)
_Wait
VIA NCS_ISL

MES_Status (false)
PV1< Clear_Idle_
(busy)
MaxPV _Wait
VIA NCS_ISL
(true)
To_MES_ Test_Result
Status:=
_Message_L A D (no_valid_
Not_In_OR
(result) _response)

(fail)
Status:=
Result
fail
(O_K)

PV2:=0 Idle_Wait
(false)

LES_Forced_
SET(NOW+
PV1:=PV1+1 _Clear()
T18,t2)
VIA NCS_ISL

Test_Result
PV1<
61_Wait (failure_in_To_MES)
MaxPV
VIA NCS_ISL
(true)

Status:=
D
fail

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 33
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3(e): Procedure Test, Sheet 2 of 5

Procedure Test 2.3.5[2](5)

; FPAR IN/OUT status INTEGER;

61_Wait

Assignment_ Transfer_
_Request _Status_Request(inf) t2
/*MES_Sig*/ /*MES_Sig*/

RESET(t2) RESET(t2) PV2:=PV2+1

(true) (false)
Waiting_ PV2<
_for_Clear MaxPV
(false) (true)
LES_Forced_Clear
Clear
(MES_Protocol_Error_
VIA LES_TDM
_Detected) VIA LES_TDM

Test_Result (no_
SET(NOW+
A _response_in_
T18,t2)
_To_MES)
VIA NCS_ISL
(false)
Status:=
Accept -
Done
(true)
From_MES_ Request_Status
_Message_L (status_code)
(result) VIA LES_TDM

(fail) Test_Result
Result (failure_in_
_From_MES)
(O_K) VIA NCS_ISL

Status:=
N:=0 PV2:=PV2+1
Done

Distress_Test_ (false)
PV2<
_Request
MaxPV
VIA LES_TDM
(true)
Test_Result
SET(NOW+ SET(NOW+
(failure_in_
T19,t2) T18,t2)
_From_MES)
VIA NCS_ISL

62_Wait_for_
Status:=
_Distress_ -
Done
_Test

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 34
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3(e): Procedure Test, Sheet 3 of 5

Procedure Test 2.3.5[3](5)

; FPAR IN/OUT status INTEGER;

62_Wait_For_
_Distress_
_Test

Distress_ Transfer_
_Alert_Test t2 _Status_Request(inf)
/*MES_Sig*/ /*MES_Sig*/

RESET(t2) N:=N+1 RESET(t2)

(waiting_for_
_Acknowledgement,
Distress_ waiting_for_Clear) (other)
_Alert_Ack Stage
VIA LES_TDM

(waiting_for_
(true) _distress_test)
N< Clear
MaxN VIA LES_TDM
(false)
Test_Result Distress_ LES_Forced_Clear
Test_Res_
(failure_in_ _Test_Request (MES_protocol_error_
_Counter:=0
_distress_test) VIA LES_TDM _detected) VIA LES_TDM
VIA NCS_ISL

Reserve_Slot
Status:= SET(NOW+ SET(NOW+
TO Slot_
Done T19,t2) T18,t2)
_Control

- 61_Wait

63_Wait_For_
_Slot_Control

Slot_Reserved Transfer_Status_
(inf)/*Slot_ _Request(inf)
Control*/ /*MES_Sig*/

Test_Result (other) LES_Forced_Clear


(pass) Stage (MES_Protocol_Error_
VIA LES_TDM _Detected) VIA LES_TDM
(waiting_for_
_test_results,
Reserve_
waiting_for_ Status:=
_Confirm()
_distress_test) Done
TO Slot_Control

Test_Result
SET(NOW+
(failure_in_distress_
T17,t2)
_test)
VIA NCS_ISL

64_Wait_For_
_Result_ -
_Ack

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 35
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3(e): Procedure Test, Sheet 4 of 5

Procedure Test 2.3.5[4](5)

; FPAR IN/OUT status INTEGER;

64_Wait_For_
_Result_
_Ack

Test_Result_ Distress_ Transfer_Status_


_Ack t2 _Alert_Test _Request(inf)
/*MES_Sig*/ /*MES_Sig*/ /*MES_Sig*/

LES_Forced_Clear
RESET(t2) (LES_timeout) RESET(t2) RESET(t2)
VIA LES_TDM

(waiting_for_ (waiting_
Test_Result Distress_ _test_results) _for_clear)
Clear
(failure_in_distress_ _Alert_Ack Stage
VIA LES_TDM
_test) VIA LES_TDM
VIA NCS_ISL (other)
Test_Result
Test_Res_
(pass)
_Counter:=0
VIA NCS_ISL

Reserve_Slot
Status:=
TO Slot_
Done
_Control Clear
VIA LES_TDM

63_Wait_ (false) Test_Result


Test_Res_Counter<
_for_Slot_ (pass)
Max_Test_Res_Ctr
_Control VIA NCS_ISL
(true)

Test_Res_Counter:= Status:=
Test_Res_Counter+1 Done

Reserve_Slot
TO Slot_
_Control

63_Wait_ LES_Forced_Clear
_for_Slot_ (MES_protocol_error_
_Control _detected) VIA LES_TDM

Test_Result
(failure_in_distress_
_test)
VIA NCS_ISL

Status:=
Done

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 36
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3(e): Procedure Test, Sheet 5 of 5

Procedure Test 2.3.5[5](5)

; FPAR IN/OUT status INTEGER;

MES_ MES_Status_ Message_ From NCS_


Distress_ (LES_INPUT_LIST)
_Status(inf) _Request _Status_ and_
_Alert /*I/O*/
/*NCS*/ /*NCS*/ _Request LES_Sig

(NCS) MES_Status Message_Status_


Source (busy) _Request
VIA NCS_ISL TO LES_I_O
(MES_Sig)

RESET(t2) RESET(t2) RESET(t2) -

Test_Result Inform_
(fail) _RCC
VIA NCS_ISL TO LES_I_O

Anomaly_SC Distress_
Distress
(protocol_ _Alert_Ack
(ReaL_Distress)
_error) VIA NCS_ISL

Test_Result
(fail)
VIA NCS_ISL

Status:=
Done

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 37
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3(f): Procedure To_MES_Message_L, Sheet 1 of 4

Procedure To_MES_Message_L 2.3.6[1](4)


DCL
; FPAR IN/OUT result INTEGER; Waiting_For_Msg,
More_Messages,
Any_To_Re_Send,
Waiting_For_Clear Boolean := False,
Reserve_Repeat,
MES_Lost,
MES_Forced_Clear,
Real_Distress,
Retries,inf,Source,Status,
Result:=Fail, stage Integer := 0,
Retries:=0 Slot_Control,
LES_I_O PId;

Reserve_
_Repeat:=0

Message_ TDM_process_must_handshake_
_Data with_LES_MES_Control_to_
VIA LES_TDM ensure_that_Message_Data
is_sent_on_TDM_before_reserve_
slot_request_is_activated
Reserve_
_Slot
TO Slot_Control

13

Slot_ Transfer_Status_
_Reserved(inf) _Request(inf)
/*Slot_Control*/ /*MES_Sig*/

Ack_ (false)
Waiting_
_Request
_For_Msg
VIA LES_TDM
(true)
Reserve_ LES_Forced_Clear
_Confirm(inf) - (MES_protocol_error_
TO Slot_Control _detected) VIA LES_TDM

SET(NOW+ Result:=
T17,t2) Fail

14_Wait_
_For_Ack

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 38
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3(f): Procedure To_MES_Message_L, Sheet 2 of 4

Procedure To_MES_Message_L 2.3.6[2](4)


A Network Record should
; FPAR IN/OUT result INTEGER; be sent to the NCS for each
completed To_MES Message
(except during PVTs)

14_Wait_
_For_Ack

Transfer_Status_
Ack
_Request (stage) t2
/*MES_Sig*/
/*MES_Sig*/

(true)
VIA Reserve_
RESET(t2) RESET(t2)
LES_TDM _Repeat>MaxRR
(false)
(waiting_
_for_message) (other) LES_Forced_
reserve_repeat:=
Stage _Clear (LES_
reserve_repeat+1
(waiting_ _timeout)
_for_clear)
(true) Reserve_
More_ reserve_repeat:=
_Slot TO
_Messages reserve_repeat+1
Slot_Control
(false)
Retries:=0, Reserve_
Clear
Reserve_ _Slot TO 13
VIA LES_TDM
_Repeat:=0 Slot_Control

Reserve_ LES_Forced_Clear
Result:=
_Slot TO 13 (MES_protocol_error_
O_K
Slot_Control _detected) VIA LES_TDM

11

(true)
Any_To_
_Re_Send
(false) (false)
Retries
(false) <=10
PVT
(true)
(true) LES_Forced_Clear
retries:=
(MES_hardware_error_
(false) (true) retries+1
More_ _detected) VIA LES_TDM
_Messages
Message_
_Data
TDM process must handshake Retries:=0, VIA LES_TDM
Clear
with slot control process Reserve_
VIA LES_TDM
to ensure that the packet _Repeat:=0
is not transmitted before Reserve_
the appropriate SCD for the ack _Slot TO
Reserve_ Slot_Control
Result:=
_Slot TO
O_K
Slot_Control

13
11

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 39
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3(f): Procedure To_MES_Message_L, Sheet 3 of 4

Procedure To_MES_Message_L 2.3.6[3](4)

; FPAR IN/OUT result INTEGER;

11

Slot_ Transfer_Status_
_Reserved(inf) _Request(inf)
/*Slot_Control*/ /*MES_Sig*/

Logical_Channel_Assignment Waiting_ (false)


(To_MES) _For_
VIA LES_TDM _Clear
(true)
Reserve_ LES_Forced_Clear
_Confirm() 11 (MES_protocol_error_
TO Slot_Control _detected) VIA LES_TDM

SET(NOW+
T17,t2)

12_Wait_For_
_Assignment_
_Response

Assignment_ Transfer_Status_
_Response _Request(inf) t2
/*MES_Sig*/ /*MES_Sig*/

A Network Record (false)


Reserve_
RESET(t2) should be available at RESET(t2)
_Repeat<MaxRR
this time for the
previous To_MES message (true)
for forwarding to the NCS
Message_ (false) LES_Forced_Clear
Waiting_
_Data (LES_timeout)
_For_Clear
VIA LES_TDM VIA LES_TDM
(true)
Reserve_
reserve_repeat:=
_Slot
reserve_repeat+1
TO Slot_Control
LES_Forced_Clear
(MES_protocol_error_
_detected) VIA LES_TDM
13

Reserve_
_Slot
TO Slot_Control

11

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 40
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3(f): Procedure To_MES_Message_L, Sheet 4 of 4

Procedure To_MES_Message_L 2.3.6[4](4)

; FPAR IN/OUT result INTEGER;

MES_ MES_Status_ Message_ MES_Forced_


(LES_INPUT_LIST)
_Status(inf) _Request _Status_ _Clear
/*I/O*/
/*NCS*/ /*NCS*/ _Request (inf)

MES_Status (MES_Sig) (NCS)


(busy) Source Source
VIA NCS_ISL
(NCS) (MES_Sig)
MES_Status
- (busy) RESET(t2) RESET(t2)
VIA NCS_ISL

Message_Status_ LES_Forced_Clear
_Request (MES_forced_clear)
TO LES_I_O VIA LES_TDM

LES_Forced_Clear
- (MES_forced_clear)
VIA NCS_ISL

(idle) (other)
Status

(busy)

Result:= Result:=
- *
Fail Not_In_OR

Distress_
RESET(t2)
_Alert

Anomaly_SC
RESET(t2)
(MES_lost)

Cannot_Deliver (NCS)
(MES_lost) Source
TO LES_I_O
(MES_Sig)
Inform_
Distress
_RCC
(Real_Distress)
TO LES_I_O

Distress_
_Alert_Ack
VIA NCS_ISL

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 41
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3(g): Procedure Enhanced_Data_Report

Procedure Enhanced_Data_Report 2.3.7[1](1)

DCL
A Boolean := False
2_in_OR

Enh_Data_R Enh_Data_R
t
eport eport_SRQ

Sequence number and


length matching

Perform data True


A? A:=False
checksum check

False
A

False
CRC valid? - -

Sequence number and


length matching True

True
A? -

False

Set (NOW+
MaxCC*T0, t)

A:=True

Enh_Data_R
eport TO
LES_I_O

No Ack A
requested?

Yes

Enh_Data_R Same sequence number and length


eport_Ack

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 42
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 4: Process MES_Sig

Process MES_Sig 2.4[1](1)


DCL
Valid Boolean:=False,
inf Integer:=0,
MultiSlot_Control PId;
TIMER t;

SET(NOW+
Slot_Period,t)

Idle

*
t
/*SIG*/

(false)
Valid

(true)
Data(inf) Slot_Error Nothing
TO Multi_ TO Multi_ TO Multi_
slot_Control slot_Control slot_Control

RESET(t)

SET(NOW+
Slot_Period,t)

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 43
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5: Process Multislot_Control, Sheet 1 of 2

Process Multislot_Control 2.5[1](2)


DCL
Waiting_For_Input,
Next_Slot_Turn,
Slot_Turn,
Continuation Boolean:=False,
TDM_Channel_Error,
In_SCD,Set_SCD,Set_SC,
P,inf Integer:=0,
Slot_Control PId;
'Initialised_
Not_Slot_Turn_
_As_
Not_Next_Slot_Turn
_Available'

1_Available *

Next_Slot(inf) Reserve_
Nothing Slot_Error Data(inf)
/*Slot_ _Request(inf)
/*MES_Sig*/ /*MES_Sig*/ /*MES_Sig*/
_Control*/ /*Slot_Control*/

Waiting_ (false) Next_Slot_ Next_ (false) Waiting_ (false)


_For_ _Turn _Slot_ _For_
_Input :=True _Turn _Input
(true) (true) (true)
Waiting_For_ Anomaly_MC Data(inf) Anomaly_MC
In_SCD:= In_SCD:=
_Input:= (TDM_channel_ TO (TDM_channel_
Unreserved Reserved
False _error) Slot_Control _error)

Set_SCD:=
3_Reserved_
- Burst_
_By_LES
_Received_OK

Waiting_For_
_Input:=
False

(true)
Continuation

(false)
Multislot_Free
P:=0 TO
Slot_Control

2_Reserved_
1_Available
_For_MES

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 44
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5: Process Multislot_Control, Sheet 2 of 2

Process Multislot_Control 2.5[2](2)

Anomaly_MC

2_Reserved_
*
_For_MES

Next_Slot(inf) SCD_Gone(inf)
Nothing Slot_Error
/*Slot_ /*Slot_
/*MES_Sig*/ /*MES_Sig*/
_Control*/ _Control*/

Waiting_ (false) Next_Slot_ (true)


Slot_
_For_ _Turn
_Turn
_Input :=True
(true) (false)
Waiting_For_ Anomaly_MC
In_SCD:= Slot_Turn Slot_Turn
_Input:= (TDM_Channel_
Reserved :=True :=False
False _Error)

Next_Slot_ Waiting_ (true)


P:=P+1 - _Turn _For_
:=False _Input

(false) Set_SC:= (false)


P< Anomaly_MC
no_burst_
MaxP (inf)
_seen
(true)
Slot_Lost Waiting_For_ Waiting_For_
- () TO _Input _Input
Slot_Control :=True :=False

Multislot_ /*If this is a


_Free TO - 2-frame slot
Slot_Control the 2/3 frame
boundary is
too high.
If this is a
1_Available 3-frame slot
there is a
serious timing
problem with
3_Reserved_ the LES*/
_By_LES

Next_Slot(inf) Reserve_
Nothing Slot_Error
/*Slot_ _Confirm(inf)
/*MES_Sig*/ /*MES_Sig*/
_Control*/ /*Slot_Control*/

Waiting_ (false) Next_Slot_


2_Reserved_
_For_ _Turn
_For_MES
_Input :=True
(true)
Waiting_For_ Anomaly_MC
In_SCD:=
_Input:= (TDM_channel_
Unreserved
False _error)

- -

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 45
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5(a): Procedure Anomaly_MC

Procedure Anomaly_MC 2.5.1[1](1)

; FPAR IN cause INTEGER;

'Unspecified_
_Action'

e.g. Inform
Operator

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 46
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 6: Process Slot_Control, Sheet 1 of 3

Process Slot_Control 2.6[1](3)


DCL
x,f,p,n,s,F_s_P,F_s_N,
m_K,MSC_f_s_p,MSC_f_s_n,
Wrong_MES_In_Reserved_Slot,
inf Integer := 0,
Anything_on_Queue,
In_Chain_F_s_P,
Continuation_Set Boolean := False,
MES_Control PId;
/*Set_All_MSS(f,s,p):=Unused,_
'' Set_All_MES_id(f,s,p):=Nil,*/
/*Set_All_Current_MS_To_Receive(f,s):=0,_
Set_All_In_Chain(f,s,p):=False*/

1_Waiting

SCD_Gone
(m_K)
/*TDM*/

/*p:=Current_MS_To_Receive(f,s),_
''
n:=(p+1)MOD(frame_Count(s))*/

SCD_Gone
(MSC_f_s_p)

SCD_Gone
(MSC_f_s_n)

/*p:=n,_
''
n:=(p+1)MOD(Frame_Count(s))*/

Next_Slot
(MSC_f_s_n)

'' /*Current_MS_To_Receive(f,s):=p*/

('yes')

'Any_More_Frequencies(f)_
_Or_Slots(s)'
('no')

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 47
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 6: Process Slot_Control, Sheet 2 of 3

Process Slot_Control 2.6[2](3)

1_Waiting

Reserve_ Multislot_
_Slot _Free
/*MES_Control(x)*/ /*MSC(f_s_p)*/

'Loop_On_All_ /*Except_Those_ (false)


Anything_
_Multislots_ _That_Are_Next_
_On_Queue
(f,s,p)' _To_Be_Received*/
(true)

'x:=MES_id_
_From_Queue'

('unused')
'MSS(f_s_p)'

('used')
Reserve_
('yes') 'More_
_Request
(f,s)'
(MSC_f_s_p)

('no')
Slot_Reserved
(f_s_p) TO MES_
_Control/*(x)*/

'Put_x_On_ 'MES_id(f_s_p)_ 'MSS(f_s_p)_


_Queue' :=x' :=Unused'

'MSS(f_s_p)_ 'MES_id(f_s_d)_
:=Used' :=Nil'

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 48
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 6: Process Slot_Control, Sheet 3 of 3

Process Slot_Control 2.6[3](3)

Anomaly_SL Convert_Data_
_To_Signal

1_Waiting

Reserve_Confirm Data(inf) Slot_Lost


(f_s_p) /*(f_s_p)*/ (f_s_p)
/*MES_Control(x)*/ /*MSC*/ /*MSC*/

('false')
'MES_id_ 'x:=_ 'x:=_
(f_s_p)=x' MES_id(f_s_p)' MES_id(f_s_p)'
('true')
Reserve_ Slot_Error
'MES_id(f_s_p)_
_Confirm TO MES_
:=Nil'
(MSC_f_s_p) _Control/*(x)*/

'InChain(f_s_p)_
-
:=False'

(true) Slot_Lost
In_Chain_
()TO MES_
_f_s_p
_Control/*(x)*/
(false)
(false)
x=Nil -

(true)
'Get(MES_id)_ ('false')
'MES_id_
_From_Packet_
_Packet=x'
_To_x'
('true')
Anomaly_SL
'MES_id(f_s_p)_
(Wrong_MES_
:=x'
_In_Reserved_Slot)

Convert_Data_
_To_Signal(inf)
/*To MES_Control(x)*/

(true)
Continuation_
_Set
(false)

'MES_id(f_s_p)_ 'In_Chain(f_s_p)_
:=Nil' :=True'

'In_Chain(f_s_p)_ 'MSS(f_s_p)_
:=False' :=Used'

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 49
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 6(a): Procedure Anomaly_SL

Procedure Anomaly_SL 2.6.1[1](1)

; FPAR IN cause INTEGER;

'Unspecified_
_Action'

e.g. Inform
Operator

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 50
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 6(b): Procedure Convert_Data_To_Signal

Procedure Convert_Data_To_Signal 2.6.2[1](1)

DCL
; FPAR IN Message_Type INTEGER;
Class Integer := 0;

Message_
_Type

(1) (2) (3) (4) (5) (6) (7)

Assignment_ Distress_ Distress_ MES_Forced_ Message_Status_ Transfer_Status_ Data_Report


_Request _Alert _Alert_Test _Clear(Class) _Request _Request(Class) (Class)
TO MES_Control TO MES_Control TO MES_Control TO MES_Control TO MES_Control TO MES_Control TO MES_Control

(8) (9) (10) (11)

Announcement_ Assignment_ Test_


Ack
_Response _Response _Result_Ack
TO MES_Control
TO MES_Control TO MES_Control TO MES_Control

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 51
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 7: Process TDM_GEN

Process TDM_GEN 2.7[1](1)


DCL
m,Slot_K,m_K Integer := 0;
TIMER t;

SET(NOW+
Frame_Length,
t)

Idle

SET(NOW+
Frame_Length,
t)

SCD(m,
Slot_K)

SCD_Gone
(m_K)

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 52
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 8: Macrodefinition Idle_Wait

Macrodefinition Idle_Wait 2.8[1](1)

SET(NOW+
T11,t1)

Clear_Wait
:=true

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 53
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 9: Macrodefinition Clear_Idle_Wait

Macrodefinition Clear_Idle_Wait 2.9[1](1)

RESET(t1)

Clear_Wait
:=false

Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 54
Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Chapter 3: Mobile Earth Station SDL

Contents

1 Introduction ............................................................................ 3

2 Mobile Earth Station SDL ........................................................ 3


2.1 Processes .........................................................................................................3
2.2 Signals ..............................................................................................................3
2.3 MES Process Control (Figure 5) .......................................................................4
2.3.1 Variables ........................................................................................................4
2.3.2 Timers ............................................................................................................4
2.3.3 Constants .......................................................................................................5
2.4 Signalling Channel Control (Figure 6) ...............................................................5
2.4.1 Variables ........................................................................................................5
2.4.2 Timers ............................................................................................................6
2.4.3 Constants .......................................................................................................6

3 Block MES SDL ....................................................................... 6


Figure 1: Block MES, Sheet 1 of 2 ..........................................................................8
Figure 1: Block MES, Sheet 2 of 2 ..........................................................................9
Figure 2: LES_NCS_SIG ...................................................................................... 10
Figure 3: Process MES_MSG ............................................................................... 11
Figure 4: Process MES_SIG_O_P, Sheet 1 of 2................................................... 12
Figure 4: Process MES_SIG_O_P, Sheet 2 of 2................................................... 13
Figure 5: Process Process_Control, Sheet 1 of 3 ................................................. 14
Figure 5: Process Process_Control, Sheet 2 of 3 ................................................. 15
Figure 5: Process Process_Control, Sheet 3 of 3 ................................................. 16
Figure 5(a): Procedure Data_Report ..................................................................... 17
Figure 5(b): Procedure Forced_Clear ................................................................... 18
Figure 5(c): Procedure Form_MES_Message_M, Sheet 1 of 3 ............................ 19
Figure 5(c): Procedure Form_MES_Message_M, Sheet 2 of 3 ............................ 20

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 1


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5(c): Procedure Form_MES_Message_M, Sheet 3 of 3 ............................ 21


Figure 5(d): Procedure Login ................................................................................ 22
Figure 5(e): Procedure Logout .............................................................................. 23
Figure 5(f): Procedure MES_Distress, Sheet 1 of 2 .............................................. 24
Figure 5(f): Procedure MES_Distress, Sheet 2 of 2 .............................................. 25
Figure 5(g): Procedure MES_Test, Sheet 1 of 3 ................................................... 26
Figure 5(g): Procedure MES_Test, Sheet 2 of 3 ................................................... 27
Figure 5(g): Procedure MES_Test, Sheet 3 of 3 ................................................... 28
Figure 5(h): Procedure Poll ................................................................................... 29
Figure 5(i): Procedure Test_Setup ........................................................................ 30
Figure 5(j): Procedure To_MES_Message_M, Sheet 1 of 2.................................. 31
Figure 5(j): Procedure To_MES_Message_M, Sheet 2 of 2.................................. 32
Figure 5(k): Procedure Data_Report_With_Ack .................................................... 33
Figure 5(l): Procedure Enhanced_Data_Report .................................................... 34
Figure 6: Process Sig_Ch_Control, Sheet 1 of 4 .................................................. 35
Figure 6: Process Sig_Ch_Control, Sheet 2 of 4 .................................................. 36
Figure 6: Process Sig_Ch_Control, Sheet 3 of 4 .................................................. 37
Figure 6: Process Sig_Ch_Control, Sheet 4 of 4 .................................................. 38
Figure 6(a): Procedure Anomaly_SCH.................................................................. 39
Figure 6(b): Procedure Select_Next_Frame_Offset .............................................. 40
Figure 7: Macrodefinition Timeout ......................................................................... 41
Figure 8: Process Receive_LES_TDM_Descriptor ............................................... 42

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 2


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

1 Introduction
A block/process diagram illustrating the MES functions is given in Section 3. The illustrations which
follow it are SDLs for the Mobile Earth Station: they should be used with the explanatory notes given
in Section 2 which follows.

2 Mobile Earth Station SDL

2.1 Processes
1. LES/NCS Signalling Selects reserved or unreserved access for signalling packet
transmission.

2. Message Channel Handles output to the message channel.

3. MES Signalling O/P Handles output to the signalling channel.

4. Process Control Handles all protocols for messaging and other services (see
Section 2.3 and Figure 2).

5. Signalling Channel Handles access control and output to the signalling channel
(see Section 2.4 and Figure 5).

2.2 Signals
I/O to Process Control (MES_I)

Name Function

Clear Request Operator wishes to force clear.

Data Report Operator wishes to send a data reporting message.

Distress Alert Operator wishes to send initial distress alert.

Login/Out Request Operator wishes to log in/out of ocean region or spot beam.

Message Status Request Operator wishes to send a Message Status Request.

From-Mobile message Operator wishes to send a message.

Test Request Operator wishes to start performance verification.

Process Control to I/O (IO)

Confirmation Message receipt confirmed.

Data Report Sent A message in data reporting mode has been sent successfully.

Display Various Conditions.

Distress Alert OK Distress Alert acknowledged.

Message A message has been correctly received.

Poll Request A poll request has been received.

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 3


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Report not sent A message in data reporting mode has failed to be sent.

NCS C.C. to Process Control (NCS_CC)

Various Packet Types Packet of this type for this MES has been received on the NCS
common channel.

TDM to Process Control (LES_TDM)

Various Packet Types Packet of this type for this MES or logical channel has been
received on a TDM channel.

Signalling Channel Control to Process Control (PC)

Success A packet has been successfully transferred on the signalling


channel.

Fail A packet has failed to be sent on the signalling channel.

LES/NCS Signalling to Signalling Channel Control (SIG)

Packet (reserved m-slot) Request to send a packet with reserved access on a particular
multislot.

Packet (unreserved) Request to send a packet using unreserved (random) access.

Process Control to Message (M1)

Message Request to send a message down the message channel.

Message to Process Control (M2)

Message Sent Message has been sent.

TDM to Signalling (LESTDM)

SCD A Signalling Channel Descriptor has arrived (may have


incorrect checksum).

2.3 MES Process Control (Figure 5)

2.3.1 Variables
C: Integer Count of attempts to send packet on the signalling
channel.

PVT: Integer Count of PVT From-Mobile message attempts.

WT: transfer type Type of pending transfer (i.e., From-Mobile).

RESP: packet type Response from LES clear procedures.

2.3.2 Timers
t Timer waiting for response from ground-based earth
station or from the operator.

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 4


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

t1 Timer waiting for Announcement following a 'Request


Pending' response to an assignment request.

2.3.3 Constants
The values of these constants are given in Chapter 1. It is recommended that they are implemented in
such a way that they can be altered as a result of operational experience.

MaxCC: integer Maximum number of attempts to send packet to LES


without response.

MaxCD: integer Maximum number of attempts to send an initial distress


alert to a land earth station without response.

MaxPVT: integer Maximum number of attempts to perform the From-


Mobile message stage of a Performance Verification
Test.

N_Ack: integer Number of TDM frames an MES shall stay tuned to an


LES TDM after seending a data report in order to receive
the indirect acknowledgement. This is only used for
MESs which can support the optional feature of data
reporting with indirect acknowledgement.

T0: duration Time to wait for response from LES.

T1: duration Time to wait for announcement after 'request pending'.

T3: duration Time to wait for distress acknowledgement.

T4: duration Time to wait for LES response during test.

T6: duration Time to wait for response from LES via NCS.

T31: duration Time to wait for LES response after message channel
transmission.

2.4 Signalling Channel Control (Figure 6)

2.4.1 Variables
A: integer Number of blocks in a signalling channel transfer.

B: integer Number of blocks left to send in a signalling channel


transfer.

C: integer Count of retry attempts due to collision or error.

D: integer Count of consecutive frames in which transmission could


not be attempted.

E: integer Count of frames with no free slots or congested.

F: integer Count of consecutive multislots in which reserved


access transmission failed.

K: Frequency/multislot identifier.

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 5


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

R: boolean Set T if reserved access, F in unreserved.

TxEnable boolean Set T if one or more of the last 3 received BBs are valid.

2.4.2 Timers
None

2.4.3 Constants
The values of these constants are given in Chapter 1. It is recommended that they are implemented in
such a way that they can be altered as a result of operational experience.

MaxA: integer Maximum number of packets in a signalling channel


transfer.

MaxB: integer Maximum number of consecutive multislots missed


before aborting transmission.

MaxC: integer Maximum number of retries after collision.

MaxD: integer Maximum number of consecutive frames allowed before


aborting transmission.

MaxE: integer Maximum number of frames with no available slots to


wait.

MaxF: integer Maximum number of transmission attempts during


reserved access.

3 Block MES SDL


The figures are arranged as follows:

Block MES Figure 1

Process LES/NCS Signalling Figure 2

Process MES Message Figure 3

Process MES Signalling O/P Figure 4

Process Process Control Figure 5

Procedure Data Report Figure 5(a)

Procedure Forced Clear Figure 5(b)

Procedure From-MES Message Figure 5(c)

Procedure Login Figure 5(d)

Procedure Logout Figure 5(e)

Procedure MES Distress Figure 5(f)

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 6


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Procedure MES Test Figure 5(g)

Procedure Poll Figure 5(h)

Procedure Test Setup Figure 5(i)

Procedure To-MES Message Figure 5(j)

Procedure Data Report Figure 5(k)

Procedure Enhanced Data Report Figure 5(l)

Process Signalling Channel Control Figure 6

Procedure Anomaly Sig. Channel Figure 6(a)

Procedure Select Next Frame Offset Figure 6(b)

Macro Timeout Figure 7

Process Receive LES TDM Descriptor Figure 8

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 7


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 1: Block MES, Sheet 1 of 2

Block MES 3.1[1](2)

SIGNAL /* MES LOCAL SIG. */


Success,
Fail,
Send_Message,
Message_Sent,
Unreserved_Access(INTEGER,INTEGER),
Reserved_Access,
Backoff,
Data(Integer),
Data_Continuation(INTEGER);

CONNECT MES_O and IO;


CONNECT MES_I and MES_I;
CONNECT NCS_CC and NCS_CC;
CONNECT LES_TDM and LES_TDM,LESTDM;
CONNECT MSG and MSG;
CONNECT LES_SIG and LESSIG;
CONNECT NCS_SIG and NCSSIG;

SYNONYM From_MES_Failed Integer = 100;


SYNONYM PV_Test Integer = 101;
SYNONYM Data_Report_Not_Sent Integer = 102;
SYNONYM In_Forced_Clear Integer = 103;
SYNONYM During_Login Integer = 104;
SYNONYM During_Logout Integer = 105;
SYNONYM Selected_Device Integer = 106;
SYNONYM In_distress_Test Integer = 107;
SYNONYM Distress_Alert_Not_Sent_To_NCS Integer = 108;
SYNONYM During_From_MES Integer = 109;
SYNONYM Invalid_Assignment Integer = 110;
SYNONYM Announce_From_MES Integer = 111;
SYNONYM During_To_MES Integer = 112;
SYNONYM Too_Many_Retries Integer = 113;
SYNONYM Waiting_For_Distress_Test Integer = 114;
SYNONYM LES_Has_Forced_Cleared Integer = 115;
SYNONYM Timeout_While_Waiting_On_CC Integer = 116;
SYNONYM Distress_Activation Integer = 117;
SYNONYM Manually Integer = 118;
SYNONYM Automatic Integer = 119;
SYNONYM During_Test_Setup Integer = 120;
SYNONYM Reserved_Multislots Integer = 121;
SYNONYM Reservation_Lost Integer = 122;
SYNONYM No_service Integer = 123;
SYNONYM Lost_TDM Integer = 124;
SYNONYM Burst_OK Integer = 125;
SYNONYM Slot_Error Integer = 126;
SYNONYM I_O Integer = 127;

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 8


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 1: Block MES, Sheet 2 of 2

Block MES 3.1[2](2)


MES_I
IO (MES_INPUT_LIST)
(MES_OUTPUT_LIST)

M2
LES_TDM Message_Sent
(TDM_LES_LIST)

Process_ MES_MSG(1,1)
_Control(1,1) M1
MSG
NCS_CC Send_Message Message_Packet
(NCS_CC_LIST)
PC
Fail,
NCS_SIG LES_SIG Success
(NCS_SIG_LIST) (LES_SIG_LIST),
Distress_Alert

LES_NCS_
_SIG(1,1)

SIG
Unreserved_Access,
Reserved_Access

Backoff
NCSSIG
(NCS_SIG_LIST)

Sig_Ch_ MES_SIG_O_P(1,1)
LESTDM _Control(1,1)
SCD
S3
LESSIG
Data, (LES_SIG_LIST),
Data_Continuation Distress_Alert

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 9


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 2: LES_NCS_SIG

Process LES_NCS_SIG 3.2[1](1)


DCL
Reserved_Access Boolean := False,
C_Priority,C_Service Integer:=0;

Idle

(false)
Reserved_
_Access
(true)
Unreserved_Access
Reserved_
(C_Priority,
_Access
C_Service)

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 10


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 3: Process MES_MSG

Process MES_MSG 3.3[1](1)

Idle

Send_
_Message

Message_
_Packet

Message_
_Sent

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 11


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 4: Process MES_SIG_O_P, Sheet 1 of 2

Process MES_SIG_O_P 3.4[1](2)


DCL
Class,Direction,
Message_Type Integer := 0;

Idle

(LES)
Direction

(NCS)

Message_
_Type

(1) (2) (3) (4) (5) (6) (7)

Assignment_ Distress_ Distress_ MES_Forced_ Message_Status_ Transfer_Status_ Data_Report


_Request _Alert _Alert_Test _Clear(Class) _Request _Request(Class) (Class)
VIA NCSSIG VIA NCSSIG VIA NCSSIG VIA NCSSIG VIA NCSSIG VIA NCSSIG VIA NCSSIG

(8) (9) (10)

Login_ Logout_ Test_


_Request _Request _Request
VIA NCSSIG VIA NCSSIG VIA NCSSIG

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 12


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 4: Process MES_SIG_O_P, Sheet 2 of 2

Process MES_SIG_O_P 3.4[2](2)

Message_
_T ype

(1) (2) (3) (4) (5) (6) (7)

Assignment_ Distress _ D istress_ MES_F orced_ Mess age_Status_ Transfer_Status_ Data_Report


_Request _Alert _Alert_Test _Clear(Class ) _Request _R equest(C lass) (Class)
VIA LESSIG VIA LESSIG VIA LESSIG VIA LESSIG VIA LESSIG VIA LESSIG VIA LESSIG

For C N132
compliant MES only
(8) (9) (10) (11) (12)

Announc ement_ Assignment_ Ack Test_ Mobile_Mobile_


_R es ponse _Response VIA LESSIG _Result_Ack Data_Report
VIA LESSIG VIA LESSIG VIA LESSIG VIA LESSIG

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 13


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5: Process Process_Control, Sheet 1 of 3

Process Process_Control 3.5[1](3)


DCL
WT,
class,I_O,
result Integer := 0,
MES_I_O PId;
TIMER t,t1;

WT:=Nil

MES tuned to
0_Idle
NCS Common Channel

Announcement LES_Forced_ Poll_Request area,


(class) _Clear(result) (class) poll,
/*NCS_CC*/ /*NCS_CC*/ /*NCS_CC*/ individual

(PV_Test)
class
(From_MES)
(To_MES)
(Nil)
WT
(Other)

WT:=Nil WT:=Nil WT:=Nil WT:=Nil

RESET(t1) RESET(t1) RESET(t1) RESET(t1) Poll

To_MES_ From_MES_ Forced_Clear


Forced_
_Message_M _Message_M MES_Test (From_MES_failed)
_Clear
(result) (WT,result) TO MES_I_O

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 14


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5: Process Process_Control, Sheet 2 of 3

Pr o c e s s P r o c e s s _ C o n t r o l 3 .5 [2 ]( 3 )

0 _ Id l e

F ro m _M E S _ T e s t_ R e q u e s t M es s a ge _
_M e s s ag e / *I_ O * / _ S t a tu s _ R e q u e s t
/* I_ O */ /* I_ O */

(O t he r) ( O th e r) M es s a ge _ /* u n r e s e r v e d _
WT WT _ St a t u s _ _ a c c e s s */
_ R e q ue s t V IA L E S _ S i g
( N il ) ( N i l)
F ro m _M E S _ A w a iti n g _ M e s s a g e _ T e s t_ Se tu p 2 _ W a it _ F o r _
_M e s s ag e _M _ T r a n s fe r ( W T ) (P V ) _ M E S _ S ig
( I_ O ,r e s u lt ) T O M E S _ I_ O

F a il Su c c e s s
- /* M E S _ S i g */ /*M E S _ S i g */ t1

M E S_ S ig _
_ F ailure ()
T O M E S _I_ O

0 _ Id l e

F o r C N 1 3 2 c o m p li a n t M o b i le _ T o _ M o b il e _
0 _ Id l e D a ta _ R e p o r t , B a s e _ M o b il e _
M E S o nly
D a ta _ R e p o r t

D a ta _ R e p o r t( ) Lo gin _ L o go ut _ F o r c e d _ C l e a r _C l e a r i n g D i s tr e s s _
/* I_ O */ _R e qu es t _ R eq ue s t _ R e q ue s t p en de d c all _A lert
/* I_ O */ / *I_ O * / / *I_ O * / /* I_ O */

WT

( O th e r )
D a ta _ R e po r t_
W T := N i l W T := N i l
W i th _ A ck
W T : = N il W T := N i l

R E S E T ( t1 ) R E S E T ( t1 ) R E S E T ( t1 ) R E S E T ( t1 )

Lo gin F o rc ed _ M E S _ D i s tr e ss
D a ta _ R e p o r t L og o ut
(r e s u lt) _ C le ar (R e a l _ D i st re s s )

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 15


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5: Process Process_Control, Sheet 3 of 3

Process Process_Control 3.5[3](3)

/*Signals_s hown_below_are_
MES_Distress to_apply_to_all_states_
of_process_including_
states_within_
all_procedur es*/
Login *

Message_ C onfirmation Netw ork_


Logout _Status /*N CS_CC*/ _Update
/*N CS_CC*/ /*NC S_CC */

Message_ Confirmation 'Store_


From_MES_
_Status T O MES_I_O _Update'
_Mess age_M
T O MES_I_O

To_MES_ -
_Mess age_M

Forced_Clear

MES_Test

Test_Setup 0_Idle

Data_Report t1

(test)
Poll WT

(From_MES)

For CN 132 compliant


WT:=Nil WT:=N il
MES only

From_MES_ Test_
Data_Report_ _Message_M _Setup
_With_Ack (I_O,res ult) (test)

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 16


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5(a): Procedure Data_Report

Procedure Data_Report 3.5.1[1](1)


DCL
inf Integer := 0,
MES_I_O PId;

Data_Report()
To LES via Network
/*Unreserved_
Configuration
Access*/
VIA LES_Sig

20_Wait_For_
MES_Sig

Success Fail
t1
/*MES_Sig*/ /*MES_Sig*/

Data_Report_ MES_Sig_Failure
_Sent (data_report_not_sent)
TO MES_I_O TO MES_I_O

Message_ Network_
Confirmation
_Status _Update
/*NCS_CC*/
/*NCS_CC*/ /*NCS_CC*/

Message_
Confirmation 'Store_
_Status
TO MES_I_O _Update'
TO MES_I_O

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 17


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5(b): Procedure Forced_Clear

Procedure Forced_Clear 3.5.2[1](1)


DCL
C,inf INTEGER :=0,
MES_I_O PId;

C:=0 *

MES_Forced_Clear() Message_ Network_


To current Confirmation
/*unreserved_access*/ _Status _Update
TDM /*NCS_CC*/
VIA LES_Sig /*NCS_CC*/ /*NCS_CC*/

Message_
15_Wait_For_ Confirmation 'Store_
_Status
MES_Sig TO MES_I_O _Update'
TO MES_I_O

Success
Fail
/*MES_LES_ -
/*MES_Sig*/
Sig*/

MES_Sig_Failure
SET(NOW+
(in_forced_clear)
T6,t)
TO MES_I_O

16_Wait_For_
Clear

LES_Forced_ Distress_
Clear
_Clear(inf) _Alert t
/*LES_TDM*/
/*Current_TDM*/ /*I_O*/

RESET(t) RESET(t) Timeout

MES_Forced_Clear()
MES_Distress To current
/*unreserved_access*/
(Real_Distress) TDM
VIA LES_Sig

15_Wait_For_
MES_Sig

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 18


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5(c): Procedure Form_MES_Message_M, Sheet 1 of 3

Procedure From_MES_Message_M 3.5.3[1](3)


Note: Status is
; FPAR IN stage INTEGER,
changed within
IN/OUT result INTEGER;
this procedure

Result:=
K Fail,
C:=0

(I_O) (test)
Stage
(announce_
_From_MES)
From 'Same_
Message_Still_ 'From_LESid_ To_MES_
Network _LES_TDM_
_Available _Find_LES_TDM' _Message
(false) Configuration _As_Used_In_'
(true)
Announcement_ To LES via Assignment_Request Assignment_Request
Forced_
_Response Network /*unreserved_access*/ /*unreserved_access*/
_Clear
VIA LES_Sig Configuration VIA LES_Sig VIA LES_Sig

24_Wait_For_ 23_Wait_For_
MES_Sig MES_Sig

Fail Success Success Fail


/*MES_LES_ /*MES_LES_ /*MES_NCS_ /*MES_LES_
Sig*/ Sig*/ Sig*/ Sig*/

WT:=
From_MES
MES_Sig_Failure
(during_From_MES)
SET(NOW+T1, TO MES_I_O
t1)

Call_Pending (LES)
Network_
(during_From_MES)
_Config_Via
TO MES_I_O
(NCS)
SET(NOW+
T0,t)
SET(NOW+
T6,t)

25_Wait_For_
_Assignment

Timeout

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 19


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5(c): Procedure Form_MES_Message_M, Sheet 2 of 3

Procedure From_MES_Message_M 3.5.3[2](3)


DCL
; FPAR IN stage INTEGER,
Status,From_MES,
IN/OUT result INTEGER;
Network_Config_VIA,
C,inf Integer := 0,
Message_Still_Available,
25_Wait_For_ Assignment_Valid Boolean := False,
_Assignment MES_I_O,MES_Control,
MES_MSG PId;

Logical_Channel_ Announcement Request_Status LES_Forced_Clear


_Assignment (From_MES) (From_MES) (inf) (inf)
/*LES_TDM*/ /*NCS_CC*/ /*Current_TDM*/ /*Current_TDM*/

Announcement_Response
Assignment_
/*unreserved_access*/ RESET(t)
_Valid
(false) VIA LES_Sig
(true)
'Format_ From_MES_
Whole_ RESET(t) RESET(t) RESET(t) _Failed(forced_
Message' _clear) TO MES_I_O

Stage:=
Forced_
RESET(t) Announce_
_Clear
_From_MES

Send_ From_MES_ (rejected)


_Message _Failed(invalid_ Status
TO MES_MSG _assignment)
TO MES_I_O (pending)
27_Wait_For_ Call_Rejected
WT:=
_Message_ (during_From_MES)
From_MES
_Sent TO MES_I_O

If "fail" the MES should


26_Wait_For_ SET(NOW+
tune to the NCS CC.
_MES_Sig T1,t1)
If "success" the MES should
remain tuned to the LES

Success,Fail Call_Pending
/*MES_LES_ (during_From_MES)
Sig*/ TO MES_I_O

25_Wait_For_Assignment,
25_Wait_For_Assignment, SET(NOW+
27_Wait_For_Message_Sent,
27_Wait_For_Message_Sent T0,t)
28_Wait_For_Ack

Forced_Clear_ Distress_
_Request C:=0 _Alert
/*I_O*/ /*I_O*/

25_Wait_For_
RESET(t) RESET(t)
_Assignment

Forced_ MES_Distress
_Clear (Real_Distress)

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 20


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5(c): Procedure Form_MES_Message_M, Sheet 3 of 3

Procedure From_MES_Message_M 3.5.3[3](3)

; FPAR IN stage INTEGER,


IN/OUT result INTEGER;

27_Wait_For_
_Message_ *
_Sent

Message_ LES_Forced_Clear Message_ Network_


Confirmation
_Sent (inf) _Status _Update
/*NCS_CC*/
/*MES_Mes*/ /*LES_TDM*/ /*NCS_CC*/ /*NCS_CC*/

Message_
SET(NOW+ Confirmation 'Store_
_Status
T31,t) TO MES_I_O _Update'
TO MES_I_O

From_MES_Failed
C:=0 (forced_clear) -
TO MES_I_O

28_Wait_
_For_Ack

Logical_Channel_ LES_Forced_Clear
Clear Ack
_Assignment LES_TDM t (inf)
/*LES_TDM*/ /*LES_TDM*/
(From_MES) /*LES_TDM*/

(false)
'Format_Lost_ Assignment_
RESET(t) Timeout RESET(t)
Blocks' _Valid
(true)
'Format_ From_MES_
Result:=O_K RESET(t) Whole_ RESET(t) _Failed(forced_
Message' _clear) TO MES_I_O

Send_ Transfer_Status_
Forced_
_Message RESET(t) _Request (waiting_
_Clear
TO MES_MSG _for_ack)

27_Wait_For_ Send_ From_MES_ VIA LES_Sig


_Message_ _Message _Failed(invalid_ /*Unreserved_
_Sent TO MES_MSG _assignment) _access*/
TO MES_I_O

27_Wait_For_
29_Wait_For_
_Message_
_MES_Sig
_Sent

Success,Fail
/*MES_LES_
Sig*/

SET(NOW+
T0,t)

28_Wait_
_For_Ack

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 21


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5(d): Procedure Login

Procedure Login 3.5.4[1](1)


DCL
; FPAR IN/OUT result INTEGER; Barred,
C,inf INTEGER := 0,
MES_I_O PId;

C:=0,
Result:= *
Fail

Login_Request Message_ Network_


Confirmation
/*unreserved_access*/ _Status _Update
/*NCS_CC*/
VIA NCS_Sig /*NCS_CC*/ /*NCS_CC*/

Message_
71_Wait_For_ Confirmation 'Store_
_Status
MES_Sig TO MES_I_O _Update'
TO MES_I_O

Success Fail
/*MES_NCS_ /*MES_NCS_ -
Sig*/ Sig*/

MES_Sig_Failure
SET(NOW+
(during_login)
T0,t)
TO MES_I_O

72_Wait_
For_Ack

Login_ Request_Status Distress_


_Ack(inf) (barred) _Alert t
/*NCS_CC*/ /*NCS_CC*/ /*I_O*/

RESET(t) RESET(t) RESET(t) Timeout

Status Login_Request
Result:= MES_Distress
(barred) /*unreserved_access*/
O_K (Real_Distress)
VIA IO VIA NCS_Sig

'Store_Network_
71_Wait_For_
_Configuration_
MES_Sig
_If_Returned'

Successful_
_Login
TO MES_I_O

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 22


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5(e): Procedure Logout

Procedure Logout 3.5.5[1](1)


DCL
C INTEGER := 0,
MES_I_O PId;

C:=0

Logout_Request
/*unreserved_access*/ *
VIA NCS_Sig

Message_ Network_
75_Wait_For_ Confirmation
_Status _Update
_MES_Sig /*NCS_CC*/
/*NCS_CC*/ /*NCS_CC*/

Success Fail Message_


Confirmation 'Store_
/*MES_NCS_ /*MES_NCS_ _Status
TO MES_I_O _Update'
Sig*/ Sig*/ TO MES_I_O

MES_Sig_Failure
SET(NOW+
(during_logout) -
T0,t)
TO MES_I_O

76_Wait_For_
_Acknowledgement

Logout_ Distress_
_Ack _Alert t
/*NCS_CC*/ /*I/O*/

RESET(t) RESET(t) Timeout

Successful_ Logout_Request
MES_Distress
_Logout /*unreserved_access*/
(Real_Distress)
TO MES_I_O VIA NCS_Sig

75_Wait_For_
_MES_Sig

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 23


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5(f): Procedure MES_Distress, Sheet 1 of 2

Procedure MES_Distress 3.5.6[1](2)


Test or real DCL
; FPAR I INTEGER; N.B. LM Alerts are sent only to an LES. C INTEGER := 0,
If the LES is operating demand assigned, Destination_LES_Operating_with_
the LM alert may be attempted via the _Permanent_TDMs Boolean := False,
NCS (if supported) in the current OR only. MES_I_O PId;

C:=0

'Destination_LES_Operating_
_with_Permanent_TDMs_OR_
_I=test'
('no')

B
('yes') (test)
I

(test)
I (real_distress) A

(real_distress)
Distress_Alert Distress_Alert_Test
/*unreserved_access*/ /*unreserved_access*/
VIA LES_Sig VIA LES_Sig Distress_Alert Distress_Alert_Test
/*unreserved_access*/ /*unreserved_access
VIA NCS_Sig VIA NCS_Sig
30_Wait_For_
MES_Sig

32_Wait_For_
Success Fail _MES_Sig
/*MES_LES_ /*MES_LES_
Sig*/ Sig*/

(test)
SET(NOW+
I
T3,t)
(real_distress)
31_Wait_For_ MES_Sig_Failure
'Retune_To_
Distress_ t (in_distress_test)
NCS'
Ack TO MES_I_O

Distress_
_Alert_Ack C:=C+1 A
/*LES_TDM*/

(false)
RESET(t) C<MaxCD

(true) (test)
I
Distress_
_Alert_OK
(real_distress)
TO MES_I_O

C:=0

B A

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 24


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5(f): Procedure MES_Distress, Sheet 2 of 2

Procedure MES_Distress 3.5.6[2](2)

; FPAR I INTEGER;

32_Wait_For_
_MES_Sig

Success Fail
/*MES_NCS_ /*MES_NCS_
Sig*/ Sig*/
MES_Sig_Failure
(in_distress_test)
(test)
SET(NOW+ TO MES_I_O
I
T3,t)
(real_distress)
33_Wait_For_
Distress_
Ack

Distress_ MES_Sig_Failure MES may attempt scan


_Alert_Ack t (distress_alert_not_ and synchronise with
/*NCS_CC*/ _sent_to_NCS) TO MES_I_O
an alternative NCS.
See Vol.3 Part 2,
Chapter 2, Section 6.3.4
RESET(t) C:=C+1
C

Distress_ (false)
_Alert_OK C<MaxCD
TO MES_I_O
(true)
(test)
I RESET(t)

(real_distress) C
Distress_Alert_ Distress Alert not
_unsuccessful acknowledged.
TO MES_I_O May be re-initiated
Distress_Alert Distress_Alert_Test if necessary (except
/*unreserved_access*/ /*unreserved_access*/ if test).
VIA NCS_Sig VIA NCS_Sig

32_Wait_For_
*
_MES_Sig

Message_ Network_
Confirmation
_Status _Update
/*NCS_CC*/
/*NCS_CC*/ /*NCS_CC*/

Message_
Confirmation 'Store_
_Status
TO MES_I_O _Update'
TO MES_I_O

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 25


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5(g): Procedure MES_Test, Sheet 1 of 3

Procedure MES_Test 3.5.7[1](3)


DCL
B Waiting_For_Distress_Test,
Waiting_For_Test_Result,
C,PVT,inf Integer := 0,
MES_I_O PId;
To_MES_
_Message_M
(result)

(fail)
Result

(O_K)

SET(NOW+
A PVT:=0
T1,t)

From_MES_ 60_Wait_On_
_Message_M _Common_
(test,result) _Channel

(fail) Announcement
Result (PVT)
/*NCS_CC*/
(O_K)

C:=0 PVT:=PVT+1 RESET(t)

(false)
SET(NOW+ PVT<
B
T4,t) MaxPVT
(true)
Test_Failure
61_Wait_For_
t A (too_many_retries)
_Distress
TO MES_I_O

Distress_Test_
_Request Timeout
/*LES_TDM*/

Transfer_Status_
_Request (Waiting_
MES_Distress _For_Distress_Test)
(test) VIA LES_Sig

61_Wait_For_Distress,
63_Wait_For_
62_Wait_For_LES_Response,
_MES_Sig
67
C:=0

Success,Fail LES_Forced_Clear Terminates


/*MES_LES_ (inf) the Test
SET(NOW+ Sig*/ /*LES_TDM*/ Sequence
T4,t) rather than
a call
SET(NOW+
RESET(t)
T4,t)
62_Wait_For_
_LES_Response

61_Wait_For_
_Distress

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 26


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5(g): Procedure MES_Test, Sheet 2 of 3

Procedure MES_Test 3.5.7[2](3)

60_Wait_On_
64_Wait_For_
_Common_
_MES_Sig
_Channel

LES_Forced_Clear Success,Fail
(inf) t /*MES_
/*NCS_CC*/ LES_Sig*/

Forced_ SET(NOW+
RESET(t)
_Clear T4,t)

Test_Failure 62_Wait_
(timeout_while_ _For_LES_
_waiting_on_CC) _Response
TO MES_I_O

Test_Failure
(LES_has_
_forced_cleared)
TO MES_I_O

62_Wait_
_For_LES_
_Response

Test_Result Distress_
(inf) _Test_Request t
/*LES_TDM*/ /*LES_TDM*/

RESET(t) Timeout
MES_Distress
(test)
Transfer_Status_
'Process_
_Request (waiting_
_Result'
_for_test_result)
C:=0
VIA LES_Sig

Test_Result_Ack
64_Wait_For_
/*reserved_access*/
_MES_Sig
VIA LES_Sig SET(NOW+
T4,t)

65_Wait_For_
_MES_Sig
-

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 27


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5(g): Procedure MES_Test, Sheet 3 of 3

Procedure MES_Test 3.5.7[3](3)

65_Wait_For_
*
_MES_Sig

Success,Fail Message_ Network_


Confirmation
/*MES_LES_ _Status _Update
/*NCS_CC*/
Sig*/ /*NCS_CC*/ /*NCS_CC*/

Message_
Confirmation 'Store_
C:=0 _Status
TO MES_I_O _Update'
TO MES_I_O

SET(NOW+
-
T0,t)

67

Test_Result
Clear
(inf) t
/*LES_TDM*/
/*LES_TDM*/

RESET(t) RESET(t) Timeout

Test_Result Transfer_Status_
'Process_
() _Request (waiting_
Result'
TO MES_I_O _for_clear)
VIA LES_Sig

Test_Result_Ack
68_Wait_For_
/*reserved_access*/
MES_Sig
VIA LES_Sig

Success,Fail
65_Wait_For_
/*MES_
_MES_Sig
LES_Sig*/

SET(NOW+
T0,t)
60_Wait_On_Common_Channel,
61_Wait_For_Distress,
Distress_ 62_Wait_For_LES_Response,
_Alert 67
66_Wait_For_Operator_Response,67
/*I_O*/

RESET(t)

MES_Distress
(Real_Distress)

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 28


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5(h): Procedure Poll

Procedure Poll 3.5.8[1](1)

DCL
MES_I_O PId;

Poll_Request
(selected_device)
TO MES_I_O

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 29


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5(i): Procedure Test_Setup

Procedure Test_Setup 3.5.9[1](1)


DCL
;FPAR Class INTEGER; C,WT,PV,
Status Integer := 0,
MES_I_O PId;

C:=0 *

Test_Request Message_ Network_


Confirmation
/*unreserved_access*/ _Status _Update
/*NCS_CC*/
VIA NCS_Sig /*NCS_CC*/ /*NCS_CC*/

Message_
51_Wait_For_ Confirmation 'Store_
_Status
_MES_Sig TO MES_I_O _Update'
TO MES_I_O

Success Fail
/*MES_NCS_ /*MES_NCS_ -
Sig*/ Sig*/

MES_Sig_Failure
SET(NOW+
(during_test_setup)
T6,t)
TO MES_I_O

52_Wait_For_
_Response

Announcement Request_Status Distress_


(PV) (status) _Alert t
/*NCS_CC*/ /*NCS_CC*/ /*I_O*/

RESET(t) RESET(t) RESET(t) Timeout

Test_Request
Status() MES_Distress
MES_Test /*unreserved_access*/
VIA IO (Real_distress)
VIA NCS_Sig

(rejected)
51_Wait_For_
Status
_MES_Sig
(pending)

SET(NOW+
T1,t1)

WT:=Test

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 30


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5(j): Procedure To_MES_Message_M, Sheet 1 of 2

Procedure To_MES_Message_M 3.5.10[1](2)


DCL
; FPAR IN/OUT result INTEGER; Presentation_Code_Accepted,
Any_Lost_Blocks Boolean := False,
To_MES,
C,inf Integer := 0,
MES_I_O PId;

(false)
Presentation_
_Code_Accepted
(true)
Unrecognised
Result:=Fail, Forced_ 84_Wait_For_Message,
Presentation
C:=0 _Clear 86_Waiting_For_Clear
Code

Assignment_Response From_MES_Failed Distress_


/*unreserved_access*/ (forced_clear) _Alert
VIA LES_Sig TO MES_I_O /*I_O*/

81_Wait_For_
RESET(t)
_MES_Sig

Success Fail
MES_Distress
/*MES_LES_ /*MES_LES_
(Real_Distress)
Sig*/ Sig*/

MES_Sig_Failure
SET(NOW+
(during_To_MES)
T0,t)
TO MES_I_O

Ack_
84_Wait_For_
_Request
_Message
/*LES_TDM*/

Message_
_Packet RESET(t)
/*LES_TDM*/

RESET(t) C:=0

'Put_Message_ 'From_List_Of_
_In_Buffer' _Lost_Blocks'

Ack
SET(NOW+ Up to 11
/*reserved_access*/
T0,t) Blocks
VIA LES_Sig

(true)
Any_Lost_
-
_Blocks
(false)

85_Wait_For_ 82_Wait_For_
_MES_Sig _MES_Sig

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 31


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5(j): Procedure To_MES_Message_M, Sheet 2 of 2

Procedure To_MES_Message_M 3.5.10[2](2)

; FPAR IN/OUT result INTEGER;

84_Wait_For_
_Message

Forced_Clear_ LES_Forced_Clear
t _Request (inf)
/*I_O*/ /*LES_TDM*/

Timeout RESET(t) RESET(t)

VIA LES_Sig Transfer_Status_ To_MES_


Forced_
/*Unreserved_ _Request (waiting_ _Failed(forced_
_Clear
_access*/ _for_message) _clear) TO MES_I_O

82_Wait_For_
_MES_Sig

Success,Fail
85_Wait_For_
/*MES_LES_ *
_MES_Sig
Sig*/

Success,Fail Message_ Network_


SET(NOW+ Confirmation
/*MES_LES_ _Status _Update
T0,t) /*NCS_CC*/
Sig*/ /*NCS_CC*/ /*NCS_CC*/

Message_
SET(NOW+ 84_Wait_For_ Confirmation 'Store_
_Status
T0,t) _Message TO MES_I_O _Update'
TO MES_I_O

86_Waiting_
-
_For_Clear

Ack_ Logical_Channel_ LES_Forced_Clear


Clear
_Request LES_TDM _Assignment t (inf)
/*LES_TDM*/
/*LES_TDM*/ (To_MES) /*LES_TDM*/

Assignment_Response
RESET(t) RESET(t) /*reserved_access*/ Timeout RESET(t)
VIA LES_sig

Result
Result:=O_K C:=0 C:=0
:=Fail

Ack /*no_blocks,_ Transfer_Status_


81_Wait_For_
reserved_access*/ _Request (waiting_
_MES_Sig
VIA LES_Sig _for_clear)

VIA LES_Sig
85_Wait_For_ 85_Wait_For_
/*Unreserved_
_MES_Sig _MES_Sig
_access*/

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 32


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5(k): Procedure Data_Report_With_Ack

Procedure Data_Report_With_Ack 3.5.11[1](1)

DCL
C INTEGER :=0,
Destination_lES_Operating_with_
Permanent_TDMs Boolean :=False,
MES_I_O Pid;

Destinated_LES_Operating_
C:=0 with_Permanent_TDMs

(no) Destinated LES


A operating in DA mode is
no supported for this mode of
(yes) Data Reporting
Data_Report Mobile_To_Mobile_Data_
VIA LES_Sig Report , Base_Mobile_Data_ B
Report

01_Wait_For_
MES_Sig

Sucess Fail
/*MES_LES /*MES_Sig*/
_Sig*/
N_Ack is the
Ack time-out SET(NOW+
factor which is N_Ack*8.64,t) t
configurable
to be at least 10
or more.
02_Wait_For_
Data_Report_ C :=C+1
Ack

Mobile_To_ (false)
Mobile_Poll or C<MaxCC B
Mobile_Base_
Poll (true)
Verify Data Data_Report_Fail
Content TO
MES_I_O

(no)
Result=OK A

(yes)

B RESET (t)

Data_Report_
OK TO
MES_I_O

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 33


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 5(l): Procedure Enhanced_Data_Report

Procedure Enhanced_Data_Report 3.5.12.[1](1)

DCL
C INTEGER :=0,
Destination_LES_Operating_with_
Permanent_TDMs Boolean :=False

C:=0
Destination_LES_operating_
with_permanent_TDMs?

A Destination LESs operating in


False
demand assigned mode are not
supported
True B

Enh_Data_R
eport Via
D LES_Sig C

01_Wait_for_MES_Sig C := C + 1

Success
/*MES_LES
Fail No
/*MES_Sig*/ C<MaxCC?
_Sig*/

Yes
Enh_Data_R
eport_Fail TO
B
No Ack True MES IO
TXEnable?
requested?

False
Yes

No
Set (NOW+T0, t) C odd?

A Yes

02_Wait_for_Enh_
Data_Report_Ack Enh_Data_R
eport_SRQ
Via LES_Sig

Enh_Data_R Same sequence


number and length t
eport_Ack
D

Enh_Data_R C
eport_OK TO
MES IO

Reset t

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 34


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 6: Process Sig_Ch_Control, Sheet 1 of 4

Process Sig_Ch_Control 3.6[1](4)


N.B. B,C,D,E,F,K are local variables,not shared with Process
Control. A is the number of blocks required to be transmitted.
R is a boolean indicating Reserved Access when true.

DCL DCL R,SCD,Pre_Assigned,


TXEnable
RI,Blocks, TXEnable,Distress,
:=False
C_Priority,C_Service, LC_Active,LES_Clear,
Random_Multislot, CUG_SCDs_Received,
Call_Service, Distress_Channel_SCD,
m,Slot_K Integer:=0, Any_Slots,
1_Waiting Process_Control, Slot_Reserved,
MES_Sig_O_P PId; Normal_SCD_Received,
LES_In_Service Boolean:=False;
Unreserved_Access
Reserved_Access
(c_priority,c_service) D
/*Process_Control*/
/*Process_Control*/

C:=0,D:=0, C:=0,D:=0,
E:=0,B:=0, F:=0,A:= C:=C+1
R:=False Blocks,B:=A

2_Waiting_For_ K:= (false)


_SCDs_In_ Reserved_ C<MaxC
_Next_Frame _Multislots
(true)
SCD(m,Slot_ 3_Waiting_For_ (true) Anomaly_SCH
_K) /*Shore_ _Reserved_m_Slot_ Distress (too_many_
_Based_TDM*/ _Frame _retries)
(false)
Distress_ Select_Next_ Fail TO
_Alert_or_ _Frame_Offset Process_
_Distress_ (RI) _Control
_Priority

/*BB(n)_or_ (true)
_BB(n-1)_or_ Offset=1 1_Waiting
_BB(n-2)=OK*/

(false)
(false)
TXEnable A

(true)

D:=D+1

(false) (true) 5_Wait_


LES_In_
D<MaxD _For_
_Service
_Backoff
(true) (false)
2_Waiting_For_
Anomaly_SCH Anomaly_SCH
B _SCDs_In_ Backoff
(no_service) (lost_TDM)
_Next_Frame

Fail TO 2_Waiting_For_
Process_ _SCDs_In_
_Control _Next_Frame

1_Waiting

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 35


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 6: Process Sig_Ch_Control, Sheet 2 of 4

Process Sig_Ch_Control 3.6[2](4)


DCL Congestion,
B No_Service,
Lost_TDM,
Reservation_Lost,
Too_Many_Retries Integer := 0;
Distress_ (true)
_Alert_or_ Distress
_Priority_
_or_Test (false)
(data_
Call_ _reporting)
_Service

(other)
(false) (false) Distress_
CUG_SCDs_
_Channel_
_Received
_SCD
(true) (true)
Logical_Ch_ (true) 'Select_Available_ 'Select_Dedicated_
LC_
_currently_ _CUG_Signalling_ A _Distress_Signalling_
_Active
_active? _Channels' _Channels'

(false)

Clear_or_ (true)
LES_ Any_
_Congested_
_Clear _Slots
_(last_valid_ (false)
_BB_received) (true)
(false)
(false)
Normal_SCD_
_Received
(true)
'Select_Available_
_General_Signalling_ A
_Channels'

(false) (true)
Any_Slots

K:=Random_
E:=E+1 _Multislot,
A:=Blocks,B:=A

(false)
D:=0,
E<MaxE
E:=0
(true)
(true) (true)
Anomaly_SCH
Distress B=1
(congestion)
(false) (false)
Fail TO Select_Next_ Data Data_Continuation
Process_ _Frame_Offset (slot_K) TO (slot_K) TO
_Control (RI) MES_Sig_O_P MES_Sig_O_P

2_Waiting_For_ 4_Waiting_
5_Wait_For_
1_Waiting _SCDs_In_ _For_SCD_
_Backoff
_Next_Frame _Response

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 36


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 6: Process Sig_Ch_Control, Sheet 3 of 4

Process Sig_Ch_Control 3.6[3](4)


3_Waiting_For_ DCL A,B,C,D,E,F,
_Reserved_m_Slot_ Slot_Marker_For_K,
_Frame K,Offset Integer:=0;

SCD (m,Slot_
_K) /*Shore-
_Based_TDM*/

/*BB(n)_or_ (false)
_BB(n-1)_or_ TXEnable
_BB(n-2)=OK*/
(true)
(false)
LES_In_
_Service

(true)
Anomaly_SCH
(no_service)

Fail TO
Process_
_Control

1_Waiting

(false)
SCD=OK

(true)
(true)
Pre_Assigned
(false)

(false)
Slot_
F:=F+1
_Reserved
(true)
(false)
D:=0,
F<MaxF
E:=0
(true)
(true) Anomaly_SCH
Anomaly_SCH
B=1 (reservation_ -
(lost_TDM)
_lost)
(false)
Data Data_Continuation Fail TO
(slot_K) TO (slot_K) TO Process_
MES_Sig_O_P MES_Sig_O_P _Control

4_Waiting_
_For_SCD_ 1_Waiting
_Response

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 37


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 6: Process Sig_Ch_Control, Sheet 4 of 4

Process Sig_Ch_Control 3.6[4](4)


4_Waiting_
_For_ Anomaly_SCH Select_Next_
_SCD_Response _Frame_Offset

SCD(m,Slot_
_K) /*Shore_
_Based_TDM*/

(false)
SCD=OK

(true)
(slot_error) (true) (true)
Slot_Marker_
Pre_Assigned Pre_Assigned
_For_K
(burst_OK) (false) (false)
(false)
B=1 E

(true)
Success TO (true)
Process_ B=1
_Control
(false)
Success
1_Waiting TO Process_
_Control

1_Waiting

('unreserved') (false) (false)


'Slot_Marker_
R R
_For_K'
('reserved') (true) (true)
B:=B-1, (false)
B:=B-1,
C C:=0,F:=0, R F:=F+1 D
F:=1
R:=True
(true)
(false) 3_Waiting_For_
D:=0,E:=0 D F<MaxF _Reserved_m_Slot_
_Frame
(true)

(true) (unreserved)
Slot_Marker_
B=1 E
_For_K
(false) (reserved)

Data Data_Continuation Anomaly_SCH


Anomaly_SCH
(slot_K) TO (slot_K) TO (reservation_ C
(lost_TDM)
MES_Sig_O_P MES_Sig_O_P _lost)

4_Waiting_ Fail TO
_For_SCD_ Process_
_Response _Control

1_Waiting

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 38


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 6(a): Procedure Anomaly_SCH

Procedure Anomaly_SCH 3.6.1[1](1)

;FPAR IN cause INTEGER;

'Unspecified_
_Action'

e.g. Inform
Operator

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 39


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 6(b): Procedure Select_Next_Frame_Offset

Procedure Select_Next_Frame_Offset 3.6.2[1](1)

;FPAR IN/OUT RI INTEGER;

'Select_Next_
_Frame_Offset'
Select a frame at
random between 1 and RI.
The selected number of
RI:=0
frames is the 'Backoff'.

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 40


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 7: Macrodefinition Timeout

Macrodefinition Timeout 3.7[1](1)

C:=C+1

(false)
C<MaxCC

(true)

Timeout
TO MES_I_O

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 41


Inmarsat Confidential C SDM
(Version Release CD004, CN141)

Figure 8: Process Receive_LES_TDM_Descriptor

Process Receive_LES_TDM_descriptor 3.8[1](1)

* Any state where the MES is tuned to


an LES primary TDM (Local ID = 0)

LES_TDM_d
escriptor_pac
ket

Compare to current TDM data for


that LES
Unchanged

New

Save list of permanent TDMs

Volume 5: SDL, Chapter 3: Mobile Earth Station SDL Page: 42


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 4: Network Coordination Station SDL

Contents

1 Introduction ............................................................................ 3

2 Network Coordination Station SDL .......................................... 3


2.1 Processes .........................................................................................................3
2.2 Signals ..............................................................................................................3
2.3 Demand Assignment (Figure 2) ........................................................................4
2.3.1 Variables ........................................................................................................4
2.3.2 Timers ............................................................................................................4
2.3.3 Constants .......................................................................................................4
2.4 NCS MES Control (Figure 3).............................................................................4
2.4.1 Variables ........................................................................................................4
2.4.2 Timers ............................................................................................................4
2.4.3 Constants .......................................................................................................4
2.4.4 LES Definitions ..............................................................................................5

3 Block NCS SDL ........................................................................ 5


Figure 1: Block NCS, Sheet 1 of 2 ..........................................................................6
Figure 1: Block NCS, Sheet 2 of 2 ..........................................................................7
Figure 2: Process NCS_Demand_Assign, Sheet 1 of 2 ..........................................8
Figure 2: Process NCS_Demand_Assign, Sheet 2 of 2 ..........................................9
Figure 3: Process NCS_MES_Control, Sheet 1 of 11 ........................................... 10
Figure 3: Process NCS_MES_Control, Sheet 2 of 11 ........................................... 11
Figure 3: Process NCS_MES_Control, Sheet 3 of 11 ........................................... 12
Figure 3: Process NCS_MES_Control, Sheet 4 of 11 ........................................... 13
Figure 3: Process NCS_MES_Control, Sheet 5 of 11 ........................................... 14
Figure 3: Process NCS_MES_Control, Sheet 6 of 11 ........................................... 15
Figure 3: Process NCS_MES_Control, Sheet 7 of 11 ........................................... 16
Figure 3: Process NCS_MES_Control, Sheet 8 of 11 ........................................... 17

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 1


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 3: Process NCS_MES_Control, Sheet 9 of 11 ........................................... 18


Figure 3: Process NCS_MES_Control, Sheet 10 of 11 ......................................... 19
Figure 3: Process NCS_MES_Control, Sheet 11 of 11 ......................................... 20
Figure 3a: Procedure NCS_Announce, Sheet 1 of 1 ............................................ 21
Figure 3b: Procedure NCS_Distress, Sheet 1 of 1................................................ 22
Figure 3c: Procedure NCS_Login, Sheet 1 of 1 .................................................... 23

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 2


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
A block/process diagram illustrating the NCS functions is given in Figure 1. The illustrations which
follow it are SDLs for the Network Coordination Station: they should be used with the explanatory
notes given in Section 2.

2 Network Coordination Station SDL

2.1 Processes
1. Demand Assignment One instance per NCS. Handles demand assignment of
TDMs (see Section 2.3 and Figure 2).

2. NCS MES Control One instance for each MES. Handles protocol items
associated with this MES (see Section 2.4 and
Figure 3).

2.2 Signals
MES Control to NCS – NCS

Various Packets Send packet to other NCS.

NCS – NCS to MES Control

Various packets Packet regarding this MES has arrived from other NCS.

MES Control to NCS – LES (LES_ISL)

Various packets Send packet to indicated LES.

NCS – LES to MES Control (NCS_ISL)

Various packets Packet regarding this MES has arrived from LES.

MES Control to NCS Common Channel (NCS_CC)

Various packets Send this packet on the NCS Common Channel.

Demand Assignment to NCS – LES Channel (LESISL)

TDM Request Response Send TDM Request Response packet to LES.

TDM Release Request Send TDM Release Request packet to LES.

TDM Request Ack Send TDM Request Acknowledgement packet to LES.

MES Status Send MES Status packet to LES.

NCS – LES Channel to Demand Assignment (NCSISL)

TDM Release A packet releasing a TDM has arrived from an LES.

TDM Request A packet requesting a TDM has arrived from an LES.

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 3


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Signalling Channel to MES Control (NCS_SIG)

Various Packets Packet for this MES has arrived from the Signalling
Channel.

2.3 Demand Assignment (Figure 2)

2.3.1 Variables
Distress Priority Queue: A queue of LESs awaiting a TDM for Distress Priority
traffic. It is ordered on first-in, first-out.

Priority Queue: A queue of LESs awaiting a TDM for Priority non


Distress traffic. It is ordered on first-in, first-out.

Normal Queue: A queue of LESs awaiting a TDM for non Priority traffic.
It is ordered on first-in, first-out.

2.3.2 Timers
None

2.3.3 Constants
None

2.4 NCS MES Control (Figure 3)

2.4.1 Variables
Announcing: boolean Set true if announcement or individual poll
is current.

B: LES identifier Identifier of the last LES to mark the MES


as busy.

MES Region: Ocean Region or null Set to ocean region into which the MES is
logged.

2.4.2 Timers
t Length of time since MES declared busy.

t1 Length of time since confirmation was sent.

t2 Length of time since NCS began announcing for a particular LES.

t3 Timer waiting for response from LES.

2.4.3 Constants
The values of these constants are given in Chapter 1. It is recommended that they are implemented in
such a way that they can be altered as a result of operational experience.

T20 Length of time an MES is declared busy before a status request is sent.

T21 Length of time since a confirmation was sent before it is assumed to have arrived.

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 4


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

T22 Maximum time for NCS to hold MES for an announcement or poll.

T35 Time to wait for an LES response to a distress alert.

This OR Ocean region for this Network Coordination Station.

2.4.4 LES Definitions


The NCS block is handling signals form one MES. In certain states it is possible for the NCS to handle
packets relating to the MES via another LES within the ocean region. Or the MES could send
signalling packets to another LES indirectly via the NCS. The various LESs are defined as follows:

LESi an arbitrary LES through which signalling packets, to or from the MES, are being
handled.

LESj an LES selected by the NCS to perform a PVT.

LES_id this is an LES with which the MES wishes to communicate, via the NCS (e.g., the LES
may be operating demand assigned).

LESB this is the LES with which the MES was last busy.

3 Block NCS SDL


The figures are arranged as follows:

NCS block Figure 1

Process NCS Demand Assignment Figure 2

Process NCS MES Control Figure 3

Procedure NCS Announce Figure 3a

Procedure NCS Distress Figure 3b

Procedure NCS Login Figure 3c

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 5


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: Block NCS, Sheet 1 of 2

Block NCS 4.1[1](2)

CONNECT NCS_ISL and NCS_ISL,NCSISL;


CONNECT LES_ISL and LES_ISL,LESISL;
CONNECT NCS_CC and NCS_CC;
CONNECT NCS_SIG and NCS_SIG;
CONNECT NCS_O and NCS_IO;

SYNONYM LESi Integer = 82;


SYNONYM With_Network_Configuration Integer = 83;
SYNONYM Request_Barred Integer = 84;
SYNONYM Successful Integer = 85;
SYNONYM Extract_from_queue Integer = 86;
SYNONYM Waiting_For_Commission_Announcement Integer = 87;
SYNONYM This_OR Integer = 88;
SYNONYM Login Integer = 89;
SYNONYM Closed_Network_Id Integer = 90;
SYNONYM CNID Integer = 91;
SYNONYM Pending_Request_In_Queue Integer = 92;
SYNONYM MES_Action Integer = 93;
SYNONYM Logout Integer = 94;
SYNONYM MES_Region Integer = 95;
SYNONYM Idle_From_Unexpected_LES Integer = 96;
SYNONYM Message_Status Integer = 97;
SYNONYM Idle_Announcing Integer = 98;
SYNONYM Announce Integer = 99;

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 6


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: Block NCS, Sheet 2 of 2

Block NCS 4.1[2](2)


NCS_CC
(NCS_CC_LIST)

NCS_SIG
(NCS_SIG_LIST)
LES_ISL
(LES_ISL_LIST)

NCS_MES_
_Control(1,1) NCS_IO
(NCS_OUTPUT_LIST)
NCS_ISL
(NCS_ISL_LIST)

LESISL
(LES_ISL_LIST2),
MES_Status

NCS_Demand_
_Assign(1,1)

NCSISL
(NCS_ISL_LIST2)

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 7


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 2: Process NCS_Demand_Assign, Sheet 1 of 2

Process NCS_Demand_Assign 4.2[1](2)


DCL
Priority_Call,
Awaiting_Release,
Permanent_TDM,
Available,
Distress,
Can_Entry_Now_Be_Satisfied,
Any_Announcement_In_Queue,
More_Entries,
More_Queues,
Awaiting_ Valid Boolean := False,
_Release For_All_LESs request_no,LESid,
:=False successful Integer := 0;
TIMER ta;

1_Waiting

TDM_Request
(request_no)
/*LESi*/

(true)
Permanent_
_TDM
(false)
(false)
Valid

(true)
(true) (false)
Distress Available

(false) (true)
(false) 'Give_
Available _Permanent_
_TDM'
(true)
(true) (true)
Priority_
Available
_Call
(false) (false)
'Give_Non_ 'Add_Request_ 'Add_Request_ 'Add_Request_
_Distress_ _To_Pending_ _To_Pending_ _To_Pending_
_TDM' _Queue' _Queue' _Queue'

'Give_
SET(NOW+ 'Non_Distress,_ 'Non_Distress,_ 'Distress,_
_Distress_
Ta,ta) Non_Priority' Priority' priority'
_TDM'

TDM_Request_ TDM_Request_
_Response _Response
(successful) (successful)
VIA LESISL VIA LESISL

TDM_Request_ TDM_Request_
_Response _Response
(pending) (rejected)
VIA LESISL VIA LESISL

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 8


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 2: Process NCS_Demand_Assign, Sheet 2 of 2

Process NCS_Demand_Assign 4.2[2](2)

1_Waiting

TDM_ ta
_Release /*request_no,
/*LESi*/ LESid*/

Awaiting_ TDM_Release_
_Release _Request
:=False VIA LESISL

SET(NOW+
RESET(ta)
Ta,ta)

TDM_ (true)
Awaiting_
_Release_Ack _Release
VIA LESISL
(false)
(false) Awaiting_
Can_Entry_Now_
_Release
_Be_Satisfied
:=True
(true)
For_All_ (true) Any_ (false)
More_
_Entries_ _Announcement_
_Entries
_In_Queue _In_queue
(false) (true)
LESid:= More_ 'Take_One_
Extract_From_ (true) -
_Queues _Off'
_Queue

(false)
(true) MES_Status
NO_TDM_
Distress ()
_Assignment
VIA LESISL
(false)
'Give_Non_ 'Give_
_Distress_ _Distress_
_TDM' _TDM'

SET(NOW+
Ta,ta)

TDM_Request_
_Response
(successful)
VIA LESISL

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 9


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 3: Process NCS_MES_Control, Sheet 1 of 11

Process NCS_MES_Control 4.3[1](11)


DCL
Announcing,
MES_Passed_Login_And_LES_Assigned,
LES_Has_TDM,
Awaitng_Release,
This initialisation is Announcements_Or_Polls_In_Queue,
undertaken when an MES is Confirmation_In_Queue,
first added to the database. Same_As_Current,
Already_In_Queue,
Commission_Bit_Set,
Registration TO all LESs Login_Bit_Set,
(not_commissioned)which are not In_Queue Boolean := False,
VIA LES_ISL CN127 Compliant i,j,B,LESid,Commissioned,
Closed_Network_Id,
Not_Commissioned_No_TDM_Assignment,
Waiting_For_Commission_Announcement,
ISP
Pending_Request_In_Queue,
LES_ID,id,result,rejected,
TRUE FALSE Source,Class,MES_Region,
Enhanced_ Enhanced_ this_OR Integer:=0,
1_Not_ Process_Control,NCS_I_O PId;
Registration Registration
_Commissioned TIMER t,t1,t2,t3;
(ISP_Code) (AA_Code)
VIA ISL VIA ISL

TO all LESs Test_Result Result is


Announcing Login_Request
which are CN127 (result) added to
:=False /*MES_Sig*/
Compliant /*LESj*/ commission-
ing report

1_Not_ NCS_Login
Result
_Commissioned (result)
(fail)
(O_K)
(fail) Registration
/*To non CN127
Result - (idle)
compliant LESs*/
VIA LES_ISL
(O_K)
Enhanced_ VIA LES_ISL
'Find_Suitable_
Registration_ /*To CN127
_LES(no_j)'
Update compliant LESs*/
(idle)

Commission_ MES_Status_Change
TO other
_Request (commissioned,login,
NCS
VIA LES_ISL MES_action)

MES_Region
-
:=This_OR

1_Not_
_Commissioned
3_Idle

MES_Status_ Assignment_ Request_ Individual_


_Request _Request _Status(inf) _Poll
/*LESi*/ /*(j)MES_Sig*/ /*LESj*/ /*LESi*/

MES_Status Assignment_ Request_ MES_Status


(not_commissioned) _Request _Status(inf) (not_in_OR)
VIA LES_ISL VIA LES_ISL VIA NCS_CC VIA LES_ISL

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 10


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 3: Process NCS_MES_Control, Sheet 2 of 11

Process NCS_MES_Control 4.3[2](11)

1_Not_
_Commissioned

MES_Status_
_Request_ LESj
_Announcement

(false)
LES_Has_
_TDM
(true)
(true)
Awaitng_
_Release
(false)
'Type_Of_ ('yes') MES_Status
_Announcement_ (not_commissioned_
=Message(PV)' _no_TDM_assignment)

('no')
MES_Status
(not_commissioned) VIA LES_ISL
VIA LES_ISL

NCS_Announce
(announcement,
LES_id)

RESET(t2)

Announcing
:=False

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 11


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 3: Process NCS_MES_Control, Sheet 3 of 11

Process NCS_MES_Control 4.3[3](11)

1_Not_
_Commissioned, 3_Idle 4_Busy
2_Not_In_OR

Distress_ Distress_ Distress_


_Alert _Alert _Alert
/*real*/

(LESi) (LESi) (LESi)


Source Source Source

(MES_Sig) (MES_Sig) (MES_Sig)


NCS_ Distress_ RESET Distress_
_Distress _Alert_Ack (t1) _Alert_Ack RESET(t)
(class,LES_id) VIA LES_ISL /* All t1*/ VIA LES_ISL

Distress_ NCS_ Distress_ MES_Status


_Alert_Ack TO NCC _Distress _Alert_Ack TO NCC
(idle)
TO NCS_I_O (class,LES_id) TO NCS_I_O

Registration (true) NCS_


(idle) TO all LESs Announcing - _Distress
VIA LES_ISL (class,LESid)
(false)
(commissioned, (false)
MES_Status_ Announcements_Or_
login,
_Change _Polls_In_Queue
MES_action)
/*TO Other_NCSs*/ (true)

MES_Region Confirmation_ 'Take_Next_


:=This_OR _In_Queue _Off'
(true)
(false)
NCS_
3_Idle _Announce
(class,LESid)

'For_All_Confirmation/_
Message_Status_ 3_Idle
_Packets_In_Queue'

SET(NOW+
T21,t1)

(message_status)
Class

(confirmation)

Confirmation Message_
VIA NCS_CC _Status
VIA NCS_CC

3_Idle

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 12


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 3: Process NCS_MES_Control, Sheet 4 of 11

Process NCS_MES_Control 4.3[4](11)

2_Not_In_
_OR

MES_Status_ MES_Status_Request_ Assignment_ Request_


Login_Request
_Request _Announcement _Request _Status(inf)
/*MES_Sig*/
/*LESi*/ /*LESi*/ /*MES_Sig*/ /*LESi*/

MES_Status Assignment_ Request_


NCS_Login
(not_in_OR) _Request _Status(inf)
(result)
VIA LES_ISL VIA LES_ISL VIA NCS_CC

(fail)

Result - - -

(O_K)
Registration
/*To non CN127
(idle)
compliant LESs*/
VIA LES_ISL

Enhanced_ VIA LES_ISL


Registration_ /*To CN127
Update compliant LESs*/
(idle)

MES_Status_Change
To all
(commissioned,login,
other NCSs
MES_action)

MES_Region
:=This_OR

3_Idle

2_Not_In_
_OR

Logout_ Test_Result Individual_


_Request (inf) _Poll
/*MES_sig*/ /*LESi*/ /*LESi*/

Test_Result MES_Status
Logout_Ack
(inf) (not_in_OR)
VIA NCS_CC
TO NCS_I_O VIA LES_ISL

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 13


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 3: Process NCS_MES_Control, Sheet 5 of 11

Process NCS_MES_Control 4.3[5](11)

3_Idle

MES_Status_ MES_Status
_Request_ LESi (class)
_Announcement /*LESi*/

(false) (idle)
LES_Has_
class
_TDM
(true) (busy)
(true) RESET
Awaitng_
(t1,t2) -
_Release
/* All t1*/
(false)
(false) Announcing
Announcing :=False,
B:=i
(true)
(true)
Same_As_ SET(NOW+
_Current T20,t)
(false)
(true)
Already_
4_Busy
_In_Queue
(false)

'Place_In_ NCS_Announce
_Queue' (class,LES_id)

MES_Status (idle_ MES_Status


_announcement_in_ (no_TDM_
_queue) _assignment)
VIA LES_ISL VIA LES_ISL

3_Idle

Request_ MES_Status_
_Status(inf) _Request
/*LESi*/ /*LESi*/

Request_ MES_Status
_Status(inf) (idle)
VIA NCS_CC VIA LES_ISL

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 14


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 3: Process NCS_MES_Control, Sheet 6 of 11

Process NCS_MES_Control 4.3[6](11)

3_Idle

Confirmation Message_ MES_Forced_ Data_Report Individual_


/*LESi*/ _Status _Clear(LESid) (closed_network_ _Poll
/*LESi*/ /*MES_Sig*/ _id) /*MES_Sig*/ /*LESi*/

RESET RESET (false)


'Put_In_ 'Put_In_
(t1) (t1) Announcing
_Queue' _Queue'
/* All t1*/ /* All t1*/
(true)
MES_Forced_ (true)
Same_As_
_Clear(inf) j:=id
_Current
VIA LES_ISL
(false)
'Find_LES_ (true)
Already_
_Corresponding_ _In_Queue
_To_CNID'
(false)
(true) (true) Data_Report
'Place_In_ NCS_Announce
Announcing Announcing (CNID)
_Queue' (class,LES_id)
VIA LES_ISL
(false) (false)
MES_Status (idle_
SET(NOW+ SET(NOW+
_announcement_in_
T21,t1) T21,t1)
_queue)
VIA LES_ISL

Confirmation Message_
_Status -
VIA NCS_CC
VIA NCS_CC

(true)
- Announcing

(false)
'For_All_Confirmation/_
Message_Status_
_Packets_In_Queue'

SET(NOW+
T21,t1)

('message_status')
'Class'

('confirmation')

Confirmation Message_
VIA NCS_CC _Status
VIA NCS_CC

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 15


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 3: Process NCS_MES_Control, Sheet 7 of 11

Process NCS_MES_Control 4.3[7](11)

3_Idle

Assignment_ Message_Status_ Test_ Login_ Logout_


_Request _Request _Request _Request _Request
/*MES_Sig*/ /*MES_Sig*/ /*MES_Sig*/ /*MES_Sig*/ /*MES_sig*/

RESET RESET RESET RESET RESET


(t1) (t1) (t1) (t1) (t1)
/* All t1*/ /* All t1*/ /* All t1*/ /* All t1*/ /* All t1*/

Assignment_ Message_Status_ 'Find_ Logout_


NCS_Login
_Request _Request _Suitable_ _Ack
(result)
VIA LES_ISL VIA LES_ISL _LES (no_j)' VIA NCS_CC

Test_ (fail)
_Request Result RESET(t2)
VIA LES_ISL
(O_K)
(pending_
Request_ Announcing
_request_in_
_Status :=False
_queue)VIA
NCS_CC

Registration
(not_in_OR)
VIA LES_ISL
/*To all LES*/

(commissioned, MES_
3_Idle logout,MES_action) _Status_
/*TO Other_NCS*/ _Change

(true) /*Remove_any_ MES_


Announcing t2 announcements_ _Region
and_confirmation_ :=Nil
(false) from_queue*/

'For_All_Confirmation/_ Announcing 2_Not_In_


Message_Status_ :=False _OR
_Packets_In_Queue'

(false)
SET(NOW+ Announcements_Or_
t1
T21,t1) _Polls_In_Queue
(true)
(message_status) 'Take_Confirmation_
'Take_Next_
Class _Or_Message_Status_
_Off'
_off_queue'
(confirmation)

Confirmation Message_ NCS_Announce


VIA NCS_CC _Status (class,
VIA NCS_CC LES_ID)

- -

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 16


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 3: Process NCS_MES_Control, Sheet 8 of 11

Process NCS_MES_Control 4.3[8](11)

4_Busy

MES_Status_ MES_Status MES_Status_


_Request_ LESi (class) _Request
_Announcement /*LESi*/ /*LESi*/

(idle) MES_Status
class (busy)
VIA LES_ISL
(busy)
(true) (true)
i=B i=B -

(false) (false)
MES_Status MES_Status
(idle)/*LESB*/ (Idle_From_
VIA LES_ISL _Unexpected_LES)
TO NCS_I_O
(false) MES_Status_
LES_Has_
B:=i _Request
_TDM
VIA LES_ISL
(true) /* To LES B */
(true)
Awaitng_ SET(NOW+
- RESET(t)
_Release T20,t)
(false)
(true) (true)
Already_ Announcements_Or_
4_Busy
_In_Queue _Polls_In_Queue
(false) (false)
MES_Status (false)
'Place_In_ Confirmation_ 'Take_Next_
(no_TDM_
_Queue' _In_Queue _Off'
_assignment)
VIA LES_ISL (true)
MES_Status (busy_ 'For_All_Confirmation/_ NCS_Announce
_announcement_in_ Message_Status_ (class,
_queue) _Packets_In_Queue' LES_id)
VIA LES_ISL

SET(NOW+
-
T21,t1)

(message_status)
Class

(confirmation)

Confirmation Message_
VIA NCS_CC _Status
VIA NCS_CC

3_Idle

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 17


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 3: Process NCS_MES_Control, Sheet 9 of 11

Process NCS_MES_Control 4.3[9](11)

4_Busy

Confirmation Message_ MES_Forced_ Individual_ SENDER=


_Status _Clear(LESid) _Poll t Process_
/*LESi*/
/*LESi*/ /*MES_Sig*/ /*LESi*/ _Control
/*MES_Sig*/
(true) MES_Status_
'Put_In_ 'Put_In_ Already_
_Request 'SAVE_SIGNAL'
_Queue' _Queue' _In_Queue
VIA LES_ISL
(false) /* To LES B */

'Place_In_ SET(NOW+
- RESET(t)
_Queue' T20,t)

MES_Status (busy_ MES_Status


_announcement_in_ - (idle)
_queue) VIA LES_ISL
VIA LES_ISL /* To LES B */

This is an anomaly condition,


RESET(t) - the LES appears to be in a
protocol sequence with the
MES that has failed and the
MES has returned to the NCS.
MES_Forced_ The next state is idle, and
_Clear() that state will execute the
VIA LES_ISL appropriate sequence for the
signal received.
(true)
Announcements_Or_
_Polls_In_Queue
(false)
(false)
Confirmation_ 'Take_Next_
_In_Queue _Off'
(true)
'For_All_Confirmation/_ NCS_Announce
_Message_Status_ (class,
_Packets_In_Queue' LES_id)

SET(NOW+
T21,t1)

(message_status)
Class

(confirmation)

Confirmation Message_
VIA NCS_CC _Status
VIA NCS_CC

3_Idle

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 18


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 3: Process NCS_MES_Control, Sheet 10 of 11

Process NCS_MES_Control 4.3[10](11)


DCL
Time_In_Packet,
Latest_Update_Time,
inf Integer := 0;

3_Idle,
*
4_Busy

MES_Status_ Test_ LES_Forced_ Cancel_


_Change(inf,inf,inf) _Result(inf) _Clear(inf) _Announcement
/*NCSj*/ /*LESi*/ /*LESi*/ /*LESi*/

Time_In_Packet PVT_Result (false)


> /*Inform_ In_Queue
Latest_Update_Time (false) _Operator*/
(true)
(true)
LES_Forced_ 'Remove_
- _Clear() _From_
VIA NCS_CC _Queue'

MES_Status
- (inf)
VIA LES_ISL

Commission_
-
_Bit_Set
(false)
(true)
Login_
_Bit_Set
(false)
(true)
MES_Region MES_Region
:=j :=Nil

Registration
To all non CN127 MES_Region
(not_in_OR)
compliant LESs :=Nil
VIA LES_ISL

Enhanced_ VIA LES_ISL Registration


Registration_ To all CN127 (not_in_OR) To all LESs
Update compliant LESs VIA LES_ISL
(not_in_OR)

RESET RESET
(t1,t,t2) (t1,t,t2)
/* All t1*/ /* All t1*/

/*Remove all /*Remove all


Announcing Announcing
Announcements Announcements
:=False :=False
and Cofirmations and Cofirmations
from queue.*/ from queue.*/

2_Not_In_ 1_Not_
_OR _Commissioned

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 19


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 3: Process NCS_MES_Control, Sheet 11 of 11

Process N CS_MES_Control 4.3[11](11)

NCS_Login

R egistration_Update_
NC S_Announce
R equest
/* via ISL*/

/* from CN 131 compliant


NCS_Distress LES */

LES_Enhanced_
R egistration
? no

yes Registration
VIA LES_ISL

Enhanced_Regis tration
VIA LES_ISL

-_

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 20


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 3a: Procedure NCS_Announce, Sheet 1 of 1

Procedure NCS_Announce 4.3.1[1](1)

DCL
; FPAR IN class,CESid INTEGER;
Announcing Boolean := False;

(poll)
Class
(announce)

Individual_
Announcement()
_Poll
VIA NCS_CC
VIA NCS_CC

MES_Status
(idle_announcing)
VIA LES_ISL

SET(NOW+
T22,t2)

Announcing
:=True

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 21


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 3b: Procedure NCS_Distress, Sheet 1 of 1

Procedure NCS_Distress 4.3.2[1](1)

DCL
; FPAR IN class,CESid INTEGER;
NCS_I_O PId;

Operator_
_Alarm
TO NCS_I_O

Alarm
TO NCS_I_O
/*TO NCC*/

Distress_
_Alert_Ack
VIA NCS_CC

'LESid=Valid_ ('no')
_And_
_RCC_Facilities'
('yes')
Distress_
_Alert 'Inform_RCC'
VIA LES_ISL

SET(NOW+
T35,t3)

20_Waiting_
For_Ack

Distress_ MES_Sig_
_Alert_Ack t3 * _and_NCS_
/*LESid*/ _and_LES

RESET(t3) 'Inform_RCC'

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 22


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 3c: Procedure NCS_Login, Sheet 1 of 1

Procedure NCS_Login 4.3.3[1](1)


DCL
; FPAR IN/OUT result INTEGER; with_network_configuration,
request_barred Integer:=0,
Database_Check,
Version_Number Boolean := False;

Database_ (false)
_Check
=OK
(true)

Result Result
:=O_K :=Fail

Version_ (true) Request_Status


_Number (request_barred)
/* = Current */ VIA NCS_CC
(false)
Login_Ack (with_ Login_Ack()
_network_configuration) VIA NCS_CC
VIA NCS_CC

Volume 5: SDL, Chapter 4: Network Coordination Station SDL Page: 23


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Chapter 5: SDL for the Polling Service

Contents

1 Introduction ............................................................................ 2

2 Data Network Control at the LES ............................................. 2

3 Process Polling SDL ................................................................ 2


Figure 1: Process Closed_Network_Control, Sheet 1 of 1 ......................................3

Volume 5: SDL, Chapter 5: SDL for the Polling Service Page: 1


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1 Introduction
The polling service allows a terrestrial user to initiate some action by an MES or a group of MES(s).
The message protocol is described in Volume 1.

2 Data Network Control at the LES


The SDL is shown in Section 3, Figure 1 for the control of Area and Group Polling within each Closed
Network by the LES. Note that the SDL is per Closed Network. Individual Polling is per MES and is
shown in the SDL for MES Control in Chapter 2.

On input from I/O of a request to issue an Area or Group Poll, the LES will transmit the Poll to the
NCS for broadcasting. The LES expects an acknowledgement from the NCS in the form of an Area
Poll Status packet or a Group Poll Status packet as appropriate. If the response is not received within
time TA, the LES should repeat the transmission to the NCS. After MaxP attempts, the LES should
abandon the Poll. The values for these two parameters are:

TA = 5 minutes

MaxP = 3

3 Process Polling SDL


The SDL for the polling process at the LES is shown in Figure 1.

Volume 5: SDL, Chapter 5: SDL for the Polling Service Page: 2


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Figure 1: Process Closed_Network_Control, Sheet 1 of 1

Process closed_network_control 5.1[1](1)

F or C N 132 c ompliant
LES only

1_Ready

Area_Poll_ Group_Poll_
_Request _Request
/*I_O */ /*I_O */
Mobile_To_
C Mobile_Poll,
P:=0 Mobile_To_ P:=0 D
Base_Poll
/*I_O*/

Area_Poll Poll_Packets G roup_Poll


TO N CS VIA TO N CS
LES_TDM

SET(NOW+Ta, SET(NO W+Ta,


t) t)
1_Ready

2_Wait_For_ 2_Wait_F or_


_N CS _NCS

Area_Poll_ Group_Poll_
t _Status t _Status
from NCS from NCS

P:=P+ 1 RESET(t) P:=P+1 RESET(t)

(false) (false)
P<MaxP 1_Ready P<MaxP 1_Ready

(true) (true)
Cannot_Poll Cannot_Poll
C (no_response_from_NCS) D (no_response_from_NCS)
T O I_O TO I_O

1_Ready 1_Ready

Volume 5: SDL, Chapter 5: SDL for the Polling Service Page: 3


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Inmarsat C

System Definition Manual

Recommended Test Procedures (RTPs)

for the Type Approval of

Inmarsat-C Mobile Earth Stations

This document contains information that is confidential, proprietary and of significant


commercial value to Inmarsat Limited. This document has been issued pursuant to a
written Licence Agreement or Confidentiality Agreement (the “Governing Agreement”)
and all access to and (where permitted) use of the information contained herein is
governed strictly by the terms of same. All persons purporting to access or use the
information must be familiar with, and have agreed to, the terms of the Governing
Agreement.

© Inmarsat Limited 2004. All rights reserved. INMARSAT is a trade mark of the
International Mobile Satellite Organization. The Inmarsat LOGO is a trade mark of
Inmarsat (IP) Company Limited. Both trade marks are licensed to Inmarsat Limited.

Recommended Test Procedures (RTPs), Front Page & Table of Contents, Page: 1
Section 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1. INTRODUCTION

1.1 PURPOSE AND SCOPE

This document, entitled "Recommended Test Procedures for Type Approval of Inmarsat-C Mobile Earth
Stations", presents a set of suggested test procedures which are a suitable basis for detailed type approval test
plans of a new model of Inmarsat-C Mobile Earth Station.

The methods of testing described in Sections 2, 3, 4, 5, 6 and 8 are not mandatory, and MES manufacturers are
free to adapt or revise them or propose alternative procedures if necessary.

The recommended technical characteristics of test simulators are described in Section 7.

1.2 DEFINITIONS AND REFERENCE DOCUMENTS

Throughout this document references are made to the Inmarsat-C System Definition Manual (SDM) and it is
assumed that the reader is already familiar with the definition of terms and abbreviations (SDM Volume 1).

1.3 STRUCTURE OF THE DOCUMENT

The remaining sections of this document cover respectively:

SECTION 2: Test Procedures for Type Approval Phase I testing (in-factory tests for base line
MES)
SECTION 3: * Test Procedures for Type Approval Phase I testing (in-factory tests for maritime
SES)
SECTION 4: Test Procedures for Land Mobile stations, LMES
SECTION 5: Test Procedures for Land Portable stations, LPES
SECTION 6: Test Procedures for EGC Receivers
SECTION 7: Technical characteristics of test simulators (LES/NCS simulators and Channel
simulators);
SECTION 8: Test Procedures for Type Approval Phase II testing (with a LES via satellite)
Test procedures (Phase I and Phase II testing) for optional/alternative capabilities and specialised services are
included.

* Note : Annex A refers to additional requirements for SOLAS SES`S


Annex B Supplementary & substitute test procedures for Low Power Land Mobile & Ship
Earth Stations

1.4 ADDITIONAL NOTES

1) New issues of this document may be released from time to time. It is a matter for the manufacturer to
ensure that the issue he is using is the latest.

2) Further test items may be added to this document in the future to cover, for instance, optional features
not already covered.

Recommended Test Procedures (RTPs), Front Page & Table of Contents, Page: 2
Section 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

TABLE OF CONTENTS Page No.

1. INTRODUCTION ..................................................................................................................... 1

1.1 Purpose and Scope ...................................................................................................... 1

1.2 Definitions and Reference Documents ....................................................................... 1

1.3 Structure of the Document .......................................................................................... 1

1.4 Additional Notes ......................................................................................................... 1

2. PHASE 1 TESTS FOR MOBILE EARTH STATIONS ........................................................... 1

2.1 INTRODUCTION AND REQUIRED TESTS ........................................................... 1

2.1.1 General.......................................................................................................... 1

2.1.2 Required Tests............................................................................................... 1

2.1.3 Functional Checks......................................................................................... 1

2.1.4 Tests for EGC Reception .............................................................................. 1

2.1.5 Tests Performed by Original Equipment Manufacturers .............................. 1

2.1.6 Input/Output Devices .................................................................................... 2

2.1.7 Environmental Conditions Tests ................................................................... 2

2.1.8 Test Set-Up with NCS/LES Simulator.......................................................... 6

2.1.8.1 Initialisation .................................................................................... 6

2.1.8.2 Set-up of calls using NCS/LES simulator....................................... 9

2.1.8.3 Other Functions .............................................................................. 9

2.2 TEST PROCEDURES .............................................................................................. 14

ITEM 1-A ANTENNA GAIN PROFILE ............................................................. 14

ITEM 1-B POLARISATION AND AXIAL RATIO............................................ 17

ITEM 2-A RECEIVING SYSTEM NOISE TEMPERATURE ............................ 19

ITEM 2-B G/T CALCULATIONS....................................................................... 22

ITEM 2-C RECEIVER TUNING ......................................................................... 23

ITEM 2-D RECEIVER SELECTIVITY............................................................... 25

ITEM 3-A OUTPUT POWER & FREQUENCY RESPONSE ............................ 27

ITEM 3-B EIRP CALCULATIONS..................................................................... 30

ITEM 3-C TRANSMITTED SPECTRUM........................................................... 31

Recommended Test Procedures (RTPs), Front Page & Table of Contents, Page: 3
Section 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 3-D TRANSMITTER OFF POWER LEVEL ............................................ 33

ITEM 3-E SPURIOUS OUTPUTS....................................................................... 36

ITEM 3-F HARMONIC OUTPUTS .................................................................... 40

ITEM 3-G PHASE NOISE ................................................................................... 42

ITEM 3-H TRANSMITTER TUNING................................................................. 45

ITEM 3-I TRANSMITTER FREQUENCY STABILITY .................................. 47

ITEM 4-A PACKET ERROR RATE.................................................................... 49

ITEM 4-B CARRIER AND FRAME ACQUISITION ........................................ 53

ITEM 5-A MODULATION CHARACTERISTICS ............................................ 58

ITEM 5-B FIRST GENERATION OPERATION................................................ 60

ITEM 5-C SIGNALLING CHANNEL CHARACTERISTICS ........................... 62

ITEM 5-D MESSAGE CHANNEL CHARACTERISTICS................................. 66

ITEM 5-E ALTERNATIVE NETWORK PROTOCOLS - SIGNALLING CHANNEL


CHARACTERISTICS ........................................................................ 72

ITEM 5-F ALTERNATIVE NETWORK PROTOCOLS - MESSAGE CHANNEL


CHARACTERISTICS ........................................................................ 75

ITEM 5-G SPECIAL ACCESS CODE ADDRESSING - SIGNALLING CHANNEL


CHARACTERISTICS ........................................................................ 78

ITEM 5-H SPECIAL ACCESS CODE ADDRESSING - MESSAGE CHANNEL


CHARACTERISTICS ........................................................................ 80

ITEM 5-I X.400 ADDRESSING - SIGNALLING CHANNEL CHARACTERISTICS


............................................................................................................. 82

ITEM 5-J X.400 ADDRESSING - MESSAGE CHANNEL CHARACTERISTICS 84

ITEM 6-A GENERAL ACCESS CONTROL TEST............................................ 87

ITEM 6-A/1 POLLING AND DATA REPORTING TEST PROCEDURES ....... 131

ITEM 6-B TDMA SYNCHRONISATION ........................................................ 178

ITEM 6-C RANDOM ACCESS ......................................................................... 182

ITEM 6-D COMMON CHANNEL SELECTION.............................................. 185

ITEM 6-E OCEAN REGION REGISTRATION ............................................... 188

ITEM 6-E/1 OCEAN REGION LES SUPPORT .................................................. 190

ITEM 6-F IDLE AND BUSY CONDITIONS ................................................... 192

Recommended Test Procedures (RTPs), Front Page & Table of Contents, Page: 4
Section 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 7-A CHARACTER CODES..................................................................... 196

ITEM 7-B DISPLAY DEVICES ........................................................................ 197

ITEM 7-C KEYBOARD..................................................................................... 199

ITEM 7-D MES MEMORY CAPACITY........................................................... 201

ITEM 7-E DCE/DTE INTERFACE CHARACTERISTICS.............................. 203

ITEM 7-F INTERFACE CONTROL CODES ................................................... 206

ITEM 9-A FAIL-SAFE AND MONITORING .................................................. 209

ITEM 9-B PERFORMANCE VERIFICATION & COMMISSIONING........... 211

ITEM 10-A MAINS CONDUCTED SPURIOUS EMISSIONS .......................... 213

ITEM 11-A VIBRATION FREQUENCY RESPONSE ....................................... 216

ITEM 11-B RAIN TEST ...................................................................................... 219

3. PHASE 1 TESTS FOR SHIP EARTH STATIONS.................................................................. 1

3.1 INTRODUCTION AND REQUIRED TESTS ........................................................... 1

3.1.1 General.......................................................................................................... 1

3.1.2 Required Tests............................................................................................... 1

3.1.3 Functional Checks......................................................................................... 2

3.1.4 Tests for EGC Reception .............................................................................. 2

3.1.5 Tests Performed by Original Equipment Manufacturers .............................. 2

3.1.6 Input/Output Devices .................................................................................... 2

3.1.7 Environmental Conditions Tests ................................................................... 2

3.1.8 Test Set-Up with NCS/LES Simulator.......................................................... 7

3.1.8.1 Initialisation .................................................................................... 7

3.1.8.2 Set-up of calls using NCS/LES simulator..................................... 10

3.1.8.3 Other Functions ............................................................................ 10

3.2 TEST PROCEDURES .............................................................................................. 13

ITEM S5-C SIGNALLING CHANNEL CHARACTERISTICS ........................... 13

ITEM S5-G 2-DIGIT SPECIAL ACCESS CODE ADDRESSING - SIGNALLING


CHANNEL CHARACTERISTICS .................................................... 15

Recommended Test Procedures (RTPs), Front Page & Table of Contents, Page: 5
Section 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM S5-H SPECIAL ACCESS CODE ADDRESSING - MESSAGE CHANNEL


CHARACTERISTICS ........................................................................ 17

ITEM S7-B DISPLAY DEVICES .......................................................................... 19

ITEM S7-D SES MEMORY CAPACITY .............................................................. 21

ITEM S8-A DISTRESS MESSAGE GENERATOR.............................................. 23

ITEM S8-B DISTRESS ALERT ACTIVATION ................................................... 25

ITEM S9-B PERFORMANCE VERIFICATION & COMMISSIONING............. 27

4. PHASE 1 TESTS FOR LAND MOBILE EARTH STATIONS ............................................... 1

4.1 INTRODUCTION AND REQUIRED TESTS ........................................................... 1

4.1.1 GENERAL .................................................................................................... 1

4.1.2 REQUIRED TESTS...................................................................................... 1

4.1.3 FUNCTIONAL CHECKS ............................................................................ 1

4.1.4 TESTS FOR EGC RECEPTION .................................................................. 1

4.1.5 TESTS BY ORIGINAL EQUIPMENT MANUFACTURERS.................... 1

4.1.6 ENVIRONMENTAL CONDITIONS TESTS .............................................. 2

4.1.6.1 Test Procedures for Land Mobile Earth Stations ............................ 2

4.1.7 TEST SET-UP WITH NCS/LES SIMULATOR .......................................... 6

4.1.7.1 Initialisation .................................................................................... 6

4.1.7.2 Set-up of calls using NCS/LES simulator....................................... 9

4.1.7.3 Other functions ............................................................................... 9

4.2 TEST PROCEDURES .............................................................................................. 13

ITEM L1-A ANTENNA GAIN PROFILE ............................................................. 13

ITEM L2-B G/T CALCULATIONS....................................................................... 14

ITEM L3-B EIRP CALCULATIONS..................................................................... 15

ITEM L3-D TRANSMITTER OFF POWER LEVEL ............................................ 16

ITEM L3-E SPURIOUS OUTPUTS....................................................................... 18

ITEM L4-A PACKET ERROR RATE.................................................................... 19

ITEM L4-B PACKET ERROR RATE UNDER SHORT TERM REPETITIVE BLOCKAGE
CONDITIONS ............................................................................................ 21

Recommended Test Procedures (RTPs), Front Page & Table of Contents, Page: 6
Section 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM L4-C CARRIER AND FRAME ACQUISITION ........................................ 24

ITEM L4-D CARRIER ACQUISITION UNDER LONG TERM BLOCKAGE


CONDITIONS .................................................................................... 25

ITEM L5-C SIGNALLING CHANNEL CHARACTERISTICS ........................... 27

ITEM L6-A/1 LAND MOBILE ALERT ACCESS CONTROL TEST .................... 28

ITEM L6-A/2 PVT ACCESS CONTROL TEST...................................................... 32

ITEM L6-D COMMON CHANNEL SELECTION................................................ 33

ITEM L6-E OCEAN REGION REGISTRATION ................................................. 35

ITEM L8-A ALERT GENERATOR....................................................................... 37

ITEM L8-B ALERT ACTIVATION ...................................................................... 38

ITEM L9-B PERFORMANCE VERIFICATION AND COMMISSIONING ....... 39

ITEM L11-A VIBRATION TEST ............................................................................ 41

ITEM L11-B SHOCK TEST..................................................................................... 43

ITEM L11-C RAIN TEST ........................................................................................ 44

5. PHASE 1 TESTS FOR LAND PORTABLE EARTH STATIONS.......................................... 1

5.1 INTRODUCTION AND REQUIRED TESTS ........................................................... 1

5.1.1 GENERAL .................................................................................................... 1

5.1.2 REQUIRED TESTS...................................................................................... 1

5.1.3 FUNCTIONAL CHECKS ............................................................................ 1

5.1.4 TESTS FOR EGC RECEPTION .................................................................. 1

5.1.5 TESTS BY ORIGINAL EQUIPMENT MANUFACTURERS.................... 1

5.1.6 ENVIRONMENTAL CONDITIONS TESTS .............................................. 2

5.1.6.1 Test Procedures for Land-Based Portable Earth Stations ............... 2

5.1.7 TEST SET-UP WITH NCS/LES SIMULATOR .......................................... 4

5.1.7.1 Initialisation .................................................................................... 4

5.1.7.2 Set-up of calls using NCS/LES simulator....................................... 7

5.1.7.3 Other functions ............................................................................... 7

5.2 TEST PROCEDURES .............................................................................................. 12

ITEM P1-A ANTENNA GAIN PROFILE........................................................... 12

Recommended Test Procedures (RTPs), Front Page & Table of Contents, Page: 7
Section 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM P2-B G/T CALCULATIONS .................................................................... 13

ITEM P3-B EIRP CALCULATIONS.................................................................. 14

ITEM P3-E SPURIOUS OUTPUTS.................................................................... 15

ITEM P4-A PACKET ERROR RATE................................................................. 17

ITEM P4-B CARRIER AND FRAME ACQUISITION...................................... 19

ITEM P6-A/1 LAND MOBILE ALERT ACCESS CONTROL TEST .................. 20

ITEM P6-A/2 PVT ACCESS CONTROL TEST .................................................... 24

ITEM P6-D COMMON CHANNEL SELECTION............................................. 25

ITEM P6-E OCEAN REGION REGISTRATION .............................................. 27

ITEM P8-A ALERT GENERATOR .................................................................... 29

ITEM P8-B ALERT ACTIVATION.................................................................... 30

ITEM P9-B PERFORMANCE VERIFICATION AND COMMISSIONING .... 31

6. PHASE 1 TESTS FOR EGC RECEIVER EQUIPMENT......................................................... 1

6.1 INTRODUCTION AND REQUIRED TESTS ........................................................... 1

6.1.1 GENERAL .................................................................................................... 1

6.1.2 REQUIRED TESTS...................................................................................... 1

6.1.3 FUNCTIONAL CHECKS ............................................................................ 2

6.1.4 TESTS PERFORMED BY ORIGINAL EQUIPMENT MANUFACTURERS 2

6.1.5 ENVIRONMENTAL CONDITIONS TEST ................................................ 2

6.2 TEST PROCEDURES ................................................................................................ 6

ITEM E2-C RECEIVER TUNING ........................................................................ 6

ITEM E4-A CHARACTER CODES...................................................................... 8

ITEM E4-B OUTPUT DEVICE(S)........................................................................ 9

ITEM E4-D MEMORY CAPACITY ................................................................... 11

ITEM E4-E RECEIVER ADDRESSING ............................................................ 15

ITEM E4-F ERROR DETECTION ..................................................................... 25

ITEM E4-G SEQUENCE NUMBER HANDLING ............................................. 28

ITEM E5-A DISTRESS MESSAGES.................................................................. 29

7. TEST SIMULATORS ............................................................................................................... 1

Recommended Test Procedures (RTPs), Front Page & Table of Contents, Page: 8
Section 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

7.1 RECOMMENDED TECHNICAL CHARACTERISTICS......................................... 1

7.1.1 INTRODUCTION ........................................................................................ 1

7.1.2 SIGNAL CHARACTERISTICS................................................................... 1

7.1.3 PACKET FORMATS ................................................................................... 3

7.1.4 ACCESS & SIGNALLING PROTOCOL/MESSAGE TRANSFER ........... 3

7.1.5 INTERFACES AND INPUT/OUTPUT FACILITIES ................................. 3

7.2 NCS/LES SIMULATOR FUNCTIONAL TEST REQUIREMENTS ........................ 4

7.2.1 GENERAL .................................................................................................... 4

7.2.2 TRANSMISSION ......................................................................................... 4

7.2.3 RECEPTION................................................................................................. 5

7.2.4 OPERATORS FACILITIES ......................................................................... 5

7.3 CHANNEL SIMULATORS FUNCTIONAL TEST REQUIREMENTS................... 5

8. PHASE II TESTS ...................................................................................................................... 1

8.1 INTRODUCTION AND REQUIRED TESTS ........................................................... 1

8.1.1 Introduction................................................................................................... 1

8.1.2 Test arrangements ......................................................................................... 1

8.1.2.1 Test arrangements for Data Reporting and Polling......................... 2

8.1.3 Required Tests............................................................................................... 3

8.2 TEST PROCEDURES ................................................................................................ 5

ITEM 21-A OCEAN REGION REGISTRATION ................................................ 9

ITEM 21-B PERFORMANCE VERIFICATION................................................ 11

ITEM 22-A TO-MOBILE MESSAGE TRANSFER ........................................... 13

ITEM 22-B FROM-MOBILE MESSAGE TRANSFER ..................................... 14

ITEM 22-C OFF-LINE OPERATION................................................................. 16

ITEM 22-D FORCED CLEARING ..................................................................... 18

ITEM 23-A DISTRESS ALERT TRANSMISSION ........................................... 20

ITEM 23-B DISTRESS MESSAGE TRANSMISSION...................................... 22

ITEM 24-A LOG-OUT AND LOG-IN................................................................ 24

Recommended Test Procedures (RTPs), Front Page & Table of Contents, Page: 9
Section 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 25-A ALTERNATIVE NETWORK SERVICES: FROM-MOBILE MESSAGE


TRANSFER...................................................................................... 25

ITEM 25-B ALTERNATIVE NETWORK SERVICES - X.400: FROM-MOBILE


MESSAGE TRANSFER .................................................................. 26

ITEM 26-A DOWNLOADING AND DELETING DNIDs ................................ 28

ITEM 26-B DATA TRANSMISSION ................................................................ 31

ITEM 26-C INITIATING DATA REPORTS AT MES ...................................... 32

ITEM 26-D INITIATING UNRESERVED REPORTS AS REQUIRED IN [RESPONSE]


FIELD............................................................................................... 33

ITEM 26-E PROGRAMMING UNRSERVED DATA REPORTING ............... 34

ITEM 26-F INITIATING UNRESERVED DATA REPORTING ..................... 35

ITEM 26-G STOPPING UNRESERVED DATA REPORTING ........................ 36

ITEM 26-H INTERRUPTIONS TO UNRSERVED DATA REPORTING ........ 38

ITEM 26-I PROGRAMMING RESERVED DATA REPORTING................... 39

ITEM 26-J INITIATING RESERVED DATA REPORTING ........................... 40

ITEM 26-K INTERRUPTIONS TO RESERVED DATA REPORTING ........... 41

ITEM 26-L STOPPING RESERVED DATA REPORTING .............................. 42

ITEM 26-M DATA REPORTING IN DEMAND ASSIGNED MODE .............. 43

ANNEX-A ADDITIONAL PHASE 1TESTS FOR ALL SOLAS SES`S ......... A1

ANNEX –B SUPPLEMENTARY AND SUBSTITUTE TEST PROCEDURE


FOR LOW POWER LAND MOBILE AND SHIP EARTH
STATIONS B1

Recommended Test Procedures (RTPs), Front Page & Table of Contents, Page: 10
Section 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2. PHASE 1 TESTS FOR MOBILE EARTH STATIONS

2.1 INTRODUCTION AND REQUIRED TESTS

2.1.1 GENERAL

The purpose of the Phase I tests is to demonstrate that all the relevant INMARSAT performance requirements
are satisfied over the range of environmental conditions in which the MES is designed to operate. This Section
outlines the minimum requirements of a Phase I test plan and presents test procedures which can be used by
manufacturers in developing their own test plan.

2.1.2 REQUIRED TESTS

As a minimum, the functions and characteristics listed in Table 1 shall be tested with the indicated variations in
the environmental conditions.

For each test in Table 1, reference is made to the relevant technical requirement stated in the Inmarsat-C SDM.

2.1.3 FUNCTIONAL CHECKS

In order to reliably check the signalling protocols for the MES under test and to shorten the time for testing, the
manufacturer shall use a test simulator (NCS/LES simulator) which can simulate the basic responses and signal
processing of an NCS and LES, and a channel simulator to simulate the RF environment in which the MES will
be used (signal impairments such as noise, fading, doppler, interferers etc).

The minimum functional characteristics and technical requirements for test simulators are presented in Section 7
of this document.

2.1.4 TESTS FOR EGC RECEPTION

When the MES model for which type approval is sought, is capable of receiving EGC messages (Class 2 or
Class 3), the applicable tests for EGC receivers shall be performed and checks that the EGC reception does not
interfere with the normal Inmarsat-C operation (according to the Class definition) shall also be done.

The basic test requirements for EGC receivers are presented in Section 6 of this document.

2.1.5 TESTS PERFORMED BY ORIGINAL EQUIPMENT MANUFACTURERS

For some subsystems, the MES manufacturer may not be the original equipment manufacturer (OEM). In such
cases, the MES manufacturer may submit the test procedures and results of the OEM, rather than repeat all tests.
Use of OEM test procedures and results to satisfy the Phase I test requirements may suffice if the procedures
and the results are clearly adequate. The test procedures presented here are suggested as a suitable basis for the
relevant tests to be conducted by the OEM.

Recommended Test Procedures (RTPs), Page: 1


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.1.6 INPUT/OUTPUT DEVICES

In some cases the DTE might not be an integral part of the Internally Mounted Equipment (IME), ie being
connected via the DTE-DCE interface with characteristics as specified in SDM Volume 3, Part 2, Chapter 4,
Section 7.6. In this case, the DTE shall be tested under the applicable environmental conditions, for use with
MES models wishing to comply with the GMDSS requirements.

However, for this purpose, test procedures and results obtained previously in type approving a different MES
model could be provided on the condition that they relate to the same DTE model using the same interface.
INMARSAT may be satisfied with the documentation provided and require no further testing.

2.1.7 ENVIRONMENTAL CONDITIONS TESTS

Each test item is to be performed under the relevant limits of the environmental conditions variations, specified
by the manufacturers. In principle it is desirable to test the MES as a whole system under environmental
condition variations. However, since the environmental test facilities available to the MES manufacturers are
often limited, it is acceptable to perform the tests which require environmental conditions to be applied to both
Externally Mounted Equipment (EME) and the IME in two phases. Where in each phase, the EME and IME
shall be separately checked in turn with the appropriate conditions. A demonstration that the performance will
still remain within the specified limits, when the whole MES system is subject to the environmental conditions
variations, shall be provided.

In order to keep the duration of a test within reasonable limits, when more than one type of environmental
variations are required, the tests may be combined. Therefore it will be acceptable to perform a particular
performance test under two different types of environmental conditions at the same time (eg under high voltage
and high temperature together).

The test procedures outlined in this document indicate the acceptable combinations of environmental conditions.

The procedures presented below assume the environmental conditions limits as stated in SDM Volume 3, Part 2,
Chapter 2, Section 11.

A Procedures for Tests under Temperature and Humidity Variations.

A.0 Start of procedure (ambient conditions).

A.1 Place the equipment under test in the environmental test chamber(s) (temperature and
humidity).

A.2 Power-up the equipment at ambient.

A.3 Define the next Test Environment (TE) as TE1 (T=55°C for EME, T=35°C for IME) with a tr
= x *.

A.4 Change the environmental conditions from ambient TE0 to TE1 and leave the equipment at
these conditions for at least 3 hours or until thermal equilibrium has been attained.

A.5 Carry out the relevant test and record the results.

A.6 Bring the equipment to ambient TE0 in not less than one hour and leave it for at least 3 hours
or until thermal equilibrium has been attained.

Recommended Test Procedures (RTPs), Page: 2


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

A.7 Perform steps A.4 through A.6 with the next test environment as TE1 (T=40°C,RH=95%) and
tr = 3 hours.

A.8 Perform steps A.4 through A.6 with TE1 (T=-35°C for EME, T=0°C for IME) and tr = x *.

A.9 End of procedure.

The diagrams in fig.1 show schematically the test cycle.

TE0 is defined as the ambient conditions, i.e. T=20°-27°C and RH=45-75%.

tr is time it shall take to reach a specified condition (next test environment) from ambient.

* tr = x means at discretion of test engineer.

x >3 hr >1 hr

+55ÞC +55ÞC >3 hr >3 hr >1 hr


+40ÞC
95% RH +35ÞC +40ÞC95
+35ÞC >3 hr % RH

>3 hr
Ambient
>3 hr
0ÞC EME 0ÞC

IME
-35ÞC Test
-35ÞC
x >1 hr

Figure 1Temperature and Humidity Cycles

B Procedures for Tests Under Power Supply Variations.

B.0 Start of procedure.

B.1 Turn on the equipment at nominal power supply conditions.

B.2 Choose as new conditions P1 (V=1.1V0, f=1.06f0)

B.3 Vary the power supply conditions from P0 to P1 and leave the equipment in these conditions
for at least 5 mins.

B.4 Carry out the relevant test and record the results.

B.5 Return to the nominal power supply conditions P0.

B.6 Perform steps B.3 through B.5 with P1 (V=0.9V0, f=0.94f0).

Recommended Test Procedures (RTPs), Page: 3


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

B.7 Perform steps B.3 through B.5 with P1 (V=1.10Vdc) if applicable (DC Mains-powered).

B.8 Perform steps B.3 through B.5 with P1 (V=0.8Vdc) if applicable (DC Mains-powered).

B.9 End of procedure.

P0 is defined as the nominal power supply conditions, i.e. V=V0, f=f0 (and V=Vdc if applicable).

V0 and f0 are the nominal values of mains voltage and frequency respectively and Vdc is the nominal value of
the voltage of the battery (if present).

C Procedures for Tests under Vibration

Three mutually perpendicular major axes shall be defined for the equipment under test: for clarity, in the
following they will be called as X, Y and Z-axis (or, alternatively, in the test procedures they might be referred
to as "front-to-back","left-to-right" and "up-down" directions).

The procedure for the test under vibration consists basically of two parts:

Procedure C.1

Investigation of mechanical response of the equipment and its resonant frequencies; this test needs to be
performed only once (for each major axis) during the Phase I test plan for the externally mounted equipment
(EME), the internally mounted equipment (IME) and the DTE (if applicable). This test is covered by Test Item
11-A.

C.1.0 Start of procedure.

C.1.1 Install the EME on the vibration table to vibrate along the X-axis.

C.1.2 The equipment shall be turned on and vibrated with a swept vibration frequency: the sweep
rate shall be low enough and the amplitude of the vibration excitation as convenient (e.g. 0.4
mm peak) to enable any resonance effects to be noted and investigated as necessary.

C.1.3 Any vibration frequency at which resonance (*) occurs shall be recorded and a plot of the
vibration response over the relevant frequency range should be provided.

C.1.4 At the end of the sweep, the equipment shall remain operational and virtually capable to meet
the performance specifications as set forth in the Technical Requirements Document.

C.1.5 Repeat steps C.1.2 to C.1.4 for the Y-axis.

C.1.6 Repeat steps C.1.2 to C.1.4 for the Z-axis.

C.1.7 Repeat steps C.1.1 to C.1.6 for the IME.

C.1.8 Repeat steps C.1.1 to C.1.6 for the DTE (if applicable).

C.1.9 End of procedure.

(*) Resonant frequencies are assumed to be the vibration frequencies at which the amplification factor, or
Q, is greater than 3; the amplification factor is defined as the ratio of the acceleration of the equipment subject
to a sinusoidal vibration excitation to the acceleration of the excitation itself.

Recommended Test Procedures (RTPs), Page: 4


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

For this test, the use of electrical vibration pickups mounted in the most significant points of the equipment
under test is recommended.

Procedure C.2

For each test item to be performed under vibration conditions, the procedure below shall be followed; in
principle, it should be desirable to test the MES as a whole system under vibration.

However, recognising the fact that usually the vibration test facilities available to the MES manufacturers are
limited, it will be acceptable to perform tests which require vibration conditions to be applied to both EME and
IME in two phases: where in each phase, the EME and IME shall be separately vibrated in turn with the
appropriate amplitude.

A demonstration that the performance will still remain within the specified limits when the whole MES system
is subject to vibration shall be provided.

The procedure below is also applicable to DTE performance testing.

C.2.0 Start of procedure.

C.2.1 Install the equipment under test on the vibration table(s) to vibrate along the X-axis.

C.2.2 Carry out the relevant test at each resonant frequency recorded during step C1.3 of procedure
1 for every vibration frequency sub-range: if no resonant frequencies have been found in a
sub-range, the test will be conducted at the highest frequency;

The frequency sub-ranges and the corresponding vibration amplitudes which shall be applied
are defined below. The vibration frequency, amplitude and test results shall be recorded.

C.2.2 (alternative) Carry out the relevant test using a random vibration with spectrum characteristics
specified below.

C.2.3 Repeat steps C.2.1 to C.2.2 for the Y-axis.

C.2.4 Repeat steps C.2.1 to C.2.2 for the Z-axis.

C.2.5 End of procedure.

Externally Mounted Equipment

Frequency Range Level

2 - 10 Hz 2.54 mm peak amplitude

10-100 Hz 1.0 g acceleration

Internally Mounted Equipment

Frequency Range Level

2 - 15.8 Hz 1.00 mm peak amplitude

15.8-100 Hz 1.0 g acceleration

Reduced Specifications (for printers only)

Recommended Test Procedures (RTPs), Page: 5


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Frequency Range Level

2 - 13.6 Hz 0.4 mm peak amplitude

13.6-100 Hz 0.3 g acceleration

Random Vibration Spectrum (for performance tests)

Frequency Range Spectral Power Density

2 - 100 Hz [0.0005] g2/Hz

D Procedure for Rain Tests

The test shall be carried out by spraying the equipment from all practicable directions with a stream of water
from a nozzle; throughout the test the equipment shall be operating normally.

The test conditions should be the following:

- internal diameter of the nozzle: 12.5 mm;

- delivery rate: 100 l/min;

- water pressure at the nozzle: 100 kPa (1 bar)

(The pressure should be adjusted to achieve the specified delivery rate. At 100 kPa the water should rise freely
for a vertical distance of approximately 8 metres above the nozzle).

D.0 Start of procedure.

D.1 Install the MES equipment under test in a suitable location for the test.

D.2 Turn on the equipment and spray the EME from all practicable directions keeping the distance
from the nozzle to the EME at approximately 3 metres; carry out the relevant tests as required
(for at least 30 mins).

D.3 Stop spraying and inspect the EME for ingress of water.

D.4 End of procedure.

2.1.8 TEST SET-UP WITH NCS/LES SIMULATOR

For further information regarding NCS/LES simulator functions and facilities reference should be made to
Section 7 of this document.

2.1.8.1 INITIALISATION

For each test item requiring an NCS/LES simulator, the following suggested procedure may be performed prior
to testing and it will be referred to in all applicable test procedures as the "Test set-up initialisation".

The parameters to be used for set-up purposes, unless otherwise stated in the procedure, may be as follows:

Notes: - all dimensionless figures in Hex notation unless otherwise indicated;

Recommended Test Procedures (RTPs), Page: 6


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

- xxxx indicates the frame counter;

- chks indicates the checksum (two bytes);

NCS

- at ch. 11080 (f = 1537.700 MHz received by the MES);

- BULLETIN BOARD as (whole packet)

7DFFxxxx5020206CFFFFFF03chks

- SIGNALLING CHANNEL DESCRIPTOR as (whole packet):

6CF036AE00000000000000chks

MES

- NCS Common Channels = ch. 11080 as a minimum;

- Preferred Ocean Region = 1;

- Destination LES = 00710;

- Transmit Service = as required (10 = Telex SFU);

After having entered these data in the simulator (NCS) and MES, transmit NCS TDM frames on the Common
Channel, incrementing the frame number. After synchronisation, the MES should respond with a LOG-IN
REQUEST if in its non-volatile memory there is no data pertaining to the current Ocean Region; if this Normal
Initialisation has already been performed in another test, the log-in phase will be skipped.

Upon reception of the LOG-IN-REQUEST from the MES, the simulator (NCS) shall set the SIGNALLING
CHANNEL DESCRIPTOR to reflect a successful reception of the packet from the MES and transmit within 3
frames a LOG-IN ACKNOWLEDGEMENT.

SIGNALLING CHANNEL DESCRIPTOR:

Will depend on the slot chosen (in this particular case the Signalling Channel available is only one, at ch. 36AE,
corresponding to f = 1646.495 MHz transmitted by the MES); eg. if the LOG-IN REQUEST was in slot 5 then
the Descriptor is

6CF036AE00800000000000chks.

LOGIN ACKNOWLEDGEMENT:

At this point the test is ready to commence, as the MES has received all the required information about the
(simulated) network.

The network, as seen by the MES, may comprises for example 15 LESs in addition to the NCS, with different
operating characteristics:

LES 1 to LES 6

- IDs = 00110 to 00610

Recommended Test Procedures (RTPs), Page: 7


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

- operating with a permanent TDM at chs.

1F40, 1F42, 232E, 27A4, 2AF8 and 2F14 (f =

1530.000, 1530.005, 1532.515, 1535.370, 1537.500 and

1540.130 MHz) on an operational satellite;

- 600 sym/s RTN link operation;

- in service and clear;

- all Services offered;

LES 7 to LES 10:

- IDs = 00710 to 01010

- operating with a permanent TDM at chs.

32F2, 35AE, 36AE and 36B0 (f = 1542.605, 1544.355, 1544.995 and

1545.000 MHz) on an operational satellite

- 1200 sym/s RTN link operation;

- in service and clear;

- all Services offered;

LES 11:

- ID = 01110

- operating with a demand-assigned TDM on an operational satellite;

- 600 sym/s RTN link operation;

- in service and clear;

- all Services offered;

LES 12:

- ID = 01210

- operating with a demand-assigned TDM on an operational satellite;

- 1200 sym/s RTN link operation;

- in service and clear;

- all Services offered;

LES 13:

- ID = 01310

Recommended Test Procedures (RTPs), Page: 8


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

- operating with a demand-assigned TDM on a spare satellite;

- out of service;

- in service and clear;

- all Services offered;

LES 14:

- ID = 01410

- operating with a permanent TDM at ch. 232E (f = 1532.515 MHz) on a spare satellite;

- 600 sym/s RTN link operation;

- in service and congested;

- Distress alerting, Safetynet, Std. C traffic, Telex SF and Fleetnet only;

LES 15:

- ID = 01510

- operating with a permanent TDM at ch. 27A4 (f = 1535.370 MHz) on a spare satellite;

- out of service

2.1.8.2 SET-UP OF CALLS USING NCS/LES SIMULATOR

a. For checking purposes

Whenever a To-Mobile message transfer has to be initiated, the simulator will send (in an NCS frame) an
ANNOUNCEMENT related to a message of one line of QBF (56 characters) to be transferred from LES 7.

b. From-Mobile message transfers

The MES will initiate the call by sending an ASSIGNMENT REQUEST to LES 7. Upon reception of the
ASSIGNMENT REQUEST from the MES, the simulator (LES) shall set the SIGNALLING CHANNEL
DESCRIPTOR to reflect a successful reception of the packet from the MES (eg. if the ASSIGNMENT
REQUEST was received in slot 10 then the Descriptor is 6CF036AE00002000000000chks ) and transmit within
7 frames a LOGICAL CHANNEL ASSIGNMENT.

This LOGICAL CHANNEL ASSIGNMENT is for an MES Message at ch. 11110, with a frame offset of 2
frames and slot no. 1; the test message from the MES is based on one frame (10368 symbols, interleaver size N
= 4) transmission.

2.1.8.3 OTHER FUNCTIONS

a. Distress Alerting

Depending upon the destination LES selected, the MES will send the distress alert packet either to the LES
(permanent TDM) or the NCS (demand assigned TDM). Selection of parameters is not specified here.

Recommended Test Procedures (RTPs), Page: 9


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The NCS/LES simulator should be able to respond with a Distress Alert Acknowledgement set up for the MES
ID.

b. Performance Verification Testing

For conducting PVTs the LES simulator should be set up with a suitable test message, ie the 512 bit test pattern
suggested in SDM Volume 3, Part 2, Chapter 2, section 6.3.3.1. It should also be possible to change this to a
longer message of approximately 4 kbytes.

c. EGC Messages

For testing the EGC functions of EGC receivers and Class 2 and 3 Inmarsat-C MESs, the simulator should be
set up to allow the assembly and insertion of single and double header EGC packets into frames.

d. Continuation Packets

It should be possible to fill TDM frames with dummy packets and/or EGC packets and force relevant signalling
and data packets to be spilt across frames as continuation packets A and B in order to verify that the MES will
detect and respond to such packets.

Recommended Test Procedures (RTPs), Page: 10


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

TABLE 1 : PHASE 1 TEST PLAN

ITEM TEST DESIGNATION A T H P V SDM REF

1 ANTENNA TESTS

1-A Gain Profile X Chap 2: 3.2.1, 3.3.1, 3.4.1

1-B Polarisation and Axial Ratio X Chap 2: 3.2.2, 3.2.3

2 RECEIVING SYSTEM TESTS

2-A Noise Temperature X Chap 2: 3.3.1

2-B G/T Calculations Chap 2: 3.3.1

2-C Tuning X X Chap 2: 3.3.4, 6.3.1

2-D Selectivity X X X Chap 2: 4.3

3 TRANSMITTING SYSTEM TESTS

3-A Output Power and Frequency Response X X X X Chap 2: 3.4.1, 3.4.9

3-B EIRP Calculations Chap 2: 3.4.1

3-C Transmitted Spectrum X Chap 2: 3.4.2

3-D Transmitter Off Power Level X X X X Chap 2: 3.4.3

3-E Spurious Outputs X X X X Chap 2: 3.4.4

3-F Harmonics Outputs X X Chap 2: 3.4.5

3-G Phase Noise X X X Chap 2: 3.4.6

3-H Tuning X X Chap 2: 3.4.7

3-I Frequency Accuracy and Stability X X X X Chap 2: 3.4.8

4 RECEIVER PERFORMANCE TESTS

4-A Packet Error Rate X X X X X Chap 2: 3.3.3, 4.4, 4.5

4-B Carrier and Frame Acquisition X X X X X Chap 2: 4.4, 4.6

5 TRANSMITTER PERFORMANCE TESTS

5-A Modulation Characteristics X X X Chap 2: 5.1

5-B First Generation Operation X Chap 2: 5.2

5-C Signalling Channel Characteristics X Chap 2: 5.3

5-D Message Channel Characteristics X Chap 2: 5.4

5-E Alternative Network Protocols - Sig chan character X Vol 4: Chapter 4

5-F Alternative Network Protocols - Msg chan character X Vol 4 : Chapter 5

Recommended Test Procedures (RTPs), Page: 11


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

5-G Special Access Codes - Signalling channel character X Vol 4: Chapter 4

ITEM TEST DESIGNATION A T H P V SDM REF

5-H Special Access Code - Message channel character X Vol 4 : Chapter 5

5-I X.400 addressing - Signalling channel character X Vol 4: Chapter 4

5-J X.400 addressing - Message channel character X Vol 4 : Chapter 5

6 ACCESS CONTROL TESTS

6-A General Access Control X Chap 2: 6.1

6-A/1 Polling and Data Reporting X Chap.3

6-B TDMA Synchronization X X Chap 2: 6.2.1

6-C Random Access X Chap 2: 6.2.2

6-D Common Channel Selection X Chap 2: 6.3

6-E Region Registration Procedures X Chap 2: 6.5

6-F Idle and Busy Conditions X Chap 2: 6.6

7 MESSAGE PROCESSING

7-A Character Codes X Chap 2: 7.2

7-B Display Devices X X X X X Chap 2: 7.3

7-C Keyboard X X X X X Chap 2: 7.4

7-D MES Memory Capacity X X X Chap 2: 7.5

7-E DCE/DTE Interface Characteristics X X X Chap 2: 7.6.1, Chap. 4: Sect.3

7-F Control Codes X Chap 2: 7.6.3, Chap. 4

8 DISTRESS ALERTING FUNCTIONS

None in this section. See Section 3, 4 or 5 if necessary.

9 TESTING FUNCTIONS

9-A Fail-Safe and Monitoring X X Chap 2: 9.1, 9.2

9-B Performance Verification and Commissioning X Chap 2: 9.3

10 ELECTROMAGNETIC COMPATIBILITY

10-A Mains Conducted Spurious Emissions X Chap 2: 10.2

11 PHYSICAL CHARACTERISTICS TESTS

11-A Vibration Frequency Response X Chap 2: 11.2

11-B Rain Test X Chap 2: 11.2

Notes:

Recommended Test Procedures (RTPs), Page: 12


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

A: ambient temperature

T: temperature

H: humidity

P: power

V: vibration

SDM REF: SDM Volume 3, Part 2, Chapter and section number

Recommended Test Procedures (RTPs), Page: 13


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

2.2 TEST PROCEDURES

ITEM 1-A ANTENNA GAIN PROFILE

1 PURPOSE OF THE TEST

The purpose of the test is to measure the antenna gain profile in elevation and azimuth over the
required frequency ranges. The results are to be used in Test Items 2-B and 3-B to show that the G/T
and EIRP requirements are met. Refer to SDM Volume 3, Part 2, Chapter 2, Sections 3.3.1 and 3.4.1.

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

TEST ANTENNA
POSITIONER
(eg. AZIMUTH TEST SOURCE
OVER ELEVATION) ANTENNA ANTENNA

SOURCE
POLARISATION
ROTATOR

POSITION
TEST RANGE
TEST POSITION SOURCE
CONTROL OR
RECEIVER SENSORS CONTROL
ANECHOIC
CHAMBER

PATTERN
RECORDER

Figure 1-A

Notes:

Recommended Test Procedures (RTPs), Page: 14


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

- If a radome is used under normal operation conditions the test should be performed with the
radome fitted.

- A useful guide to antenna testing may be found in the document IEEE Standard Test
Procedures for Antennas (IEEE Std 149-1979).

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) Signal source covering 1530 - 1545 MHz and 1626.5 - 1646.5 MHz;

(b) Test range or anechoic chamber with low reflections over the 1530 - 1646.5 MHz frequency
range;

(c) Source antenna;

(d) Standard gain antenna (RHCP or linearly polarised);

(e) Test receiver and pattern plotting equipment;

(f) Scalar network analyzer with SWR bridge;

(g) Antenna positioner and controller.

6 TEST PROCEDURE

(a) Introduction

The antenna gain specified in SDM Volume 3, Part 2, Chapter 2, Section 3.2.1, is the antenna partial
gain for right hand circular polarization. In other words the gain is referred to a hypothetical, right
hand circularly polarized isotropic antenna.

The measurement of the gain of the test antenna may be determined by substituting the antenna under
test for a calibrated, or standard gain, antenna. The gain of the antenna under test is:

⎧⎪Pr(θ,φ)⎫⎪
Gt(θ,φ) = Gs + 10 Log10⎨ Ps ⎬ dBi
⎪⎩ ⎪⎭

where Gs is the power gain of the standard gain antenna (in dBi), Pr is the power received with the test
antenna, and Ps is the power received with the standard gain antenna.

The results of Test Item 1-B must be combined with Test Item 1-A in order to determine the actual
RHCP antenna gain profile and the gain uncertainty. The gain required is the partial RHCP gain (in
dBci) and two possible ways of measuring this quantity are described below in (b) and (c).

(b) RHCP Source Antenna

Using a RHCP source antenna there will be an uncertainty in the measured gain due to the axial ratios
and arbitrary polarization ellipse orientations of the source, standard gain and test antennas. At any
point on the pattern, this uncertainty may be calculated as:

⎧ (1 + r12 )(1 + r 22 ) + 4r1 r2 ⎫


dG+ = 10 Log10 ⎨ 2 2 ⎬ dB
⎩ 2(1 + r1 )(1 + r 2 ) ⎭

Recommended Test Procedures (RTPs), Page: 15


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

⎧(1+ r 21 )(1 + r 22 ) + 4r1 r 2 + (1- r 21 )(1 - r 22 ) ⎫


dG- = 10 Log10 ⎨ ⎬ dB
⎩ 2(1+ r21 )(1 + r 22 ) ⎭
where r1 is the axial ratio (in a particular direction) of the test or substituted standard gain antenna, and
r2 is the axial ratio of the RHCP source antenna in the direction of the antenna under test, generally on
axis. The measured antenna gain will therefore lie between G+dG+, and G+dG- where G is the actual
antenna gain. Clearly it is desirable to minimize this uncertainty, therefore the source and standard
gain antennas should have very good axial ratios over the frequency range of interest (preferably < 1
dB).

(c) Rotatable Linearly Polarized Source Antenna

If a linearly polarized standard gain antenna is used as the source antenna, the total gain at any point on
the pattern may be found from:

Gt(θ,φ)dB = 10Log10{Gtv(θ,φ) + Gth(θ,φ)}

where Gtv and Gth are the partial power gains with respect to vertical and horizontal linear
polarizations respectively. This is not however the RHCP partial gain as required for this test. To
obtain the RHCP partial gain a correction factor is applied to the total gain. The RHCP partial gain is:

⎧ (1 + r t ( θ , φ )) 2 ⎫
Grhcp(θ , φ )dB = Gr(θ , φ )dB + 10Log10 ⎨ ⎬
⎩ 2(1 + r t (θ , φ )) ⎭
2

where rt is the axial ratio of the antenna under test. A separate verification is necessary to ensure that
the antenna is right hand and not left hand circularly polarized. If the axial ratio is better than 6 dB
then the correction factor is less than 0.5 dB (ie, Gt ≥ Grhcp ≥ Gt-0.5).

(d) Tests to be performed

The pattern measurements shall be performed using a suitable antenna test range or anechoic chamber.
All patterns should be checked at six frequencies, e.g. 1530.0, 1537.5, 1545.0, 1626.5, 1636.5, 1646.5
MHz. As a minimum at least two orthogonal elevation cuts over ±180° and at least three 360° azimuth
cuts at constant elevation angles (e.g. -15°, +5°, +60°) should be taken at each frequency. A check
should be performed to ensure that no major pattern irregularities exist over the coverage region.

(e) SWR measurements

It is recommended that, as part of this test, a swept frequency SWR measurement of the antenna should
be performed over the 1530 - 1545 MHz and 1626.5 - 1646.5 MHz ranges.

7 PASS/FAIL CRITERIA

The results will be used together with the results from Test Item 2-A in the G/T calculations (refer to
Test Item 2-B) and Test Item 3-A in the EIRP calculations (refer to Test Item 3-B) to demonstrate that
the G/T and EIRP will stay within the specified limits.

Recommended Test Procedures (RTPs), Page: 16


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 1-B POLARISATION AND AXIAL RATIO

1 PURPOSE OF THE TEST

The test shall demonstrate that the antenna polarisation and axial ratio comply with the requirements
stated in SDM Volume 3, Chapter 2, Sections 3.2.2 and 3.2.3.

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

Refer to figure 1-A.

Note: If a radome is used under normal operation conditions these characteristics should be
measured with the radome fitted.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

As for Test Item 1-A, with either a linear polarised source antenna and means for rotating the antenna
about its beam axis or, two source antennas (RHCP and LHCP).

6 TEST PROCEDURE

As a minimum, pattern cuts and frequencies should correspond to those suggested in Test Item 1-A.
To measure the antenna axial ratio, two alternative ways, described below, are possible:

(a) Rotatable Linearly Polarized Source Antenna

For any single point on the antenna pattern (q,f) the linearly polarized source antenna may be rotated
for maximum power transfer between the source and test antenna. The power measured at the last
(receiving) antenna is recorded as PA. The source antenna is then rotated by 90° and the power
measured again and recorded as PB. The axial ratio at this point is:

PA
AR(θ,φ) = 10Log10 ⎛ PB ⎞ dB
⎝ ⎠

To obtain axial ratio measurements at the same point as the gain measurements, the patterns may be
measured with the linearly polarized source antenna continuously rotating about its main beam axis. If
the rate of rotation is W then the following conditions must be satisfied;

dθ dφ
dt << Ω and dt << Ω rad/s
This measurement may be combined with Test Item 1-A.

(b) RHCP and LHCP Source Antennas

Using a pair of identical RHCP and LHCP source antennas each with a known boresight axial ratio,
two sets of patterns can be measured for the test antenna; one for RHCP and the other for LHCP.

Recommended Test Procedures (RTPs), Page: 17


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Assuming that the axial ratios of the two source antennas are good (ie, < 2dB and preferably < 1dB on
boresight), then at any point (θ,φ) on the pattern the difference in the measured power levels is the
cross-polarization ratio:

PL
X(θ,φ) = 10Log10 ⎛ PR ⎞ dB
⎝ ⎠

The axial ratio may be calculated from the cross polarization ratio from:

⎧1+ 10 X 20 ⎫
AR(θ , φ ) = 20 Log10 ⎨ X 20 ⎬
⎩1− 10 ⎭

Note that if X is negative then the antenna is RHCP at that point; if X is positive the antenna is LHCP
and if X is 0 then the antenna is linearly polarized.

As in (a), these measurements can be combined with Test Item 1-A.

7 PASS/FAIL CRITERIA

The polarisation shall be right hand circular as in the definition of CCIR Rec.573 and the axial ratio not
greater than 2 (AR≤6 dB) for any directions 5°- 90° in elevation and 0°- 360° in azimuth.

Localized degradations in axial ratio beyond the specified requirements may be acceptable if there is
sufficient gain margin in the antenna over that region.

Recommended Test Procedures (RTPs), Page: 18


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 2-A RECEIVING SYSTEM NOISE TEMPERATURE

1 PURPOSE

The test shall determine the receiving system (antenna and receiver) noise temperature. The result will
be used in Test Item 2-B, along with the antenna gain measurements, to verify the G/T of the MES.
Refer to SDM Volume 3, Part 2, Chapter 2, section 3.3.1.

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

MES
ANTENNA

DUMMY MES L-BAND PWR METER


LOAD RECEIVER OR
NF METER

NOISE
SOURCE

Figure 2-A

Notes: The antenna must be mounted such that it has an unobstructed view of clear sky between the
zenith and 5° of the horizon. Any radome or antenna cover must be fitted and should be dry.
Ideally the ground surface should simulate the reflection/absorption characteristics of seawater
as far as possible. Justifiable corrections may be applied to the result to account for the
difference in the ground surface characteristics.

Recommended Test Procedures (RTPs), Page: 19


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) Noise figure meter or power meter (digital)

(b) Dummy load (Ambient temperature)

(c) Noise source: (this can be either a noise source with a calibrated excess noise ratio or, for
example, a liquid nitrogen cooled load).

6 TEST PROCEDURE

(a) If the unit under test is designed for full duplex operation, measurements must be made with
the transmitter and HPA operating at nominal power, through the diplexer, and into a dummy
load.

(b) Any diplexer, cables or other possible sources of attenuation between the antenna and receiver
must be defined for all steps of this test as either part of the antenna unit or as part of the
receiver. This definition may not change during this test. If any such possible sources of
attenuation are optional, a worst case attenuation (e.g. maximum allowed length of cable)
between antenna and receiver must be used.

(c) Disable any AGC circuit in the receiver IF. Tune the receiver to 1530MHz.

(d) Connect the antenna to the receiver. Measure and record the noise power, Pa.

(e) Connect the noise source to the receiver. Measure and record the noise power, Pn.

(f) Connect the ambient load to the receiver. Measure and record the noise power, Po.

(g) Calculate the Y-factors according to the formula:

Pn
Y1 = P
a

Po
Y2 = P
a

Po
Y3 = P
n
(h) Calculate the system noise temperature as follows:

since

Tn+Tr To+Tr To+Tr


Y1 = Ta+Tr Y2 = Ta+Tr and Y3 = Tn+Tr

where

Tn = Temperature of noise source;


To = Ambient Temperature;
Ta = Antenna noise Temperature, and
Tr = Receiver noise temperature;

Recommended Test Procedures (RTPs), Page: 20


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

then

To-Y3Tn
Tr = Y3-1

To-Tn
Ta = Y2-Y1 -Tr

and

T(system) = Ta+Tr

(i) Repeat steps (d) through (h) with the receiver tuned to 1537.5 MHz and to 1545 MHz.

7 PASS/FAIL CRITERIA

Pass/fail will be determined in the G/T calculation, Item 2-B.

Example: If the antenna gain at 90° elevation (zenith) is 0dBi, then system noise temperature must be
less than 282K for the receiver to be within the G/T specification.

Recommended Test Procedures (RTPs), Page: 21


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 2-B G/T CALCULATIONS

1 PURPOSE

The calculations shall demonstrate that the G/T of the MES complies with the requirements stated in
SDM Volume 3, Part 2, Chapter 2, Section 3.3.1.

2 APPLICABILITY

All classes of MESs.

3 PROCEDURE

The results from the Test Items 1-A and 2-A will be used in the following calculations.

(a) Convert all the results for the antenna gain obtained in Test Item 1-A at 1530,1537.5 and 1545
MHz from dBi to dBK-1:

G/T(dBK-1) = G(dBi) - 10Log10(Ta+Tr)

where: Ta is the antenna noise temperature from Test Item 2-A and Tr is the receiver noise
temperature at the appropriate frequency.

(b) Compare the converted values with the minimum G/T profile shown in Figure 2-2 of SDM
Volume 3, Part 2, Chapter 2.

4 PASS/FAIL CRITERIA

The antenna G/T as obtained in step a. shall be greater than the superimposed mask for any elevation
angle between -15° and 90° and any azimuth direction.

Models of MES found to exhibit marginal G/T performance may still be acceptable if the manufacturer
is able to demonstrate that the demodulator/decoder performance is such that the equipment is able to
compensate the degradation in G/T performance (and still meet the output performance/Packet Error
Rate of SDM Volume 3, Part 2, Chapter 2, Section 4.5 with all relevant signal impairments.

Recommended Test Procedures (RTPs), Page: 22


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 2-C RECEIVER TUNING

1 PURPOSE

The test shall verify that the receiver complies with the requirements of SDM Volume 3, Part 2,
Chapter 2, Section 3.3.4. This will ensure that the receiver will tune to any channel in the band 1530.0
to 1545.0MHz, in increments of 5kHz; and that the frequency to which the receiver tunes corresponds
to the correct channel number. Refer to SDM Volume 3, Part 2, Chapter 2, section 6.3.1.

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

Temperature

4 TEST SET-UP

NCS/LES MES
SIMULATOR

TEMPERATURE CHAMBER

CONTROLLER DTE

Figure 2-C

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES Simulator

(b) Temperature chamber

6 PROCEDURE

(a) Initialise the set-up

Recommended Test Procedures (RTPs), Page: 23


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(b) Assign the MES to receive a message from a LES operating at 1530MHz (Channel 800010,
1F4016).

(c) Transmit one line of QBF message. Check that the MES receives the message error-free.

(d) Repeat with LES channels at frequencies listed below:

Frequency Channel Number

(MHz) (Decimal) (Hexadecimal)

----------- -------- -------

1530.000 8000 1F40

1530.005 8002 1F42

1532.515 9006 232E

1535.370 10148 27A4

1537.500 11000 2AF8

1540.130 12052 2F14

1542.605 13042 32F2

1544.355 13742 35AE

1544.995 13998 36AE

1545.000 14000 36B0

(e) Repeat steps (b) to (d) at high and low temperature.

7 PASS/FAIL CRITERIA

The QBF line must be received correctly at all frequencies.

Recommended Test Procedures (RTPs), Page: 24


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 2-D RECEIVER SELECTIVITY

1 PURPOSE

The test shall verify that the predetection filter of the receiver complies with the requirements of SDM
Volume 3, Part 2, Chapter 2, Section 4.3.

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

Temperature

Humidity

4 TEST SET-UP

ENVIRONMENTAL CHAMBER

IF TEST* SPECTRUM
ANALYSER

GENERATOR
MES DCE

*Note: IF Test Point after all IF filtering DTE

Figure 2-D

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) Spectrum analyzer

(b) Signal generator

(c) Environmental chamber(s) (temperature and humidity)

6 PROCEDURE

(a) Disable any AGC circuitry in the MES.

Recommended Test Procedures (RTPs), Page: 25


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(b) Artificially force the MES receiver to tune to 1537.5MHz (Channel Number 1100010 or
2AE816 ).

(c) Adjust the signal generator to 1537.5MHz at a level within the linear range of the receiver.
Record the signal generator level.

(d) Sweep the signal generator +50kHz, and plot the test point output. Define as 0dB the output
level corresponding to 1537.500MHz at the input.

(e) Repeat at 0°C, +40°C with 95% relative humidity and +35°C.

7 PASS/FAIL CRITERIA

Within the limits depicted in SDM Volume 3, Part 2, Chapter 2, Figure 2-7.

Recommended Test Procedures (RTPs), Page: 26


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 3-A OUTPUT POWER & FREQUENCY RESPONSE

1 PURPOSE

The test shall measure the stability of the transmitter output power level over the Inmarsat-C transmit
band and environmental variations. The results of this test will be used in the calculations of Test Item
3-B to verify that the Inmarsat-C unit complies with the EIRP requirements of SDM Volume 3, Part 2,
Chapter 2, Section 3.4.1. Refer also to SDM Volume 3, Part 2, Chapter 2, section 3.4.9.

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

Temperature

Humidity

Power supply

4 TEST SET-UP

ENVIRONMENTAL CHAMBER

IF TEST* SPECTRUM
ANALYSER

GENERATOR
MES DCE

*Note: IF Test Point after all IF filtering DTE

Figure 3-A

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES Simulator.

(b) Power meter, of known accuracy over the desired frequency and level range.

Recommended Test Procedures (RTPs), Page: 27


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(c) Power Supplies in which voltage and/or frequency can be varied. One appropriate power
supply is required for each of the power interfaces which may be supplied with the Inmarsat-C
unit (i.e. AC mains, DC mains, battery).

(d) Environmental chamber(s) (temperature and humidity)

(e) Coupling Network: This may consist of directional coupler, circulator, combiner, attenuator
and/or load.

6 TEST PROCEDURE

(a) Zero and calibrate the power meter.

(b) If the components in the coupling network are not sufficiently broadband, calibrate coupling
network over the frequency range 1626.5 to 1646.5 MHz. Attach this curve to the data sheets.

(c) Connect the test equipment and MES as shown in figure 3-A.

(d) Initialise the set-up.

(e) Prepare a maximum length message (i.e. maximum allowable for this model) at the MES.

(f) Initiate an MES transmission, assigning the MES (by the simulator) to ch.1000010

(g) Adjust the HPA to maximum power (if possible). Measure and record the output level.

(h) Adjust the HPA to minimum power (if possible). Measure and record the output level.

(i) Set the HPA to nominal level. Measure and record. DO NOT RE-ADJUST THE
TRANSMITTER POWER LEVEL FOR THE REMAINDER OF THIS TEST.

(j) Record the power level every three minutes for a duration of at least twice the maximum
length message. When the MES stops transmitting because it has completed sending the
message, immediately initiate another maximum length transmission.

(k) Reduce the MES message length to approximately 1 kbyte. Initiate a transmission channel
600010 (177016, 1626.5MHz). Measure and record the power level. Repeat for channels
700010, 800010, 900010, 1000010, 1100010, 1200010, 1300010 and 1400010.

(l) With nominal power supply voltage and frequency, send a request and assign the MES to
channel 1000010. Measure and record the power level.

(m) Measure and record the power level.

(n) Repeat step (m) at high power supply and at low power supply.

(o) Repeat steps (m) and (n) for all types of power supply for which interfaces may be supplied
with the MES.

(p) Repeat steps (j), (m), (n) and (o) with the EME at -35°C, 0°C, 40°C with 95% relative
humidity, +55°C, and again at ambient, according to the Environmental Conditions tests
procedures in Section 2.1.7.

Recommended Test Procedures (RTPs), Page: 28


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(q) Place the IME in an environmental chamber at ambient conditions. Prepare a relatively short
message, initiate a transmission, and record power level. Repeat with the IME at its minimum
rated temperature, maximum rated temperature, with 95% relative humidity, and again at
ambient conditions. Throughout this step the EME must be kept at ambient conditions.

7 PASS/FAIL CRITERIA

Pass/fail will be determined in the EIRP calculations (Test Item 3-B).

Recommended Test Procedures (RTPs), Page: 29


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 3-B EIRP CALCULATIONS

1 PURPOSE

The calculations shall demonstrate that the maximum and minimum EIRP, calculated from results of
Test Items 1-A and 3-A, complies with the requirements of SDM Volume 3, Part 2, Chapter 2, Section
3.4.1

2 APPLICABILITY

All classes of MES.

3 PROCEDURE

Calculate the maximum and minimum transmitter EIRP, using the results from Test Items 1-A and 3-A.

First, the maximum and minimum power to the antenna are to be calculated, taking into account:

Ps = nominal power setting at HPA;

Lm = loss due to mismatch of antenna;

dPf = variation of power across the transmit frequency band;

dPT = variation of power output due to effects of temperature and humidity and
variations in the power supply;

dPt = variation in HPA output power over time, and

dPIME = variation in output power due to effects of the IME.

The formulae are presented in Item 3-B, Test Data Sheet.

Secondly, the curves of maximum and minimum EIRP are to be plotted, using the above calculation
along with the antenna gain profile.

4 PASS/FAIL CRITERIA

The plots resulting from these calculations must fall within the limits of SDM Volume 3, Part 2,
Chapter 2, Figure 2-3.

Recommended Test Procedures (RTPs), Page: 30


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 3-C TRANSMITTED SPECTRUM

1 PURPOSE

The test shall verify that the transmitter spectrum corresponds to that of an unfiltered BPSK spectrum
with minimum distortion and complies with the requirements of SDM Volume 3, Part 2, Chapter 2,
Section 3.4.2.

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

NCS/LES
COUPLER
SIMULATOR MES

SPECTRUM
ANALYSER DTE
CONTROLLER

Figure 3-C

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) Spectrum analyser

(b) Camera or plotter

(c) NCS/LES simulator

(d) Coupling network

6 TEST PROCEDURE

(a) Adjust the spectrum analyser for 100kHz span, 1kHz bandwidth, video filtering off, sweep
time as slow as practical. Initialise the set-up.

(b) Initiate a From-Mobile message transmission of maximum message length, with a LES
operating on first generation satellite (600 sym/s return link).

Recommended Test Procedures (RTPs), Page: 31


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(c) Plot or photograph the spectrum. Record the difference in level at fc ±48.6kHz from the
centre carrier frequency.

(d) Repeat step (c) with the span of 10 kHz. Record the difference in level at ±4.2 kHz from the
centre carrier frequency.

(e) Repeat steps (b) and (d) with a LES operating on second generation satellite (1200 sym/s
return link).

Notes: Alternative resolution bandwidths and frequency spans may also be used providing the results
may be referred to the requirements.

7 PASS/FAIL CRITERIA

Step (c): at fc ± 4.2 kHz, the difference shall be at least 26dB;

at least 47.5 dB at fc ± 48.6 kHz.

Step (d): at fc ± 4.2 kHz, the difference shall be at least 22dB;

at least 43.5 dB at fc ± 48.6 kHz.

Recommended Test Procedures (RTPs), Page: 32


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 3-D TRANSMITTER OFF POWER LEVEL

1 PURPOSE

The test shall verify that the output power of the transmitter, when in a non-operative state, complies
with the requirements of SDM Volume 3, Part 2, Chapter 2, Section 3.4.3, and to check for "fail-safe"
operation capability, i.e, that no transmission shall occur inadvertently under all realistic conditions.

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

Temperature

Humidity

Power supply

4 TEST SET-UP

ENVIRONMENTAL CHAMBER

POWER COUPLING
METER NETWORK MES

PEAK PWR
DETECTOR POWER
OR SUPPLY DTE
RF DET. WITH
SCOPE

Figure 3-D

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) Power Meter.

(b) Spectrum analyser covering the 1626.5 to 1646.5 MHz frequency range.

(c) Power Supplies in which voltage and/or frequency can be varied. One appropriate power
supply is required for each of the power interfaces which may be supplied with the MES (i.e.
AC mains, DC mains, battery).

(d) Peak power detector, or RF detector connected to storage oscilloscope

(e) Environmental chamber

Recommended Test Procedures (RTPs), Page: 33


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(f) Coupling network.

(g) A spark generator. It is recommended that this should comprise a capacitor of not less than
100 uF in series with a resistor of not more than 10 ohms charged to a voltage of not less than
50 v.

6 TEST PROCEDURE

(a) Set power supply to nominal level. Switch on MES (idle mode). Record actual power at the
antenna (measured power plus coupling loss).

(b) Replace the power meter with the spectrum analyser. Set the spectrum analyser to sweep the
1626.5 to 1646.5 MHz frequency range with a resolution bandwidth of 3 kHz. Record the
trace(s) using a camera or plotter. Note any corrections required for the coupler, EIRP
correction and spectrum analyser noise bandwidth correction factor.

(c) Increase power supply frequency to maximum as shown on the results sheets (if applicable).
Monitor the power meter while slowly (over two seconds minimum) increasing the power
supply voltage to the maximum shown. Record the maximum actual power level at the
antenna.

(d) Decrease power supply frequency to minimum as shown on the results sheets (if applicable).
Monitor the power meter while slowly (over 10 seconds) decreasing the voltage to zero. Then
slowly increase the power supply voltage to nominal. Record the maximum actual power
level at the antenna.

(e) With power supply voltage and frequency at nominal, monitor the peak power meter
disconnecting and reconnecting the power supply five times. The power supply must be
physically disconnected from the MES each time, and not merely switched on and off.
Record any anomalies or increases in the MES output power above its nominal value, onto the
data sheet.

(f) With nominal power supply voltage and frequency, switch the MES off and on ten times in
quick succession. Record any anomalies or increases in the MES output power.

(g) Repeat steps (a) through (f) for all types of power supplies which may be supplied with the
MES.

(h) Repeat steps (a) through (f) at 0°C, 40°C with 95% relative humidity, and at 35°C.

(i) Monitor the peak power meter while performing the following on both the IME and the EME
of the MES. Record any anomalies or transients seen at the MES antenna connector:

i.1 Drop from a height of not less than 10 cm (4 inches) onto a hard surface.

i.2 Apply a shock with a plastic or rubber hammer (with a mass of at least 250g) to the MES in
each of three mutually orthogonal planes.

i.3 Disconnect and reconnect each connector inside the IME and EME. This includes edge and
RF connectors.

i.4 Apply a spark to the MES casing (from 50V source).

Recommended Test Procedures (RTPs), Page: 34


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

7 PASS/FAIL CRITERIA

Under all possible conditions the MES power output (EIRP) and power output transients shall not
exceed -45dBW and -63 dBW in any 3 kHz bandwidth when the transmitter is in a non-operative state.

Recommended Test Procedures (RTPs), Page: 35


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 3-E SPURIOUS OUTPUTS

1 PURPOSE

The test shall verify that the spurious outputs of the transmitter comply with the requirements of SDM
Volume 3, Part 2, Chapter 2, Section 3.4.4.

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

Temperature

Humidity

Vibration

4 TEST SET-UP

ENVIRONMENTAL CHAMBER/VIBRATION TABLE

NCS/LES
COUPLER
SIMULATOR MES

ATTEN-
UATOR

NOTCH SPECTRUM
FILTER ANALYSER
CONTROLLER DTE

Figure 3-E

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator;

(b) Notch filter and calibrated LNA (if necessary for the receive band);

(c) Step attenuators;

(d) Spectrum analyzer(s) capable of tuning from 10MHz to 18GHz;

(e) Coupling network;

(f) Environmental chamber(s) (temperature and humidity); and

Recommended Test Procedures (RTPs), Page: 36


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(g) Vibration table.

6 PROCEDURE

(a) Calibrate the notch filter and the LNA (if used). Attach plots of the filter response from
10MHz to 18GHz and of the LNA response in the band 1530 to 1545 MHz to data sheets. If
the MES diplexer is removed for any part of this test, calibrate it separately and attach
10MHz-18GHz plots to the data sheets. Also attach a plot of the antenna gain (10MHz-
18GHz) if available.

If it is not available, the curve of theoretical maximum antenna gain may be used. This is
shown in figure 3-E/1 as a normalized maximum antenna gain versus frequency plot for a 1
m2 aperture antenna. The actual aperture is calculated from the largest antenna dimension.
For example; if an antenna is 10 cm long, A=0.0078 m2 or -21 dBm2. At 3 GHz the
maximum theoretical gain of a 1 m2 antenna is 30 dBi and for the example antenna the
maximum gain is 30 - 21 = 9 dBi.

Normalized Maximum Antenna Gain versus Frequency

50
Normalized Maximum Gain (dB/m )

40

30 Assumptions:

1. Efficiency = 100 %
20
1 2 3 4 5 6 7 8 910 20 2. Effective Aperture = Physical Aperture
Frequency (GHz)
3. Physical Aperture = p (L/2)2

where L is the major antenna


dimension.

Figure 3-E/1

(b) Measurement in the transmit band (1626.5-1646.5MHz) should be made without the notch
filter.

(c) All data should be taken with a spectrum analyzer bandwidth of 3kHz.

(d) Photograph or plot the transmit spectrum in the frequency range of 1530.0 to 1661.5 MHz.
Two sets of photographs or plots of the spectrum analyzer display are required, each set
showing the spectrum from 1530 to 1661.5MHz. The first set shall be with the transmit
carrier at 1626.5MHz, the second with the carrier at 1646.5MHz. All photographs or plots

Recommended Test Procedures (RTPs), Page: 37


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

must have horizontal and vertical scales labelled, and must indicate the carrier frequency and
whether the diplexer or notch filter was used.

(e) Plot the specification mask on each of the photographs or plots. At each frequency the mask
level is calculated according to the following formula:

Mask level (dBm) = TRD specification (dBW) + 30

+ diplexer loss (if diplexer is removed)

+ attenuator and coupling losses

+ notch filter loss

- antenna gain (or theoretical maximum gain)

+ LNA gain (if LNA present)

(f) With the carrier at 1636.5MHz scan the output spectrum and note on the data sheet all
spurious outputs between 10MHz and 18GHz. For each spurious output frequency, calculate
the specification according to the formula in step (e) above. Photographs or plots are not
required.

(g) For each setting of the spectrum analyzer, note the maximum level of the noise floor onto the
data sheet.

(h) Repeat step (f) under the following conditions:

(i) -35°C (EME)

(ii) 0°C

(iii) +40°C + 95% relative humidity

(iv) +55°C (EME)

(v) vibration - front to back

(vi) vibration - left to right

(vii) vibration - up - down

7 PASS/FAIL CRITERIA

All spurious and noise outputs (excluding harmonics) in the direction of maximum antenna gain must
be below the spectrum envelope defined by the following data points:

Frequency EIRP/3kHz

(MHz) (dBW)

---------------- ------

1530-1545 -130

1611.5 -77

Recommended Test Procedures (RTPs), Page: 38


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1626.5 - 1646.5 -48

1661.5 -77

1751.5 -85

Below 1530 and

above 1751.5 -85

Recommended Test Procedures (RTPs), Page: 39


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 3-F HARMONIC OUTPUTS

1 PURPOSE

The test shall verify that the harmonic content of the transmitter complies with the requirements of
SDM Volume 3, Part 2, Chapter 2, Section 3.4.5

2 APPLICABILITY

All classes of MESs

3 ENVIRONMENTAL CONDITIONS

Normal ambient

Temperature

4 TEST SET-UP

NCS/LES
SIMULATOR COUPLER
MES

ATTENUATOR

SPECTRUM
ANALYSER

CONTROLLER DTE

Figure 3-F

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator

(b) Coupling network

(c) Attenuators

(d) Spectrum analyzer

(e) Temperature chamber

6 PROCEDURE

(a) Initiate a transmission at 1636.5MHz.

(b) Adjust the attenuators such that the carrier is at the spectrum analyzer reference level.

Recommended Test Procedures (RTPs), Page: 40


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(c) Measure and record the level of each of the carrier's 2nd through 11th harmonics.

(d) Repeat the above steps at -35°C (EME), 0°C and +55°C (EME).

(e) Calculate the EIRP of each harmonic on the data sheet. If the antenna gain is unknown at any
frequency, use the maximum theoretical antenna gain given in figure 3-E/1.

7 PASS/FAIL CRITERIA

Each harmonic must be less than -25dBW EIRP.

Recommended Test Procedures (RTPs), Page: 41


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 3-G PHASE NOISE

1 PURPOSE

The test shall verify that the phase noise of the transmit carrier complies with the requirements of SDM
Volume 3, Part 2, Chapter 2, Section 3.4.6.

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

Temperature

Vibration

4 TEST SET UP

ENVIRONMENTAL CHAMBER/VIBRATION TABLE

SPECTRUM MIXER MES


ATTENUATOR
ANALYSER

SIGNAL
GENERATOR

DTE

Figure 3-G

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) Attenuator

(b) Spectrum analyzer, calibrated for noise measurements. This must be either an internal
analyzer feature, allowing the display to be read directly in dB/Hz, or should include sufficient
data on the noise response to permit a calculation.

(c) Low Noise Signal Generator.

(d) Mixer.

Recommended Test Procedures (RTPs), Page: 42


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(e) Environmental chamber

(f) Vibration table

6 PROCEDURE

(a) The transmitter phase noise must be measured in a single sideband only; double sideband
measurements (mixing the carrier to near 0Hz) is not preferred.

(b) The phase noise may be read directly from the carrier for the offset frequency of more than
100 Hz, and from the product of the carrier and a low phase noise signal generator for the
frequency offset between 10 Hz and 100 Hz.

(c) Set up the MES to transmit a CW carrier.

(d) Scan the phase noise between 10Hz and 100kHz from the carrier and plot the result. The
maximum permitted analyzer bandwidth is:

Frequency from Carrier in Hz Analyzer BW in Hz

---------------------------- -----------------

10 - 100 1

100 - 1k 10

1k - 10k 100

10k - 100k 1000

(e) Repeat the above steps under the following conditions:

0°C

35°C

Vibration - front to back

Vibration - left to right

Vibration - up-down

(f) Submit all plots, which must also show the specification mask. Plots should have a
logarithmic frequency scale if possible.

(g) If the spectrum analyzer does not have internal calibration for noise measurements, show the
calculation which arrives at a conversion factor.

(h) If any discrete components are above the specification, the total noise power in the 10Hz to
100kHz range must be calculated or measured and summed to the power of the discrete
components. Submit the calculations.

Recommended Test Procedures (RTPs), Page: 43


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

7 PASS/FAIL CRITERIA

Under all conditions, the continuous noise spectrum must be below the curve in the Inmarsat-C SDM,
Volume 3, Part 2, Chapter 2, Figure 2-5.

If any discrete components are present, the total power in a single sideband between 10Hz and 100kHz
from the carrier must not exceed 0.071rad-rms (-23dBc). The total SSB phase noise power is
calculated as follows:

N
SSB phase noise power (in rad-rms)= C

where N: noise power of continuous plus discrete components (W)

C: power of the carrier (W)

Recommended Test Procedures (RTPs), Page: 44


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 3-H TRANSMITTER TUNING

1 PURPOSE

The test shall verify that the transmitter will tune to the assigned frequency and complies with the
requirements of SDM, Volume 3, Part 2, Chapter 2, Section 3.4.7.

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

Temperature

4 TEST SET-UP

TEMPERATURE CHAMBER

NCS/LES
SIMULATOR COUPLER MES

FREQUENCY
COUNTER
CONTROLLER DTE

Figure 3-H

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator

(b) Frequency counter

(c) Coupling network

(d) Temperature chamber

6 TEST PROCEDURE

(a) Prepare a message at the MES.

(b) Request a channel from the NCS/LES simulator.

(c) Assign the MES to 1636.5 MHz (channel 177016, 600010).

Recommended Test Procedures (RTPs), Page: 45


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(d) Record the frequency of the MES transmission.

(e) Repeat steps a - d for each frequency listed below:

(f) Repeat steps a - e at high and low temperature.

Channel Number

(decimal) (hexadecimal) (MHz)

6000 1770 1626.500


6002 1772 1626.505
7138 1BE2 1629.345
8246 2036 1632.115
10630 2986 1638.075
10632 2988 1638.080
12002 2EE2 1641.505
13998 36AE 1646.495
14000 36B0 1646.500

7 PASS/FAIL CRITERIA

All messages are transmitted on the assigned channel.

Recommended Test Procedures (RTPs), Page: 46


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 3-I TRANSMITTER FREQUENCY STABILITY

1 PURPOSE

The test shall verify that the transmitter frequency stability relative to the NCS TDM complies with the
requirements of SDM, Volume 3, Part 2, Chapter 2, Section 3.4.8.

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

Temperature

Humidity

Power Supply

4 TEST SET-UP

ENVIRONMENTAL CHAMBER

NCS/LES
SIMULATOR COUPLER
MES

FREQUENCY FREQ. POWER


COUNTER REF. SUPPLY

CONTROLLER DTE

Figure 3-I

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator

(b) Frequency reference

(c) Frequency counter

(d) Power supplies in which voltage and/or frequency can be varied. One appropriate power
supply is required for each of the power interfaces which may be supplied with the MES (i.e.
AC mains, DC mains, battery).

Recommended Test Procedures (RTPs), Page: 47


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(e) Coupling network

(f) Environmental chamber

6 TEST PROCEDURE

(a) Modify the MES such that the transmitter will not be modulated by the data and will instead
transmit a CW signal. Transmit a TDM with the NCS/LES simulator

(b) Initiate a transmission from the MES for the time corresponding to the maximum message
length.

(c) Measure and record the transmitter frequency to the nearest 1 Hz.

(d) Repeat steps a), b) and c) shifting the TDM carrier by +850 Hz and -850 Hz from the nominal
frequency.

(e) Repeat steps a), b) and c) with the power supply at high voltage and high frequency (if
applicable) as indicated in the results sheet.

(f) Repeat steps a), b) and c) with the power supply at low voltage and low frequency (if
applicable) as indicated in the results sheet.

(g) Repeat steps a) through e) with all types of power supplies for which interfaces may be
supplied with the MES.

(h) Repeat steps a) through f) at 0°C, 40°C with 95% relative humidity, and at +35°C.

7 PASS/FAIL CRITERIA

The transmitter shall always be within 150 Hz of the nominal, with reference to the TDM stability.

Recommended Test Procedures (RTPs), Page: 48


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 4-A PACKET ERROR RATE

1 PURPOSE OF THE TEST

The test shall verify that the performance of the receiver in terms of packet error rate (PER) is within
the limits specified in SDM, Volume 3, Part 2, Chapter 2, Section 4.5 with all the impairments therein
specified in SDM, Volume 3, Part 2, Chapter 2, section 4.4.

Moreover, the degradation of receiver performance in the presence of out-of-band interfering signals
will be checked according to SDM, Volume 3, Part 2, Chapter 2, Section 3.3.3.

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

Temperature

Humidity

Main power supply

Vibration

4 TEST SET-UP

ENVIRONMENTAL CHAMBER/VIBRATION TABL

NCS/LES CHANNEL
SIMULATOR SIMULATOR MES

POWER
SUPPLY
DTE

CONTROLLER

Figure 4-A

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Channel simulator system comprising (refer to figure 4-A/1):

Recommended Test Procedures (RTPs), Page: 49


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

b.1 Additive white gaussian noise;

b.2 Multipath fading;

b.3 Phase noise;

b.4. Short-term doppler;

b.5 Adjacent channel;

IN C/M set
UP
CONVERTER
š/2 LF
LPF BAND
noise
PASS SIGNAL
BPSK IF/RF LF FILTER GENERA
MODULATOR GENERATOR noise LPF TOR

INTERFERENCE
EXT PM MULTIPATH
(ADJACENT CHANNEL) WIDE
FADING
BAND INTERFERENCE
NOISE (OUT OF BAND)

LPF ADDITIVE
EQUALISER NOISE
FUNCTION
PHASE GENERATOR
NOISE LF NOISE
SOURCE SHORT-TERM
DOPPLER

Figure 4-A/1

(c) Signal generator (for out-of-band interference);

(d) Environmental chamber(s) (temperature and humidity);

(e) Vibration table;

(f) Power supplies in which voltage and frequency (if applicable) can be varied. An appropriate
power supply is required for each of the power interfaces which may be supplied with the
MES (ie. AC mains, DC mains or DC battery).

6 TEST PROCEDURE

(a) Connect the simulators and the MES as shown in figure 4-A.

Initialise the set-up.

Prior to the tests, the various subsystems of the Channel simulator unit need to be calibrated to
ensure that the impairments introduced during the tests are as specified. The recommended
functional test procedures for the channel simulator are shown in Section 7.

(b) Set the channel simulator for the following conditions:

Recommended Test Procedures (RTPs), Page: 50


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

b.1 Received carrier level corresponding to a PFD of -145.5 dBW/m2 at the MES antenna*;

b.2 Phase noise and short-term doppler present (ON);

b.3 Carrier and clock frequency offsets = 0 Hz;

b.4 Multipath and interferers (ACI and OBI) absent (OFF).

*Note :This should be equivalent to C/No = 35 dB Hz at the demodulator input, with a G/T = -23 dBK-
1, however the G/T measured should be taken into account; refer to Item 2-B G/T
calculations.

(c) Start sending in every frame six 48 byte test packets, P48 and two 128 byte test packets, P128.
Note that for estimating the PER, special software might be required in the MES under test
since the only facility available as standard is the monitoring of the number of bulletin boards
in error over the last 100.

Alternatively, messages of suitable formats could be repeatedly transmitted by the simulator


and the packets received in error could be estimated by monitoring the
ACKNOWLEDGMENTS sent back by the MES.

(d) Run the test for time sufficient to transmit the MES a total of 20000 test packets
(approximately 6 hours). Record the number of PE48 and PE128 (respectively P48 and P128
packets received in error or missing altogether).

Calculate the PEP% as:

PE48
PER%(48) = 150 ;

PE128
PER%(128) = 50 ;

(e) After changing the received carrier level to correspond to a PFD of - 146.5 dBW/m2 (C/No =
34 dB-Hz at the demodulator), see note* in (b), run the Test for a time corresponding to 5000
test packets transmitted (approximately 1 hour and 30 minutes).

Calculate the PEP% as:

PE48
PER%(48) = 37.5 ;

PE128
PER%(128) = 12.5 ;

(f) Set the multipath fading to C/M=7 dB with a 0.7 Hz 3 dB bandwidth, carrier frequency offset
+850 Hz, clock offset - 0.06 Hz and ACI 5 kHz above the nominal carrier frequency at +5
dBc. Repeat steps (d) and (e).

(g) Repeat steps (d) and (e) changing the carrier frequency offset to -850 Hz, the clock offset to
+0.06 Hz and ACI 5 kHz below the nominal carrier frequency at +5 dBc.

(h) Set the channel simulator system for the conditions specified in step (f) and repeat step (e) at
high temperature/high power, humidity, low temperature/low power and vibration.

Recommended Test Procedures (RTPs), Page: 51


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(i) Disable the multipath and repeat step (e) with a simulated out-of-band interference at +130
dBc (referred to the wanted carrier).

Optional additional test:

(j) Increase the level of the out of band interference in 3 dB steps until a measurable degradation
in performance is detected; record the level of the interferer with respect to the wanted carrier
(in dBc).

7 PASS/FAIL CRITERIA

The packet error rate shall not exceed the following values:

PFD (dBW/M2) [C/No (dBHz)]* PER% (48) PER% (128)

-145.5 [35] 0.7 2.0

-146.5 [34] 2.7 8.0

*: see note in step (b) of TEST PROCEDURE.

Recommended Test Procedures (RTPs), Page: 52


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 4-B CARRIER AND FRAME ACQUISITION

1 PURPOSE OF THE TEST

The test shall verify that the performance of the receiver in terms of carrier/symbol/frame acquisition is
within the limits specified in SDM, Volume 3, Part 2, Chapter 2, Section 4.6 with all the impairments
stated in SDM, Volume 3, Part 2, Chapter 2, Section 4.4.

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

Temperature

Humidity

Power supply

Vibration

4 TEST SET-UP

Refer to figure 4-B.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Channel simulator system comprising (refer to figure 4-A/1):

b.1 Additive White Gaussian Noise;

b.2 Multipath Fading;

b.3 Phase Noise;

b.4 Short term Doppler;

b.5 Adjacent Channel Interference;

(c) RF switch.

(d) Counter.

(e) Timer/Function generator.

(f) Environmental chamber(s) (temperature and humidity).

(g) Vibration table.

Recommended Test Procedures (RTPs), Page: 53


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(h) Power supplies in which voltage and frequency (if applicable) can be varied. An appropriate
power supply is required for each of the power interfaces which are supplied with the MES
(ie, AC mains, DC mains or battery).

6 TEST PROCEDURE

PART A

(a) Connect the simulators and the MES as shown in figure 4-B.

Prior to the tests the various subsystems of the Channel Simulator Unit need to be calibrated
to ensure that the impairments introduced during the tests are as specified.

Tune the NCS/LES simulator and the MES to Channel no. 1100010.

Set the channel simulator system for the following conditions:

Received carrier level corresponding to a PFD of -146.5 dBW/m2 at the MES antenna (see
note in step (b), Item 4-A, Test Procedures)

Phase noise and short term doppler : ON;

Carrier frequency offset = -850 Hz;

Data rate offset = 0.06 Hz

Short/term doppler (+/-50 Hz): ON;

Multipath fading/interference : ON;

(b) Start sending continuously test frames and activate the timer/function generator to periodically
interrupt the RF signal; the interruption shall last at least 30 seconds.

(c) During all the following steps (a total of 6 runs, or 2400 interruptions), after each interruption,
measure on the counter the time taken to achieve synchronisation and record the result.

(d) Repeat steps (b) 300 times; record the number of times acquisition was not achieved within
25s.

(e) Repeat steps (d) with a carrier frequency offset of +850 Hz and a data rate offset of -0.06 Hz.

(f) Repeat step (e) at high temperature/high power with a carrier frequency offset of -850 Hz and
again with humidity.

(g) Repeat step (e) at low temperature/low power with a carrier frequency offset of -850 Hz and
again with vibration.

(h) Using all the results from the previous measurements, calculate the following values:

N0 = no. of tests with acquisition time of less than 25 s;

N1 = no. of tests with acquisition time between 25 and 35 s;

Nk = no. of tests with acquisition time between 25+10*(k-1) and 25+10*k s;

Recommended Test Procedures (RTPs), Page: 54


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Then,

N0
P0 = 2400 ;

(N0+N1)
P1 = 2400 ;

----

(N0+N1+ ..+Nk)
Pk = 2400 ;
PART B

(a) Set the channel simulators for the conditions as indicated in step (a), Part A.

(b) Start sending continuously test frames and store the received frame number. Make only 2-
frame slots available and restrict the randomising interval to one.

(c) Continuously send assignment requests from the MES until 100 have been sent and calculate
the number Nf = (N)/(slot type no.-1).

slot type no. = 2 for 2-frame slots;

3 for 3-frame slots;

where N is the number of valid received frames.

N.B. A valid received frame is defined as one in which the bulletin board was received error free.

(d) Continuously send test frames and store the received frame number; make only 3-frame slots
available and restrict the randomising interval to one. Repeat step (c).

(e) Repeat steps (b) through (d) with a carrier frequency offset of +850 Hz.

(f) Repeat step (b) through (d) at high temperature/high power and humidity with a carrier
frequency offset of -850 Hz.

(g) Repeat step (b) through (d) at low temperature/low power with a carrier frequency offset of
+850 Hz.

(h) Sum all the Nf obtained during the steps above (a total of 5 runs with 2-frame slots and 5 runs
with 3-frame slots) to obtain Nt;

Nt
Pt = 1000
PART C

(a) Set the channel simulator for the conditions as indicated in step (a), Part A.

(b) Start sending continuously test frames.

Recommended Test Procedures (RTPs), Page: 55


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(c) Initiate a From-Mobile message transmission of maximum message length with a LES
operating a first generation satellite. Measure the time taken to achieve synchronisation to the
NCS following the message transfer and record the result.

(d) Repeat step (c) 100 times; Record the number of times acquisition was not achieved within
25s.

(e) Repeat steps (b) through (d) with carrier offset of +850 Hz.

(f) Repeat steps (b) through (d) at high temperature/high power and humidity with a carrier
frequency offset of -850 Hz.

(f) Repeat steps (b) through (d) at low temperature/low power with a carrier frequency offset of
+850 Hz

(g) Calculate the following values:

N0=No. of tests with acquisition time of less than 25 s;

N1=No. of tests with acquisition time of between 25 and 35 s;

Nk=No. of tests with acquisition time of between 25+10*(k-1) and 25+10*k s;

Then,

N0
P0=500 ;

N0+N1
P1= 500 ;

-----

N0+N1+ -- +Nk
Pk= 500 ;

7 PASS/FAIL CRITERIA

Note that in these test the bulletin board packet error rate is assumed to be 0.011 at -146.5 dBW/m2,
corresponding to 34.0 dBHz.

PART A:

The mean value of the Ni shall be no greater than 3.3 (individual Ni values of 2, 3 and 4 are
acceptable).

The calculated P0...Pk in step (h) shall satisfy the inequalities given below:

P0 greater than 0.99;

P1 greater than 0.999;

...

Pk 1-10-(2+k)

Recommended Test Procedures (RTPs), Page: 56


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

PART B:

The Pt in step (h) shall be greater than 0.989.

PART C:

The calculated value Po -- Pk in step () shall satisfy the inequalities given below:

P0 ≥ 0.99;

P1 ≥ 0.999;

---

Pk ≥ 1-10-(2+k)

Recommended Test Procedures (RTPs), Page: 57


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 5-A MODULATION CHARACTERISTICS

1 PURPOSE

The test will verify that the characteristics of the MES transmitted signal of the MES comply with
SDM, Volume 3, Part 2, Chapter 2, Section 5.1.

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

Temperature

Power supply

4 TEST SET-UP

TEMPERATURE CHAMBER

NCS/LES COUPLER MES


SIMULATOR
CLOCK

SPECTRUM POWER
ANALYSER COUNTER SUPPLY
DTE
CONTOLLER

Figure 5-A

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Spectrum analyser

(c) Frequency counter.

(d) RF Coupler.

(e) Temperature Chamber

(f) Power supplies in which voltage and/or frequency can be varied. One appropriate power
supply is required for each of the power interfaces which may be supplied with the Inmarsat-C
unit (ie. AC, DC mains, battery).

Recommended Test Procedures (RTPs), Page: 58


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6 TEST PROCEDURE

(a) Connect the simulators and the MES as shown in figure TEST SET-UP. Initialise the set-up.

(b) Prepare a test message at the DTE. The length of the message should produce a transmission
of at least [5 minutes].

(c) Transfer the test message to the DCE and initiate a From-Mobile message transfer to a LES
(second generation satellite).

(d) During the transmission on the MES Message Channel, monitor and record the following
characteristics:

1. Transmitted spectrum: main lobe, first and second lobes amplitudes and first and
second null frequencies; Alternatively, provide a picture of the spectrum analyser
display.

2. The MES clock frequency at intervals of [10 s]. The clock frequency must be
measured at the point where the frequency is up-coverted so that the frequency
accuracy of less than 1x10-6 can be expected.

(e) Repeat steps (b) through (d) at high temperature and high main power conditions.

(f) Repeat steps (b) through (d) at low temperature and low main power conditions.

7 PASS/FAIL CRITERIA

Steps d.1: The lobes' amplitudes of the transmitted spectrum (power density), when referred to
the amplitude of the main lobe in dB/Hz, shall be:

First lobe: -13 ±1 dB;

Second lobe: -18 ±1 dB;

Steps d.2: The clock frequency shall be within the following limits:

fclk = (1±10-6)*fnom.clk over any 10 s period;

= (1±10-5)*fnom.clk during the whole tests.

Recommended Test Procedures (RTPs), Page: 59


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 5-B FIRST GENERATION OPERATION

1 PURPOSE

The test shall demonstrate that the MES is capable to operate with first generation satellites as specified
in SDM, Volume 3, Part 2, Chapter 2, Section 5.2 and that in this mode of operation, the modulation
characteristics comply with SDM, Volume 3, Part 2, Chapter 2, Section 5.1.

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

4 TEST SET-UP

NCS/LES COUPLER MES


SIMULATOR

CLOCK

SPECTRUM COUNTER
ANALYSER
CONTROLLER DTE

Figure 5-B

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Spectrum analyser

(c) Frequency counter.

(d) RF Coupler.

6 TEST PROCEDURE

(a) Connect the simulators and the MES as shown in figure 5-B. Initialise the set-up.

(b) Prepare a test message at the DTE. The length of the message should produce a transmission
of at least [5 minutes]. Throughout the test record the binary data (in hex format) received on
the MES signalling channel.

(c) Transfer the test message to the DCE and initiate a From-Mobile message transfer to the LES
(first generation satellite).

Recommended Test Procedures (RTPs), Page: 60


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(d) During the transmission on the MES Message Channel, monitor and record the following
characteristics:

1 Transmit spectrum : main lobe, first and second lobes amplitudes and first and
second null frequencies; Alternatively, provide a plot or photograph of the spectrum
analyser display.

2 The MES clock frequency at intervals of 10s. The clock frequency must be measured
at the point where the frequency is up-converted so that the frequency accuracy of
less than 1x10-6 can be expected.

7 PASS/FAIL CRITERIA

Steps d.1: The lobes' amplitudes of the transmitted spectrum (power density), when referred to
the amplitude of the main lobe in dB/Hz, shall be:

First lobe: -13 ±1 dB;

Second lobe: -18 ±1 dB;

Steps d.2: The clock frequency shall be within the following limits:

fclk = (1±10-6)*fnom.clk over any 10 s period;

= (1±10-5)*fnom.clk during the whole tests.

Recommended Test Procedures (RTPs), Page: 61


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 5-C SIGNALLING CHANNEL CHARACTERISTICS

1 PURPOSE

The test shall verify all packets transmitted on the MES signalling channel are correctly formatted with
Unique Word insertion, coding and scrambling as specified in SDM, Volume 3, Part 2, Chapter 2,
Section 5.3.

2 APPLICABILITY

All classes of MES.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

NCS/LES SIMULATOR
MES

DEMODULATOR

DATA
ANALYSER DTE

CONTROLLER

Figure 5-C

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Data analyser.

6 TEST PROCEDURE

(a) Connect the simulator and the MES as indicated in Figure 5-C. Initialise the set-up.

In steps (b) to (o) below record the signalling packet received by the NCS/LES simulator in
hexadecimal format both before and after unique word removal, descrambling and decoding
(i.e. two hexadecimal listings for each packet type). Indicate the transmission/reception bit
order (i.e. whether the least significant bit or the most significant bit of each displayed byte is
transmitted/received first).

Recommended Test Procedures (RTPs), Page: 62


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(b) Cause the MES to send an Acknowledgement packet with normal priority to the NCS/LES
simulator. Record the values assumed for:

- the logical channel number;

- the number of error packets;

- error packet numbers;

on the test data sheet.

(c) Cause the MES to send an Announcement Response packet with normal priority to the
NCS/LES simulator. Record the MES ID assumed for the test on the test data sheet.

(d) Cause the MES to send an Assignment Response packet with normal priority to the NCS/LES
simulator. Record the values assumed for:

- the MES ID;

- the logical channel number;

- the number of message packets;

on the test data sheet.

(e) Cause the MES to send a Clear packet with normal priority to the NCS/LES simulator.
Record the values assumed for:

- the MES ID;

- the LES ID;

- the logical channel number;

on the test data sheet.

(f) This step only applies to MESs which provide the optional data reporting service.

Cause the MES to send a single Data Report packet with normal priority to the NCS/LES
simulator. Record the values assumed for:

- the data network ID;

- LES ID;

on the test data sheet. Record the contents of the data field. If this is a text message provide
an ASCII listing showing the position of all non-printable characters (e.g. [CR] [LF] =
carriage return, line feed), otherwise the data should be indicated in hexadecimal form.

(g) This step only applies to MESs which provide the optional data reporting service.

Repeat step (f) for a multi-packet Data Report, recording all packets received at the NCS/LES
simulator.

Recommended Test Procedures (RTPs), Page: 63


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(h) Cause the MES to send a Forced Clear packet with normal priority to the NCS/LES simulator.
Record values assumed for:

- the MES ID;

- the LES ID;

- the logical channel number;

- the reason for clear;

on the test data sheet.

(i) Cause the MES to send a Login Request packet with normal priority to the NCS/LES
simulator. Record the values assumed for:

- the MES ID;

- the MES class;

- the network version number;

on the test data sheet.

(j) Cause the MES to send a Logout Request packet with normal priority to the NCS/LES
simulator. Record the value assumed for the MES ID on the test data sheet.

(k) Cause the MES to send a Message Status Request packet with normal priority to the NCS/LES
simulator. Record the values assumed for:

- the MES ID;

- the LES ID;

- the message reference number;

on the test data sheet.

(l) Cause the MES to send a Test Request packet with normal priority to the NCS/LES simulator.
Record the value assumed for the MES ID on the test data sheet.

(m) Cause the MES to send a Test Result Acknowledgement packet with normal priority to the
NCS/LES simulator. Record the values assumed for the logical channel number on the test
data sheet.

(n) Cause the MES to send a Transfer Status Request packet with normal priority to the NCS/LES
simulator. Record the values assumed for:

- the MES ID;

- the logical channel number;

- the stage;

on the test data sheet.

Recommended Test Procedures (RTPs), Page: 64


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(o) Cause the MES to send an Assignment Request packet with normal priority to the NCS/LES
simulator (PVT).

7 PASS/FAIL CRITERIA

The data at the simulator demodulator output shall indicate that the packet content, checksum,
scrambling, coding and UW insertion are as specified in SDM Volume 4, Chapter 4 and SDM, Volume
3, Part 2, Chapter 2, Section 5.3 for each packet type.

Recommended Test Procedures (RTPs), Page: 65


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 5-D MESSAGE CHANNEL CHARACTERISTICS

1 PURPOSE

The test shall verify that the transmitted messages on the MES message channel are correctly formatted
in respect of packet content, interleaving, coding and scrambling for all possible interleaver block sizes
as stated in SDM, Volume 3, Part 2, Chapter 2, Section 5.4 and SDM Volume 4, Chapter 5.

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

See Figure 5-C.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Data analyser.

6 TEST PROCEDURE

In steps (b) to (v) below record the message frames received by the NCS/LES simulator subject to the
following conditions:

- before preamble and unique word removal, de-interleaving, decoding and descrambling;

- after preamble and unique word removal and de-interleaving, but before decoding and
descrambling;

- after preamble and unique word removal, de-interleaving and decoding, but before
descrambling;

- After preamble and unique word removal, de-interleaving, decoding and descrambling have
all been performed.

The message frames should be recorded in hexadecimal format and an indication of the
transmission/reception bit order should be given (i.e. whether the least significant bit or the most
significant bit of each displayed byte is transmitted/received first).

For International Alphabet 5 the text content of the recovered frame(s) should be displayed with odd
parity.

Listings of original text messages should show the position of all non-printable characters (e.g. CR
LF = carriage return, line feed) in the message.

(a) Connect the simulator and the MES as indicated in Figure 5-D and initialise the set-up.

Recommended Test Procedures (RTPs), Page: 66


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Block Size N=0: store-and-forward telex service

(b) Cause the MES to transmit a message with the following characteristics:

message length < 120 characters ( = 1 packet);

message block size N 0;

character representation IA5, odd parity;

and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.

(c) Cause the MES to transmit a message with the following characteristics:

message length 120 characters (= 1 packet);

message block size N 0;

character representation IA5, odd parity.

and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.

(d) Cause the MES to transmit a message with the following characteristics:

message length 121 characters (1 packet + 1 character);

message block size N 0;

character representation IA5, odd parity;

and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.

(e) Cause the MES to transmit a message with the following characteristics:

message length > 244 characters ( > 2 frames);

message block size N 0;

character representation IA5, odd parity;

and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.

(f) This step is to be performed if the MES under test offers a capability for message transmission
in ITA2 format.

Cause the MES to transmit a message with the following characteristics:

message length < 120 (ITA2) characters ( = 1 packet);

message block size N 0;

character representation ITA2;

Recommended Test Procedures (RTPs), Page: 67


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.

Block Size N=1: store-and-forward telex service

(g) Cause the MES to transmit a message with the following characteristics:

message length < 120 characters ( = 1 packet);

message block size N 1;

character representation IA5, odd parity;

and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.

(h) Cause the MES to transmit a message with the following characteristics:

message length 244 characters (= 2 packets, 1 frame);

message block size N 1;

character representation IA5, odd parity;

and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.

(i) Cause the MES to transmit a message with the following characteristics:

message length 245 characters (= 1 frame + 1 character);

message block size N 1;

character representation IA5, odd parity;

and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.

(j) Cause the MES to transmit a message with the following characteristics:

message length > 492 characters ( > 2 frames);

message block size N 1;

character representation IA5, odd parity;

and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.

Block Size N=2: store-and-forward telex service

(k) Cause the MES to transmit a message with the following characteristics:

message length < 120 characters ( = 1 packet);

message block size N 2;

Recommended Test Procedures (RTPs), Page: 68


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

character representation IA5, odd parity;

and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.

(l) Cause the MES to transmit a message with the following characteristics:

message length 368 characters (= 3 packets, 1 frame);

message block size N 2;

character representation IA5, odd parity;

and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.

(m) Cause the MES to transmit a message with the following characteristics:

message length 369 characters (= 1 frame + 1 character);

message block size N 2;

character representation IA5, odd parity;

and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.

(n) Cause the MES to transmit a message with the following characteristics:

message length > 740 characters ( > 2 frames);

message block size N 2;

character representation IA5, odd parity;

and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.

Block Size N=3: store-and-forward telex service

(o) Cause the MES to transmit a message with the following characteristics:

message length < 120 characters ( = 1 packet);

message block size N 3;

character representation IA5, odd parity;

and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.

(p) Cause the MES to transmit a message with the following characteristics:

message length 492 characters (= 4 packets, 1 frame);

message block size N 3;

Recommended Test Procedures (RTPs), Page: 69


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

character representation IA5, odd parity;

and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.

(q) Cause the MES to transmit a message with the following characteristics:

message length 493 characters (= 1 frame + 1 character);

message block size N 3;

character representation IA5, odd parity;

and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.

(r) Cause the MES to transmit a message with the following characteristics:

message length > 988 characters ( > 2 frames);

message block size N 3;

character representation IA5, odd parity;

and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.

Block Size N=4: store-and-forward telex service

(s) Cause the MES to transmit a message with the following characteristics:

message length < 120 characters ( = 1 packet);

message block size N 4;

character representation IA5, odd parity;

and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.

(t) Cause the MES to transmit a message with the following characteristics:

message length 616 characters (= 5 packets, 1 frame);

message block size N 4;

character representation IA5, odd parity;

and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.

(u) Cause the MES to transmit a message with the following characteristics:

message length 617 characters (= 1 frame + 1 character);

message block size N 4;

Recommended Test Procedures (RTPs), Page: 70


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

character representation IA5, odd parity;

and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.

(v) Cause the MES to transmit a message with the following characteristics:

message length > 1236 characters ( > 2 frames);

message block size N 4;

character representation IA5, odd parity;

a nd indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.

7 PASS/FAIL CRITERIA

The data at the simulator demodulator output shall indicate that the packet content, checksum flush
bytes, scrambling, coding, UW insertion and preamble insertion have all been correctly performed by
the MES with different interleave factors and message sizes.

Recommended Test Procedures (RTPs), Page: 71


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 5-E ALTERNATIVE NETWORK PROTOCOLS - SIGNALLING CHANNEL


CHARACTERISTICS

1 PURPOSE

The test shall verify that all packets transmitted on the MES signalling channel, relating to alternative
protocols, are correctly formatted as specified in SDM Volume 4, Chapter 4.

2 APPLICABILITY

All classes of MESs supporting any of the optional services of PSTN, PSDN or Closed Network
addressing.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

See Figure 5-C.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Data analyser.

6 TEST PROCEDURE

(a) Connect the simulator and the MES as indicated in Figure 5-C. Initialise the set-up.

In the steps below record the signalling packet received by the NCS/LES simulator in
hexadecimal format after unique word removal, descrambling and decoding. Indicate the
transmission/reception bit order (i.e. whether the least significant bit or the most significant bit
of each displayed byte is transmitted/received first).

(b) If PSTN is supported by the MES, cause the MES to send an Assignment Request packet with
normal priority to the NCS/LES simulator. The service should be PSTN using a 2-digit
Country Code and requiring a V.22 modem to be attached. Record the values for the
following fields on the test data sheet:

- the MES ID (3 bytes);

- the LES ID (1 byte);

- the message length (1 byte; number of message packets);

- the destination network (3 bits; value 1);

- the extension length (2 bits; value 3);

- the address location (3 bits; value 3);

Recommended Test Procedures (RTPs), Page: 72


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

- the destination extension (3 bytes; value D62200H);

- the address (12 bits; 3 bcd digits - {0cc}, zero followed by the 2-digit country code).

(c) For SES only: Repeat (b), but cause the MES to send an Assignment Request packet with
distress priority to the NCS/LES simulator.

The fields should have the same values except for the priority bit in the type field.

(d) Repeat tests (b) and (c) with 3-digit country codes and other destination extensions, including
Fax T.30. In this latter case the following two fields should have the following values:

- the destination extension (3 bytes; value 543000H);

- the address (12 bits; 3 bcd digits - {ccc}, the 3-digit country code).

All other fields should be the same.

(e) Repeat tests (b), (c) and (d) for the Prefixed Store and Forward Protocol, if the protocol is
supported.

The fields should have the same values as in (b), (c) or (d) with the exception of:

- the address (20 bits; 5 bcd digits - {pp000} or {pp0cc}or {ppccc}, where pp is the 2-
digit prefix, cc is a 2-digit country code, ccc is a 3-digit country code).

(f) If PSDN is supported by the MES, cause the MES to send an Assignment Request packet with
normal priority to the NCS/LES simulator. The service should be PSDN. Record the values
for the following fields on the test data sheet:

- the MES ID (3 bytes);

- the LES ID (1 byte)

- the message length (1 byte; number of message packets);

- the destination type (3 bits; value 3);

- the extension length (2 bits; value 0);

- the address location (3 bits; value 3);

- the address (16 bits; 4 bcd digits - {0ddd} or {dddd}, the DNIC prefixed with zero if
necessary).

Note that no destination extension field is present for PSDN.

(g) For SES only: Repeat (f), but cause the MES to send an Assignment Request packet with
distress priority to the NCS/LES simulator.

The fields should have the same values except for the priority bit in the type field.

Recommended Test Procedures (RTPs), Page: 73


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(h) Repeat (f) and (g) for the Prefixed Store and Forward service, if the protocol is supported.

The fields should have the same values except for:

- the address (24 bits; 6 bcd digits - {pp0000} or {pp0ddd}or {ppdddd}, where pp is
the 2-digit prefix, ddd is a 3-digit DNIC, dddd is a 4-digit DNIC).

(i) If Closed Network addressing is supported by the MES, cause the MES to send an
Assignment Request packet with normal priority to the NCS/LES simulator. The service
should be Closed Network. Record the values for the following fields on the test data sheet:

- the MES ID (3 bytes);

- the LES ID (1 byte)

- the message length (1 byte; number of message packets);

- the destination type (3 bits; value 5);

- the extension length (2 bits; value 0);

- the address location (3 bits; value 0);

- the address (16 bits; a DNID).

Note that no destination extension field is present for Closed Network addressing.

(j) For SES only: Repeat (i), but cause the MES to send an Assignment Request packet with
distress priority to the NCS/LES simulator.

The fields should have the same values except for the priority bit in the type field.

(k) Repeat (i) and (j) for the Prefixed Store and Forward service, if the protocol is supported.

The fields should have the same values as in those tests.

(p) Verify that in all the above cases, the formatting of the fields is in accordance with the SDM.
Verify that the correct padding is used for short fields.

7 PASS/FAIL CRITERIA

The data at the simulator demodulator output shall indicate that the packet content, is as specified in
SDM Volume 4, Chapter 4 for each packet type.

Hex coded output should be provided as part of the test.

Recommended Test Procedures (RTPs), Page: 74


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 5-F ALTERNATIVE NETWORK PROTOCOLS - MESSAGE CHANNEL


CHARACTERISTICS

1 PURPOSE

The test shall verify that the transmitted data messages on the MES message channel are correctly
formatted in respect of packet content, as stated in SDM Volume 4, Chapter 5.

2 APPLICABILITY

All classes of MESs supporting any of the optional protocols of PSTN, PSDN or Closed Network.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

See Figure 5-C.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Data analyser.

6 TEST PROCEDURE

In the tests below record the message frames received by the NCS/LES simulator after preamble and
unique word removal, de-interleaving, decoding and descrambling have all been performed.

The message frames should be recorded in hexadecimal format and an indication of the
transmission/reception bit order should be given (i.e. whether the least significant bit or the most
significant bit of each displayed byte is transmitted/received first).

For International Alphabet 5 (if supported) the text content of the recovered frame(s) should be
displayed with odd parity.

Listings of original text messages should show the position of all non-printable characters (e.g. CR LF
= carriage return, linefeed) in the message.

(a) Connect the simulator and the MES as indicated in Figure 5-D and initialise the set-up.

(b) This test should be used with MESs that support the PSTN protocol.

Cause the MES to transmit a message with the following characteristics:

protocol PSTN

PSTN addresses More than one address of various lengths up to and


including the maximum length.

message length < 120 characters ( = 1 packet);

Recommended Test Procedures (RTPs), Page: 75


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

message block size N 0;

character representation data;

and indicate on the test data sheet the values assumed for the class, confirmation request,
logical channel number, presentation, last count and additional information fields.

The addressing information should appear in full in the Additional Information field of the
field Message packet.

(c) Repeat test (b) for the Prefixed Store and Forward Protocol, if the protocol is supported.

(d) This test should be used with MESs that support the PSDN protocol.

Cause the MES to transmit a message with the following characteristics:

protocol PSDN

PSDN addresses More than one address of various lengths up to and


including the maximum length.

message length < 120 characters ( = 1 packet);

message block size N 0;

character representation data;

and indicate on the test data sheet the values assumed for the class, confirmation request,
logical channel number, presentation, last count and additional information fields.

The addressing information should appear in full in the Additional Information field of the
field Message packet.

(e) Repeat test (d) for the Prefixed Store and Forward Protocol, if the protocol is supported.

(f) This test should be used with MESs that support the Closed Network protocol.

Cause the MES to transmit a message with the following characteristics:

protocol Closed Network

message length < 120 characters ( = 1 packet);

message block size N 0;

character representation data;

and indicate on the test data sheet the values assumed for the class, confirmation request,
logical channel number, presentation, last count and additional information fields.

The Additional Information field of the first Message packet should be empty.

(g) Repeat test (f) for the Prefixed Store and Forward Protocol, if the protocol is supported.

Recommended Test Procedures (RTPs), Page: 76


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(h) Verify that in all the above cases, the formatting of the fields is in accordance with the SDM.

7 PASS/FAIL CRITERIA

The data at the simulator demodulator output shall indicate that the packet content, is as specified in
SDM Volume 4, Chapter 5 for each packet type.

Hex coded output to be provided as part of test.

Recommended Test Procedures (RTPs), Page: 77


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 5-G SPECIAL ACCESS CODE ADDRESSING - SIGNALLING CHANNEL


CHARACTERISTICS

1 PURPOSE

The test shall verify all packets transmitted on the MES signalling channel, relating to alternative
protocols, are correctly formatted as specified in SDM Volume 4, Chapter 4.

2 APPLICABILITY

All MESs supporting Special Access Codes.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

See Figure 5-C.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Data analyser.

6 TEST PROCEDURE

(a) Connect the simulator and the MES as indicated in Figure 5-C. Initialise the set-up.

In the steps below, record the signalling packet received by the NCS/LES simulator in
hexadecimal format after unique word removal, descrambling and decoding. Indicate the
transmission/reception bit order (i.e. whether the least significant bit or the most significant bit
of each displayed byte is transmitted/received first).

(b) Cause the MES to send an Assignment Request packet with normal priority to the NCS/LES
simulator. The service should be Special Access Codes and the code used should be one of the
supported codes. Record the values for the following fields on the test data sheet:

- the MES ID (3 bytes);

- the LES ID (1 byte)

- the message length (1 byte; number of message packets);

- the destination type (3 bits; value 6);

- the extension length (2 bits; value 0);

- the address location (3 bits; value 0);

- the address (6 bytes; a 6 or fewer character code in IA5. If the code has fewer than 6
characters, the remaining bytes are filled to the right with 00H).

Recommended Test Procedures (RTPs), Page: 78


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(c) For SES only: Repeat (b), but cause the MES to send an Assignment Request packet with
distress priority to the NCS/LES simulator.

(d) Repeat (b) and (c) for the Prefixed Store and Forward service, if the protocol is supported.

(e) Verify that in all the above cases, the formatting of the fields is in accordance with the SDM.
Verify that the correct padding is used for short fields.

7 PASS/FAIL CRITERIA

The data at the simulator demodulator output shall indicate that the packet content, is as specified in
SDM Volume 4, Chapter 4 for each packet type.

Hex coded output should be provided as part of the test.

Recommended Test Procedures (RTPs), Page: 79


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 5-H SPECIAL ACCESS CODE ADDRESSING - MESSAGE CHANNEL


CHARACTERISTICS

1 PURPOSE

The test shall verify that the transmitted data messages on the MES message channel are correctly
formatted in respect of packet content, as stated in SDM Volume 4, Chapter 5.

2 APPLICABILITY

This test applies to all MESs supporting Special Access Codes.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

See Figure 5-C.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Data analyser.

6 TEST PROCEDURE

In the tests below record the message frames received by the NCS/LES simulator after preamble and
unique word removal, de-interleaving, decoding and descrambling have all been performed.

The message frames should be recorded in hexadecimal format and an indication of the
transmission/reception bit order should be given (i.e. whether the least significant bit or the most
significant bit of each displayed byte is transmitted/received first).

For International Alphabet 5 (if supported) the text content of the recovered frame(s) should be
displayed with odd parity.

Listings of original text messages should show the position of all non-printable characters (e.g. CR LF
= carriage return, linefeed) in the message.

(a) Connect the simulator and the MES as indicated in Figure 5-D and initialise the set-up.

(b) Cause the MES to transmit a message with the following characteristics:

protocol Special Access Code

message length < 120 characters ( = 1 packet);

message block size N 0;

character representation data;

Recommended Test Procedures (RTPs), Page: 80


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

and indicate on the test data sheet the values assumed for the class, confirmation request,
logical channel number, presentation, last count and additional information fields.

The Additional Information field of the first Message packet should be empty.

(c) Repeat test (b) for the Prefixed Store and Forward Protocol, if the protocol is supported.

(d) Verify that in all the above cases, the formatting of the fields is in accordance with the SDM.

7 PASS/FAIL CRITERIA

The data at the simulator demodulator output shall indicate that the packet content, is as specified in
SDM Volume 4, Chapter 5 for each packet type.

Hex coded output to be provided as part of test.

Recommended Test Procedures (RTPs), Page: 81


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 5-I X.400 ADDRESSING - SIGNALLING CHANNEL CHARACTERISTICS

1 PURPOSE

The test shall verify that all packets transmitted on the MES signalling channel, relating to X.400, are
correctly formatted as specified in SDM Volume 4, Chapter 4.

2 APPLICABILITY

All classes of MESs supporting X.400.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

See Figure 5-C.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Data analyser.

6 TEST PROCEDURE

(a) Connect the simulator and the MES as indicated in Figure 5-C. Initialise the set-up.

In the steps below record the signalling packet received by the NCS/LES simulator in
hexadecimal format after unique word removal, descrambling and decoding. Indicate the
transmission/reception bit order (i.e. whether the least significant bit or the most significant bit
of each displayed byte is transmitted/received first).

(b) Cause the MES to send an Assignment Request packet with normal priority to the NCS/LES
simulator. The service should be X.400. Record the values for the following fields on the test
data sheet:

- the MES ID (3 bytes);

- the LES ID (1 byte)

- the message length (1 byte; number of message packets);

- the destination type (3 bits; value 4);

- the extension length (2 bits; value 1);

- the address location (3 bits; value 2).

- the destination extension (1 byte; value 80H, Basic X.400 presentation code).

Note that no address field is present for X.400.

Recommended Test Procedures (RTPs), Page: 82


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(c) For SES only: Repeat (b), but cause the MES to send an Assignment Request packet with
distress priority to the NCS/LES simulator.

The fields should have the same values except for the priority bit in the type field.

(d) Repeat (b) and (c) for the Prefixed Store and Forward service, if the protocol is supported.

The fields should have the same values as in those tests.

(p) Verify that in all the above cases, the formatting of the fields is in accordance with the SDM.

7 PASS/FAIL CRITERIA

The data at the simulator demodulator output shall indicate that the packet content, is as specified in
SDM Volume 4, Chapter 4 for each packet type.

Hex coded output should be provided as part of the test.

Recommended Test Procedures (RTPs), Page: 83


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 5-J X.400 ADDRESSING - MESSAGE CHANNEL CHARACTERISTICS

1 PURPOSE

The test shall verify that the transmitted data messages on the MES message channel are correctly
formatted in respect of packet content, as stated in SDM Volume 4, Chapter 5.

2 APPLICABILITY

All classes of MESs supporting the X.400 protocol.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

See Figure 5-C.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Data analyser.

6 TEST PROCEDURE

In the tests below record the message frames received by the NCS/LES simulator after preamble and
unique word removal, de-interleaving, decoding and descrambling have all been performed.

The message frames should be recorded in hexadecimal format and an indication of the
transmission/reception bit order should be given (i.e. whether the least significant bit or the most
significant bit of each displayed byte is transmitted/received first).

For International Alphabet 5 (if supported) the text content of the recovered frame(s) should be
displayed with odd parity.

Listings of original text messages should show the position of all non-printable characters (e.g. CR LF
= carriage return, linefeed) in the message.

(a) Connect the simulator and the MES as indicated in Figure 5-D and initialise the set-up.

(b) This test should be used with MESs that support the X.400 protocol.

Cause the MES to transmit a message with the following characteristics:

protocol X.400

message length < 120 characters ( = 1 packet);

message block size N 0;

character representation Basic X.400 encoding;

Recommended Test Procedures (RTPs), Page: 84


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

and indicate on the test data sheet the values assumed for the class, confirmation request,
logical channel number, presentation, last count, additional information and data fields.

The Additional Information field of the first Message packet should be empty. The
Presentation Code should be 80H.

(c) Repeat test (b) for the Prefixed Store and Forward Protocol, if the protocol is supported.

(k) Verify that in all the above cases, the formatting of the fields is in accordance with the SDM.

7 PASS/FAIL CRITERIA

The data at the simulator demodulator output shall indicate that the packet content, is as specified in
SDM Volume 4, Chapter 5 for each packet type.

Hex coded output to be provided as part of test.

Recommended Test Procedures (RTPs), Page: 85


Section 2, Part 1: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 6-A GENERAL ACCESS CONTROL TEST

1 PURPOSE OF THE TEST

The test shall verify that the access control functions and signalling channel protocol implemented in
the MES under test are compliant with the requirements stated in SDM Volume 1, Volume 4, Volume
5 (sequence diagrams, SDL diagrams and packet format definitions) and in SDM Volume 3, Part 2,
Chapter 2, Section 6.1.

2 APPLICABILITY

The test is generally applicable to all classes of Inmarsat-C MES; some parts of the test might not be
needed for MES models designed for certain specific applications (see 6 Test Procedure below).

The tests shall be performed first with a LES/NCS operating in a first generation scenario and then
repeated with a second generation scenario.

It has been assumed that the MES DCE - DTE interface has been implemented in accordance with the
recommended interface control codes of SDM Volume 3, Part 2, Chapter 4, allowing the interrogation
of the DCE by the operator. Alternative implementations are acceptable, however it is the
manufacturers responsibility to submit amended test procedures highlighting the difference between
these procedures and ensuring that the full range of access control tests are still covered.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

The Test Set-up will consist of a NCS/LES simulator attached at RF or IF to the MES. The simulator
is described in Section 7 of this document.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator. The simulator is capable of simulating both normal and error conditions,
including timeouts, in a controlled way to determine the response of the MES under test to all
operational events.

Means for monitoring the results of unexpected events and displaying the information provided in DCE
Indicator messages must be provided.

(b) Other equipment will be used to check the operation of the MES at IF and RF and to
determine that the MES does tune to the appropriate channel at each stage of the test.

6 TEST PROCEDURE

The test procedures are described in the following pages. Part 1 covers signalling channel access
control and Part 2 covers Process control.

Recommended Test Procedures (RTPs), Page: 86


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

PART 1 SIGNALLING CHANNEL CONTROL

1 Frame Basics

This part of the test procedure shall demonstrate that the protocol for accessing the signalling channel
complies with the requirements given in SDM Volume 3, Part 2, Chapter 2, Section 6.2.3, concerning
the reception of at least one good Bulletin Board in the last 3 received.

For the purpose of testing the reaction of the MES to Frames containing Bulletin Boards (BB) and
Signal Channel Descriptors (SCD) with various combinations of good and bad checksums a Basic Test
Frame is defined containing a Bulletin Board and one Signalling Channel Descriptor with the
following field settings:

Bulletin Board

Network Version =1

Frame Number = 0 for the first

= Last frame number + 1 for the rest:

Signalling Channels =1

Two-frame Count =0

Empty Frame =0

Spare =0

Channel Type = 1 for NCS CC (or 2 for LES TDM)

Local ID =0

Spare =0

Origin ID = 1,44 (hex 6C) for NCS

(or LES Simulator ID for LES)

Status = X1110000 binary for NCS

(or X1111000 Binary for LES)

Services(byte one) = 10100000 binary for NCS

(or 10110000 Binary for LES)

Services(byte two) =0

Randomising = 10

Signalling Channel Descriptor

Available = 1 (Available for Store and Forward Message)

CUG = 1 (Available for Closed User Group use)

Recommended Test Procedures (RTPs), Page: 87


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Distress = 1 (Available for Maritime Distress traffic)

Slotted = 1 (Slotted Aloha)

Spare =0

Sat. Freq. code = As required for the simulator (NCS/LES)

Slot State Markers = 00 binary for all 28 slots

X indicates setting as required for test. The settings of the Checksums will be given for each test.

Test 1 Treatment of Bad Bulletin Boards

(a) Connect the simulators and the MES as described in the TEST SET-UP. Set the NCS/LES
TDM to send Basic Test Frames as defined above. Reset the MES to its initial Idle state. At
the DTE issue the commands Set Operating Parameters and Tune to NCS Channel as
necessary.

(b) Transmit a sequence of at least 100 Basic Test Frames from the NCS with a bad checksum for
the BB and a good checksum for the SCD.

(c) When at least 100 such frames have been transmitted, issue the Operator command to request
Link Performance at the DTE.

Expected Result: The Report should show 100% Bad Bulletin Boards.

(d) At the DTE issue a Log in request.

Expected Result: The MES does not attempt to use the Signalling Channel and the DCE Indicator at
the DTE shows Log-in fail. Use the Operator commands Current Channel and MES Status to check
that the Current Channel is still NCS CC and the Status is idle.

Test 2 Treatment of a sequence of Three Bad Bulletin Boards

For this test another Test Frame is defined for the NCS TDM only:

[Test Announcement Frame ] ::= [BB][SCD][Ann. Pkt]

with the following field settings:

Bulletin Board same as for the Basic Test Frame, except that the Empty Frame field is set to 1;

SCD same as for the Basic Test Frame;

Announcement Packet (To-Mobile)

MES ID = ID of the MES under test.

LES ID = ID of the Simulator LES.

LES TDM = TDM of Simulator LES.

Service = Store and Forward

Direction = To-Mobile

Recommended Test Procedures (RTPs), Page: 88


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Priority = Routine

Logical Channel No. =1

Message Reference No. =1

Sub-address =0

Presentation =0

Packets =1

Last Count =1

Checksum = good

(a) Transmit a sequence of Basic Test Frames from the LES TDM channel, each with a bad
checksum for the BB and a good checksum for the SCD, preceded by a sequence with good
BBs and good SCDs on the NCS common channel but use the simulator to transmit to the
MES on the NCS Common Channel a Test Announcement Frame in frame 0. In the Nth frame
reset the BB checksum to good.

Note: In the following tests the frame sequences refer to received frames and therefore do not
include frames lost during retuning and resynchronising at the receiver.

Rxd Frame BB Status SCD Status Packets TDM Source


Frame -5 good BB good SCD NCS
Frame -4 good BB good SCD ,,
Frame -3 good BB good SCD ,,
Frame -2 good BB good SCD ,,
Frame -1 good BB good SCD ,,
Frame 0 good BB good SCD Announcement ,,

Note: Frame(s) may be lost whilst the receiver re-tunes and synchronises with the LES TDM

Frame 1 bad BB good SCD LES


Frame 2 bad BB good SCD ,,
,, ,, ,, ,,
Frame N-3 bad BB good SCD ,,
Frame N-2 bad BB good SCD ,,

Frame N-1 bad BB good SCD [FAIL] ,,


Frame N good BB good SCD ,,

(b) Use the DTE Operator commands Current Channel, MES Status and Link Performance to
check the action of the MES and observe the DCE Indicator.

Expected result: The MES should tune to the LES TDM but not transmit the Assignment Response.
The process shall fail at the N-1th (MaxD) received frame after the announcement. Anomaly Lost
TDM should be reported.

Test 3 Treatment of a sequence of bad Signalling Channel descriptors

(a) Transmit a sequence of Basic Test Frames from the LES TDM channel, each with a good
checksum for the BB and a bad checksum for the SCD, preceded by a sequence with good
BBs and good SCDs on the NCS common channel but use the simulator to transmit to the

Recommended Test Procedures (RTPs), Page: 89


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

MES on the NCS Common Channel a Test Announcement Frame in frame 0. In the Nth
frame reset the SCD checksum to good.

Rxd Frame BB Status SCD Status Packets TDM Source


Frame -5 good BB good SCD NCS
Frame -4 good BB good SCD ,,
Frame -3 good BB good SCD ,,
Frame -2 good BB good SCD ,,
Frame -1 good BB good SCD ,,
Frame 0 good BB good SCD Announcement ,,

Note: Frame(s) may be lost whilst the receiver re-tunes and synchronises with the LES TDM

Frame 1 good BB bad SCD LES Frame


2 good BB bad SCD ,, ,,
,, ,, ,, Frame N-3
good BB bad SCD ,, Frame N-2
good BB bad SCD ,, Frame N-1
good BB bad SCD [FAIL] ,, Frame N
good BB good SCD ,,

(b) Use the DTE Operator commands Current Channel, MES Status and Link Performance to
check the action of the MES and observe the DCE Indicator.

Expected result: The MES should tune to the LES TDM but not transmit the Assignment Response.
The process shall fail at the N-1th (MaxD) received frame after the announcement. Anomaly Lost
TDM should be reported.

Test 4 Treatment of a sequence of bad Signalling Channel Descriptors and bad Bulletin Boards

(a) Transmit the following sequence of Basic Test Frames from the NCS/LES simulator. Then
use the simulator to transmit to the MES on the NCS Common Channel a Test Announcement
Frame in frame 0. In the Nth frame reset the BB and SCD checksums to good.

Rxd Frame BB Status SCD Status Packets TDM Source


Frame -5 good BB good SCD NCS
Frame -4 good BB good SCD ,,
Frame -3 good BB good SCD ,,
Frame -2 good BB good SCD ,,
Frame -1 good BB good SCD ,,
Frame 0 good BB good SCD Announcement ,,
Note: Frame(s) may be lost whilst the receiver re-tunes and synchronises with the LES TDM

Frame 1 bad BB good SCD LES


Frame 2 bad BB good SCD ,,
Frame 3 bad BB good SCD ,,
Frame 4 good BB bad SCD ,,
,, ,, ,, ,,
Frame N-3 bad BB bad SCD ,,
Frame N-2 bad BB bad SCD ,,
Frame N-1 bad BB bad SCD [FAIL] ,,
Frame N good BB good SCD ,,
(b) Use the DTE Operator commands Current Channel, MES Status and Link Performance to
check the action of the MES and observe the DCE Indicator.

Recommended Test Procedures (RTPs), Page: 90


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Expected result: The MES should tune to the LES TDM but not transmit the Assignment Response.
The process shall fail at the N-1th (MaxD) received frame after the announcement. Anomaly Lost
TDM should be reported.

Test 5 One good Bulletin Board in last Three

(a) Repeat Test 2 up to Frame 0 then continue the following variations for frames 1 to 3:

(i) Rxd Frame BB Status SCD Status Packets TDM Source


Frame 1 bad BB good SCD LES
Frame 2 bad BB good SCD ,,
Frame 3 good BB good SCD ,,

Expected result: The MES should tune to the LES Signalling Channel and send an Assignment
Response packet.

(i) Frame 1 good BB good SCD LES


Frame 2 bad BB good SCD ,,
Frame 3 bad BB good SCD ,,

Expected result: The MES should tune to the LES Signalling Channel and send an Assignment
Response packet.

(iii) Frame 1 bad BB good SCD LES


Frame 2 good BB good SCD ,,
Frame 3 bad BB good SCD ,,

Expected result: The MES should tune to the LES Signalling Channel and send an Assignment
Response packet.

2 Bulletin Board and SCD Information Tests

Test 1 Treatment of valid Bulletin Boards and Signalling Channel Descriptors

(a) Transmit 100 Basic Test Frames on the NCS Common Channel with good checksums for both
BB and SCD.

(b) Use the Operator command Query to check that the Channel Type is NCS Common Channel.
Confirm that the DCE is tuned to this channel using the Current Channel enquiry. Use Link
Performance to check that the percentage of bad frames reduces as the test proceeds until it
reaches 0 % when 100 frames have been received.

Use the Operator enquiry MES Status to verify that the status of the DCE is Idle.

Use the Operator enquiry Shore Access to verify that the DCE has correctly decoded the BB fields for
Channel Type, Origin Id, Status, Services, Randomising interval, 2-Frame count and number of
Signalling Channels and has correctly decoded the SCD slot states.

Expected Result: The MES should accurately decode the information in the BB and SCD and present
the results of the DTE-DCE commands to the Operator.

Recommended Test Procedures (RTPs), Page: 91


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Test 2 Bulletin Board and Signaling Channel Informations

(a) Continue Test 1 varying the values of Channel Type, Origin Id, Status and Services bits,
Randomising interval, Number of Signalling Channels, 2-Frame count in the Bulletin Board,
and the slot states in the SCD.

Use the Operator enquiry Shore Access to verify that the DCE has correctly decoded the BB fields for
Channel Type, Origin Id, Status, Services, Randomising interval, 2-Frame count and number of
Signalling Channels and has correctly decoded the SCD slot states.

Expected Result: The MES should accurately decode the information in the BB and SCD and present
the results of the DTE-DCE commands to the Operator.

Test 3 Bulletin Board - 2-Frame Count

(a) Set the 2-Frame Count field to zero and the randomising interval to 1 in the Bulletin Board (ie,
indicating all slots are 3-Frame slots and no frame randomisation) and only slot 1 to available
on the NCS Common Channel.

(b) Initiate a Log-in at the DTE keyboard and time the intervals between successive bursts on the
signalling channel

(c) Set the 2-Frame count field to 14 (first generation) and repeat step (b).

(d) Repeat (a), (b) and (c) for second generation operation setting the 2-Frame count field in (c) to
28.

Expected result: In (b) the time interval between bursts should always be consistent with 3-Frame
operation (25.92s in both first and second generation modes). In (c) the time interval should always be
consistent with 2-Frame operation (17.28s in both first and second generation modes).

Test 4 Bulletin Board Status - Out of Service

(a) Transmit a Sequence of modified Basic Test Frames from the NCS, in which the only change
is to set Bit 6 of the Status byte to 0, meaning out of service.

(b) Attempt to Log in at the MES.

Expected Result: The MES does not attempt to use the Signalling Channel and the DCE Indicator at
the DTE shows Log-in fail. Use the Operator commands Current Channel and MES Status to check
that the Current Channel is still NCS CC and the Status is Logged out.

(c) Transmit a Sequence of modified Basic Test Frames from the LES, in which the only change
is to set Bit 6 of the Status byte to 0, meaning out of service.

(d) For SES only: Attempt to send Distress Alert at the MES.

Expected Result: The MES does not attempt to use the Signalling Channel and the DCE Indicator at
the DTE shows Distress fail. Use the Operator commands Current Channel and MES Status to check
that the Current Channel is NCS CC and the Status is Logged out.

Recommended Test Procedures (RTPs), Page: 92


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Test 5 Bulletin Board Status - Restoration mode

Set the NCS TDM Channel Type to Standby NCS Common Channel (Restoration mode Network
operation) and the LES TDM Channel Type to joint Common Channel and LES TDM.

(a) Transmit a Network Update packet from the NCS with the following fields:

Network Version =2

LES Total =1

LES ID = ID of the Simulator LES.

LES Status = 01111000 Binary

LES Services[1] = 10110000 Binary

LES Services[2] =0

LES TDM = TDM of Simulator LES

Good Checksum

(b) Transmit a continuous sequence of good Basic Test Frames from the NCS with the Channel
Type set to Standby NCS Common Channel.

(c) Transmit a continuous sequence of good Basic Test Frames from the LES with the Channel
Type set to Joint Common and TDM.

(d) Verify that a prompt is sent to the operator via the DTE requesting the operator to select a
LES.

(e) Select a LES (only one available in this case).

(f) Perform the following steps in sequence and note the MES response:

1) Attempt to log-out of the ocean region.

2) Attempt to log-in to the ocean region.

3) Transmit a request for a Performance Verification Test.

Expected result: The MES should retune to the LES Common Channel, but all 3 attempts should be
refused and a DCE indication presented to the DTE Operator.

(g) Perform the following steps in sequence and note the MES response:

1) Attempt a From-Mobile message transfer to the selected LES, followed by the


delivery confirmation.

2) Attempt a To-Mobile message transfer from the selected LES.

3) Send as EGC message from the selected LES (only for Class-2 or 3 MES).

Expected result: All attempts are successful.

Recommended Test Procedures (RTPs), Page: 93


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(h) Reset the NCS and LES TDM bulletin boards. Transmit a sequence of unmodified Basic Test
Frames from both the NCS and the LES.

Expected result: the MES retunes to the NCS.

Test 6 Bulletin Board Status - Stand-alone operation

Retune the LES TDM to the NCS Common Channel frequency and indicate that this is NCS Common
TDM.

(a) Transmit a Network Update packet from the NCS with the following fields:

Network Version =3

LES Total =1

LES ID = ID of the Simulator LES.

LES Status = X1111000 Binary

LES Services[1] = 10110000 Binary

LES Services[2] =0

LES TDM = TDM of Simulator NCS Common Channel

Good Checksum

(b) Transmit a continuous sequence of good Basic Test Frames from the NCS with the Channel
Type set to NCS Common Channel.

(c) Perform the following steps in sequence and note the MES response:

1) Attempt to log-out of the ocean region.

2) Attempt to log-in to the ocean region.

3) Transmit a request for a Performance Verification Test.

4) Transmit an assignment request.

Expected result: All commands should be accepted.

(d) Reset the NCS and LES TDM bulletin boards. Transmit a sequence of unmodified Basic Test
Frames from both the NCS and the LES.

Transmit a Network Update packet from the NCS with the following fields:

Network Version =4

LES Total =1

LES ID = ID of the Simulator LES.

LES Status = X1111000 Binary

Recommended Test Procedures (RTPs), Page: 94


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

LES Services[1] = 10110000 Binary

LES Services[2] =0

LES TDM = TDM of Simulator LES

Good Checksum

Expected result: the MES remains tuned to the NCS. The new network configuration information is
accepted and stored.

Test 7 Signalling Channel Descriptor - Available bit

(a) Transmit a Sequence of modified Basic Test Frames from the LES, in which the only change
is to set the Available bit to zero, meaning Signalling channel not available for Store and
Forward Messaging Service by MES.

(b) Attempt to make a From-Mobile message transfer at the MES.

Rxd Frame BB Status SCD Status Packets TDM Source


Frame 1 good BB good SCD LES
Frame 2 good BB good SCD ,,
,, ,, ,, ,,
Frame N-1 good BB good SCD [FAIL] ,,
Frame N good BB good SCD ,,

Expected Result: The MES does not attempt to use the Signalling Channel and the DCE Indicator at
the DTE shows call fail after the N-1th (MaxD) frame. Use the Operator commands Current Channel
and MES Status to check that the Current Channel is still NCS CC and the Status is idle.

(c) As in (a), but set the Available bit to 1. Initiate a From-Mobile message transfer at the MES.

Expected result: The MES sends the assignment request to the LES Signaling Channel.

Test 8 Signalling Channel Descriptor - Distress bit

(a) Transmit a Sequence of modified Basic Test Frames from the NCS, in which the Available bit
is set to 0, the CUG bit is set to 0 and the distress bit is set to 1, ie, reserved for Distress traffic
only.

(b) Attempt to Log in at the MES.

Rxd Frame BB Status SCD Status Packets TDM Source


Frame 1 good BB good SCD NCS
Frame 2 good BB good SCD ,,
,, ,, ,, ,,
Frame N-1 ,, ,, [FAIL] ,,
Frame N good BB good SCD ,,

Expected Result: The MES does not attempt to use the Signalling Channel and the DCE Indicator at
the DTE shows Log-in fail after the N-1th (MaxD) frame. Use the Operator commands Current
Channel and MES Status to check that the Current Channel is still NCS CC and the Status is idle.

Recommended Test Procedures (RTPs), Page: 95


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(c) For the purpose of this test it is assumed that either the MES does not have network
configuration information, in which case it should tune to the NCS to transmit the distress
alert.

For SES only: Initiate a Distress Alert at the MES. When the DCE replies, confirm the Alert.

Expected Result: The MES sends a Distress Alert on the Signalling Channel.

(d) For SES only: As in (c), but set the Distress bit to zero. Send the Distress Alert at the MES.

Expected result: The MES does not attempt to use the Signaling Channel and the DCE Indicator at the
DTE shows Distress Alert fail after the N-1th (MaxD) frame. Use the Operator commands Current
Channel and MES Status to check that the Current Channel is still NCS CC and Status is idle.

(e) For SES only: Configure the NCS/LES simulator to allow the MES to tune and synchronise
with the LES TDM. Set up two SCDs, one is a dedicated distress signalling channel and the
other is a general signalling channel, in which both Available and Distress bits are set. Send
10 Distress Alerts to the LES.

Expected Result: All distress alerts should be sent on the dedicated distress signalling channel.

(f) For SES only: As in (e), but change the dedicated distress signalling channel to a general
signalling channel, in which both Available and Distress bits are set. Send 10 Distress Alerts
from the MES.

Expected Result: The distress alerts should be scattered on both signalling channels.

(g) For SES only: As in (e), but change the dedicated distress signalling channel to the signalling
channel, in which only Available bit is set. Send 10 Distress Alerts to the LES.

Expected Result: The distress alerts should be sent on the general signalling channel.

(f) For SES only: As in (e), but change the dedicated distress signalling channel to a dedicated
Land Mobile Alert signalling channel, in which both Available and Land Mobile Alert bits are
set. Send 10 Distress Alerts to the LES.

Expected Result: The distress alerts should be sent on the general signalling channel.

Test 9 Signalling Channel Descriptor - CUG bit

(a) Transmit a Sequence of modified Basic Test Frames from the NCS, in which the Available bit
is set to 0, the CUG bit is set to 1 and the distress bit is set to 0, ie, reserved for Closed User
Group use.

(b) Attempt to Log in at the MES.

Rxd Frame BB Status SCD Status Packets TDM Source


Frame 1 good BB good SCD NCS
Frame 2 good BB good SCD ,,
,, ,, ,, ,,
Frame N-1 ,, ,, [FAIL] ,,
Frame N good BB good SCD ,,

Recommended Test Procedures (RTPs), Page: 96


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Expected Result: The MES does not attempt to use the Signalling Channel and the DCE Indicator at
the DTE shows Log-in fail after the N-1th (MaxD) frame. Use the Operator commands Current
Channel and MES Status to check that the Current Channel is still NCS CC and the Status is idle.

(c) For SES only: Repeat (a) with the Distress bit also set to 1 and Initiate a Distress Alert at the
MES. When the DCE replies, confirm the Alert.

Expected Result: The MES sends a Distress Alert on the Signalling Channel. Use the Operator
commands Current Channel and MES Status to check that the access is made.

3 Treatment of Slot State Markers

Test 1 Unreserved Access - no valid SCD

(a) Transmit a sequence of Basic Test Frames from the NCS, each with a good checksum for both
the BB and the SCD. Then use the simulator to transmit to the MES on the NCS Common
Channel a Test Announcement Frame, each having a BB with a good checksum and a SCD
with a good checksum. Transmit a sequence of MaxD Test Frames from the LES, each having
a BB with a good checksum and a SCD with a bad checksum. In the Nth (MaxD+1) frame,
reset the SCD to a good checksum.

Note: In the following tests the frame sequences refer to received frames and therefore do not
include frames lost during retuning and resynchronising at the receiver.

Rxd Frame BB Status SCD Status Packets TDM Source


Frame -5 good BB good SCD NCS
Frame -4 good BB good SCD ,,
Frame -3 good BB good SCD ,,
Frame -2 good BB good SCD ,,
Frame -1 good BB good SCD ,,
Frame 0 good BB good SCD Announcement ,,
Note: Frame(s) may be lost whilst the receiver re-tunes and synchronises with the LES TDM

Frame 1 good BB bad SCD LES


Frame 2 good BB bad SCD ,,
,, ,, ,, ,,
Frame N-3 good BB bad SCD ,,
Frame N-2 good BB bad SCD ,,
Frame N-1 good BB bad SCD [FAIL] ,,
Frame N good BB good SCD ,,
(b) Use the DTE Operator commands Current Channel, MES Status and Link Performance to
check the action of the MES and observe the DCE Indicator.

Expected result: The MES should tune to the LES TDM but not transmit the Assignment Response.
The process shall fail at the N-1th (MaxD) received frame after the announcement. Anomaly Lost
TDM should be reported.

Test 2 Unreserved Access - no free slots

(a) Repeat Test 1 but with the following variations;

(b) Use the simulator to transmit to the MES on the LES TDM a sequence of MaxE+1 Test
Frames, each having a BB with a good checksum but having the randomising interval set to 1,
a SCD with a good checksum, but the SCD showing all slots reserved.

Recommended Test Procedures (RTPs), Page: 97


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(c) Use the DTE Operator commands Current Channel, MES Status and Link Performance to
check the action of the MES and observe the DCE Indicator.

Expected result: The MES should tune to the LES TDM but not transmit the Assignment Response.
The process shall fail at the N-1th (MaxE) received frame after the announcement. Anomaly
Congestion should be reported.

Test 3 Unreserved Access - one block (bad response)

(a) Repeat test 1 with the following variations;

(b) Use the simulator to transmit to the MES on the LES TDM a sequence of Test Frames, each
having a BB with a good checksum, a SCD with a good checksum and all slots free.

Rxd Frame BB Status SCD Status Packets TDM Source


Frame -5 good BB good SCD NCS
Frame -4 good BB good SCD ,,
Frame -3 good BB good SCD ,,
Frame -2 good BB good SCD ,,
Frame -1 good BB good SCD ,,
Frame 0 good BB good SCD Announcement ,,
Note: Frame(s) may be lost whilst the receiver re-tunes and synchronises with the LES TDM

Frame 1 good BB good SCD Assignment resp. LES


Frame 2 good BB bad SCD ,,
,, ,, ,, ,,
Expected result: The MES should tune to the Signalling Channel and transmit an Assignment
Response, which should convey its MES ID.

(c) Transmit a sequence of Basic Test Frames from the LES, with good BBs but bad SCDs.

(d) Use the DTE Operator commands Current Channel, MES Status and Link Performance to
check the action of the MES and observe the DCE Indicator.

Expected result: The MES should consider the Announcement Response successfully received and start
to wait for the Message. The Current Channel should show LES TDM and the MES Status should
show Busy.

Test 4 Unreserved Access - one block (error)

(a) Transmit a sequence of Basic Test Frames from the NCS, each with a good checksum for both
BB and SCD. Then use the simulator to transmit to the MES on the NCS Common Channel
one Test Announcement Frame, having a BB with a good checksum and a SCD with a good
checksum. Transmit a sequence of Basic Test Frames from the LES with good BBs and good
SCDs with all slots free.

Expected result: The MES should tune to the LES and to transmit an Assignment Response in the free
slot on the LES Signalling Channel.

(b) Transmit a sequence of Basic Test Frames from the LES, with good BBs and good SCDs, in
which the slot burst received bit is zero.

(c) Use the DTE Operator commands Current Channel, MES Status and Link Performance to
check the action of the MES and observe the DCE Indicator.

Recommended Test Procedures (RTPs), Page: 98


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Expected result: The MES should back-off, re-randomise and try to resend the Assignment Response.
The current channel should show SIG and the MES Status should remain Busy.

Test 5 Unreserved Access - one block (success)

(a) Transmit a sequence of 10 Basic Test Frames from the NCS, each with a good checksum for
both BB and SCD. Then use the simulator to transmit to the MES on the NCS Common
Channel one Test Announcement Frame. Transmit a sequence of Basic Test Frames from the
LES, having a BB with a good checksum, a SCD with a good checksum and with only one
slot free.

Expected result: The MES should tune to the Signalling Channel and transmit an Assignment
Response, which should convey its MES ID.

(b) Transmit a sequence of Basic Test Frames from the LES, with good BBs and good SCDs and
with the selected multislot showing burst received.

(c) Use the DTE Operator commands Current Channel and MES Status to check the action of the
MES and observe the DCE Indicator.

Expected result: The MES should consider the Assignment Response successfully received and start to
wait for the Message. The Current Channel should show LES TDM and the MES Status should show
Busy.

Test 6 For SES only: Unreserved Access - distress alert (error)

(a) Transmit a sequence of Basic Test Frames from the NCS and LES, each with a good
checksum for both BB and SCD.

(b) Issue a Distress Alert at the MES DTE.

Expected result: The MES should tune to the LES TDM and then the Signalling Channel and transmit
the Distress Alert in a free slot.

(c) Continue to transmit the sequence of Basic Test Frames from the LES, with good BBs and
good SCDs, in which the slot burst received bit is zero.

(d) Use the DTE Operator commands Current Channel, MES Status and Link Performance to
check the action of the MES and observe the DCE Indicator.

Expected result: The MES should try to resend the Distress Alert at the next opportunity. The current
channel should show SIG and the MES Status should remain Busy.

Test 7 For SES only: Unreserved Access - distress (error and TXenable false)

(a) Transmit a sequence of Basic Test Frames from the NCS and LES, each with a good
checksum for both BB and SCD.

(b) Issue a Distress Alert at the MES DTE.

Expected result: The MES should tune to the LES TDM and then the Signalling Channel and transmit
the Distress Alert in a free slot.

Recommended Test Procedures (RTPs), Page: 99


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(c) On receipt of the Distress Alert, transmit a sequence of Basic Test Frames from the LES, with
bad BBs and good SCDs, in which the slot burst received bit is zero.

(d) Use the DTE Operator commands Current Channel, MES Status and Link Performance to
check the action of the MES and observe the DCE Indicator.

Expected result: The MES should set D to 1.

(e) Transmit to the MES on the LES TDM Channel a sequence of MaxD - 1 Basic Test Frames,
each having a BB with a bad checksum, and a SCD with a good Checksum.

(f) Use the DTE Operator commands Current Channel, MES Status and Link Performance to
check the action of the MES and observe the DCE Indicator.

Expected result: The MES should ignore such a sequence and remain tuned to the LES TDM Channel.
Anomaly Lost TDM should be reported.

Test 8 Reserved Access - no valid BB

For this test another Test Frame is defined:

[Test Acknowledgement Request Frame] ::=

[BB][SCD][Ack. Request Pkt]

with the following field settings:

Bulletin Board same as for the Basic Test Frame, except that the Empty Frame field is set to 1;

SCD same as for the Basic Test Frame;

Acknowledgement Request Packet

LES ID = ID of the Simulator LES.

Logical Channel No. =1

MES Signalling Channel = As required for the simulator

Frame Offset =3

AM/PM bit =0

Slot Number =1

Checksum = good

(a) Repeat Test 5, so that the MES is in the state in which it is waiting for a Message from the
LES and is tuned to the LES TDM.

(b) Transmit a sequence of 5 Basic Test Frames from the LES, each with a good checksum for
both BB and SCD. Then use the simulator to transmit to the MES on the LES TDM a Test
Acknowledge Request Frame, having a good checksum for both BB and SCD in Frame 0.
Transmit a sequence of M (Frame_offset+3(MaxF-1)) Test Frames from the LES, each having
a BB with a bad checksum and a SCD with a good checksum.

Recommended Test Procedures (RTPs), Page: 100


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Rxd Frame BB Status SCD Status Packets TDM Source


Frame -5 good BB good SCD LES
Frame -4 good BB good SCD ,,
Frame -3 good BB good SCD ,,
Frame -2 good BB good SCD ,,
Frame -1 good BB good SCD ,,
Frame 0 good BB good SCD Acknowledge Req. ,,
Frame 1 bad BB good SCD ,,
,, ,, ,, ,,
Frame M bad BB good SCD ,,
(c) Use the DTE Operator commands Current Channel, MES Status and Link Performance to
check the action of the MES and observe the DCE Indicator.

Expected result: The MES should ignore such a sequence and remain tuned to the LES TDM.

(d) Transmits Test Acknowledgement Request Frame on the LES TDM as (b) in succession
MaxF times.

Expected result: The MES should ignore such sequences and remain tuned to the LES TDM.
Anormaly Lost TDM should be reported after MaxF retransmissions.

Test 9 Reserved Access - no valid SCD

(a) Repeat Test 5, so that the MES is in the state in which it is waiting for a Message from the
LES and is tuned to the LES TDM.

(b) Transmit a sequence of 5 Basic Test Frames from the LES, each with a good checksum for
both BB and SCD. Then use the simulator to transmit to the MES on the LES TDM a Test
Acknowledgement Request Frame, having a good checksum for both BB and SCD in Frame
0. Transmit a sequence of M (Frame_offset+3(MaxF-1)) Test Frames from the LES, each
having a BB with a good checksum and a SCD with a bad checksum.

Rxd Frame BB Status SCD Status Packets TDM Source


Frame -5 good BB good SCD LES
Frame -4 good BB good SCD ,,
Frame -3 good BB good SCD ,,
Frame -2 good BB good SCD ,,
Frame 1 good BB good SCD ,,
Frame 0 good BB good SCD Acknowledge Req. ,,
Frame 1 good BB bad SCD ,,
,, ,, ,, ,,
Frame M good BB bad SCD ,,
(c) Use the DTE Operator commands Current Channel, MES Status and Link Performance to
check the action of the MES and observe the DCE Indicator.

Expected result: The MES should ignore such a sequence and remain tuned to the LES TDM.

(d) Transmit a Test Acknowledgement Request Frame on the LES TDM as (b) in succession
MaxF times.

Expected result: The MES should ignore such sequences and remain tuned to the LES TDM.
Abnormaly Lost TDM should be reported after MaxF retransmitions.

Recommended Test Procedures (RTPs), Page: 101


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Test 15 Reserved Access - one block (error)

(a) Repeat Test 5, so that the MES is in the state in which it is waiting for a Message from the
LES and is tuned to the LES TDM.

(b) Transmit a sequence of 5 Basic Test Frames from the LES, each with a good checksum for
both BB and SCD. Then use the simulator to transmit to the MES on the LES TDM a Test
Acknowledgement Request Frame, having a BB with a good checksum, a SCD with a good
checksum and the slot 1 reserved.

Expected result: The MES should tune to the LES Signalling Channel and transmit an
Acknowledgement in the reserved slot.

(c) Transmit a sequence of Basic Test Frames from the LES, with good BBs and good SCDs, in
which the slot burst received bit is zero.

(d) Use the DTE Operator commands Current Channel, MES Status and Link Performance to
check the action of the MES and observe the DCE Indicator.

Expected result: The MES should retransmit in the next multislot. The current channel should show
LES SIG and the MES Status should remain Busy.

4 Congestion Control

Test 1 Bulletin Board Status - Congested: Response to log-in/log-out

(a) Transmit a Sequence of modified Basic Test Frames from the NCS, in which Bit 5 of the
Status byte is set to 0 (congested) and the randomising interval is set to 1.

(b) Attempt to Log in at the MES.

Rxd Frame BB Status SCD Status Packets TDM Source


Frame 1 good BB good SCD NCS
Frame 2 good BB good SCD ,,
,, ,, ,, ,,
Frame N-1 ,, ,, [FAIL] ,,
Frame N good BB good SCD ,,

Expected Result: The MES does not attempt to use the Signalling Channel and the DCE Indicator at
the DTE shows Log-in fail (congestion) after the N-1th (MaxE) frame. Use the Operator commands
Current Channel and MES Status to check that the Current Channel is still NCS CC and the Status is
idle.

(c) Repeat steps (a) and attempt to send a log out request.

Expected Result: As in (b) above. The DTE reports Log out fail (congestion) after the Nth (MaxE+1)
frame.

Test 2 Bulletin Board Status - Congested: Response to Announcement

(a) Use the simulator to transmit to the MES on the NCS TDM a sequence of Basic Test Frames
followed by a Test Announcement Frame. Then on the LES TDM transmit a sequence of
frames each having a BB with a good checksum but having the status bit (B5) set to 0
(congested) and the randomisation interval set to 1, and a SCD with a good checksum.

Recommended Test Procedures (RTPs), Page: 102


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Rxd Frame BB Status SCD Status Packets TDM Source


Frame -5 good BB good SCD NCS
Frame -4 good BB good SCD ,,
Frame -3 good BB good SCD ,,
Frame -2 good BB good SCD ,,
Frame -1 good BB good SCD ,,
Frame 0 good BB good SCD Announcement ,,
Note: Frame(s) may be lost whilst the receiver re-tunes and synchronises with the LES TDM

Frame 1 good BB good SCD Assignment Resp. LES


Frame 2 good BB good SCD SCD-Sig Pkt OK ,,
(b) Use the DTE Operator commands Current Channel, MES Status and Link Performance to
check the action of the MES and observe the DCE Indicator.

Expected result: The MES tunes to the LES TDM and transmits an assignment response on the LES
signalling channel, ignoring the LES congested bit in the bulletin board.

Test 3 For SES only: Bulletin Board Status - Congested: Response to Distress Alert

(a) Transmit a Network Update packet from the NCS with the following fields:

Network Version =5

LES Total =1

LES ID = ID of the Simulator LES.

LES Status = X1111000 Binary

LES Services[1] = 10110000 Binary

LES Services[2] =0

LES TDM = FFFFH (ie, LES in demand assigned mode)

Good Checksum

(b) Transmit a continuous sequence of good Basic Test Frames from the NCS with the bulletin
board status bit (B5) set to 0 (congested) and the randomisation interval set to 1, and a SCD
with a good checksum.

(c) Transmit a distress alert from the MES (to the demand assigned LES via the NCS).

Expected Result: The congestion status is ignored and the MES successfully transmits the distress alert
packet to the NCS.

Recommended Test Procedures (RTPs), Page: 103


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

PART 2 PROCESS CONTROL TESTS

In these tests, Test frames carrying TDM packets are transmitted from the NCS or LES without error,
the Bulletin Board and Signalling Channel Descriptor are modified as necessary in the manner of the
Test Announcement Frame used in Stage 3 of Part 1. In most tests the burst received bit is set
correctly, but in some it is deliberately set to zero.

In the following tests an abbreviated notation is given together with a description of the test sequence.
The format and meaning are as follows.

Each transmission is on a separate line, with the exception that the success or failure of a burst on a
Signalling channel is shown by the addition of "-OK" or "-FAIL" on the same line as the transmission
in question. This refers to each signalling channel access whereby the MES attempts to transmit a
burst MaxC+1 times (or is inhibited from transmitting in MaxD+1 times) before exiting the signalling
channel control.

For each transmission (MES or NCS/LES simulator originated) the format is:

SOURCE/CHANNEL TYPE/RELATIVE TIME/PACKET TYPE.

where SOURCE is:

NCS

LES

MES

CHANNEL TYPE is:

NCC = NCS Common Channel

TDM = LES TDM

NSIG = NCS Signalling Channel

CSIG = LES Signalling Channel

MSG = LES Message Channel

RELATIVE TIME is Fi frame number corresponding to Ti

PACKET TYPE is as defined in the SDM.

As an example, the sequence:

MES/CSIG/F0/ASSIGNMENT REQUEST - OK

LES/TDM/F0+R+6/LOGICAL CHANNEL ASSIGNMENT

MES/MSG/F1/Test Message

LES/TDM/F(EOM)+3/ACKNOWLEDGEMENT

MES/CSIG/F2/TRANSFER STATUS REQUEST - OK

Recommended Test Procedures (RTPs), Page: 104


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

LES/TDM/F2+R+3/CLEAR

will represent the following events:

In frame F0 (reference) the MES sends an Assignment Request packet on the Signalling Channel; the
packet is successfully received by the LES (simulator) and this is reflected in the Signalling Channel
Descriptor packet; R+6 frames after the Assignment Request has been generated, the LES (simulator)
sends a logical channel Assignment packet to the MES; the MES begins transmitting the message in
frame F1; 3 frames after the end of the message the LES sends an acknowledgement packet; having
timed out, the MES sends a Transfer Status Request in frame F2; it is received successfully and the
LES sends a clear packet R+3 frames later.

In order to verify the correction action in the case of timeouts, a delay of either N1 or N2 frames is
made in many tests, where:

N1(T) = Greatest integer less than T/8.64, and

N2(T) = Least integer greater than T/8.64.

Thus N1 is just less than the number of frames which would cause the timeout T and N2 is just greater
than this number.

Whenever the MES transmits a packet on the MES Signaling Channel and waits for a response from
the NCS or the LES, 3 (or 2) frames should be added to the response frame number because of the 3-
frame (2-frame) count operation. This is denoted by R.

The timeout T in each case is as defined in the SDM.

As an example, T0 is defined as 60s in the SDM, Volume 5, Chapter 2, Section 2. Therefore N1(T0) is
6 frames and N2(T0) is 7 frames.

In order to force MES timeouts to occur, either the LES response packet is transmitted late (N2 frames
delay) or it is not transmitted at all. In both cases the effect at the MES should be the same (timeout).

1 For SES only: DISTRESS ALERT

LES with Demand Assigned TDM

Simulate a scenario in which the destination LES is operating with a Demand Assigned TDM (LES
TDM channel number FFFFH in network update or log-in acknowledgement packet) and initiate a
Distress Alert.

Monitor and record the behaviour of the MES (responses to the operator, signalling channel no. etc)
throughout the following tests.

a) Make the transmission of the Distress Alert packet successful. Wait R+N1 frames and send
an Acknowledgement Packet.

MES/NSIG/F0/DISTRESS ALERT - OK

NCS/NCC/F0+R+N1/DISTRESS ALERT ACK

Expected result: Alert OK

Recommended Test Procedures (RTPs), Page: 105


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

b) Repeat as in a), but send the Acknowledgement Packet R+N2 frames later.

MES/NSIG/F0/DISTRESS ALERT - OK

NCS/NCC/F0+R+N2/DISTRESS ALERT ACK

Expected result: MES should repeat the Distress Alert automatically after the timeout on the NCS
Signalling channel:

MES/NSIG/F1/DISTRESS ALERT - OK

NCS/NCC/F1+R+N1/DISTRESS ALERT ACK

c) Repeat as in a) and make the transmission of the Distress Alert packet fail.

MES/NSIG/F0/DISTRESS ALERT - FAIL

Expected result: MES should repeat the Distress Alert MaxC times on the NCS Signalling channel:

MES/NSIG/F1/DISTRESS ALERT - OK

NCS/NCC/F1+R+N1/DISTRESS ALERT ACK

LES Operating with a Permanent TDM

(a) Make the transmission of the Distress Alert packet successful. Wait R+N1 frames and send
an Acknowledgement Packet.

MES/CSIG/F0/DISTRESS ALERT - OK

LES/TDM/F0+R+N1/DISTRESS ALERT ACK

Expected result: Alert OK

(b) Repeat as in a), but send the Acknowledgement Packet R+N2 frames later.

MES/CSIG/F0/DISTRESS ALERT - OK

LES/TDM/F0+R+N2/DISTRESS ALERT ACK

MES/CSIG/F1/DISTRESS ALERT - OK

LES/TDM/F1+R+N2/DISTRESS ALERT ACK

---

MES/CSIG/Fn/DISTRESS ALERT - OK

LES/TDM/Fn+R+N2/DISTRESS ALERT ACK

Expected result: MES should repeat the Distress Alert MaxCD times automatically after each timeout
on the LES Signaling Channel. Then the MES should send the Distress Alert on the NCS Signaling
Channel.

MES/NSIG/Fn1/DISTRESS ALERT - OK

Recommended Test Procedures (RTPs), Page: 106


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

NCS/NCC/Fn1+R+1/DISTRESS ALERT ACK

(c) Repeat as in b), but send the Acknowledgement Packet from the NCS after R+N2 frames.
make the next Distress Alert Packet successful again and send the Acknowledgement Packet
after a further R+N2 frames.

MES/CSIG/F1/DISTRESS ALERT - OK

LES/TDM/F1+R+N2/DISTRESS ALERT ACK

MES/CSIG/F2/DISTRESS ALERT - OK

LES/TDM/F2+R+N2/DISTRESS ALERT ACK

---

MES/CSIG/Fn/DISTRESS ALERT - OK

LES/TDM/Fn+R+N2/DISTRESS ALERT ACK

MES/NSIG/Fn1/DISTRESS ALERT - OK

NCS/NCC/Fn1+R+N2/DISTRESS ALERT ACK

MES/NSIG/Fn2/DISTRESS ALERT - OK

NCS/NCC/Fn2+R+N2/DISTRESS ALERT ACK

---

Expected result: MES should repeat the Distress Alert MaxCD times again automatically after each
timeout on the LES Signalling Channel. Then the MES should send the Distress Alert on the NCS
Signalling Channel repeatedly.

MES/NSIG/Fn3/DISTRESS ALERT - OK

NCS/NCC/Fn3+R+1/DISTRESS ALERT ACK

(d) Repeat as in a). but make the transmission of the Distress Alert Packet fail.

MES/CSIG/F0/DISTRESS ALERT - FAIL

Expected result: MES should repeat the Distress Alert MaxC times on the LES Signaling Channel and
then retune to the NCS and send the Distress Alert on the NCS Signalling channel:

MES/NSIG/F1/DISTRESS ALERT - OK

NCS/NCC/F1+R+N1/DISTRESS ALERT ACK

(e) Repeat as in d) and send the Acknowledgement Packet from the NCS after R+N2 frames.

MES/CSIG/F0/DISTRESS ALERT - FAIL

Expected result: MES should repeat the Distress Alert MaxC times on the LES signalling channel and
then retune to the NCS and resend the Distress Alert on the NCS Signalling channel:

Recommended Test Procedures (RTPs), Page: 107


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

MES/NSIG/F1/DISTRESS ALERT - OK

NCS/NCC/F1+R+N2/DISTRESS ALERT ACK

Expected result: MES should repeat the Distress Alert on the NCS signalling channel. Note any further
action of the MES (ie, operator prompts).

(f) Set the MES to log-out and make the transmission of the Distress Alert packet successful.

MES/NSIG/F0/DISTRESS ALERT - OK

NCS/NCC/F0+R+N0/DISTRESS ALERT ACK

Expected result: The MES should send the Distress Alert on the NCS Signalling channel. Alert OK

2 LOG-IN and LOG OUT

With the MES's memory cleared, initiate a request for Log-in with network version number 0.

(a) Make the transmission of the Log-in Request packet fail

MES/NSIG/F0/LOGIN REQUEST - FAIL

Expected result: The MES should repeat the Log-in MaxC times and then report Log-in Fail.

(b) Initiate again a Log-in Request with Network version 0, make the transmission of the Log-in
Request packet successful and suppress transmission of the Login Acknowledgement packet.
Then, making the next Log-in Request packet also successful, transmit a Login
Acknowledgement packet after R+N1 frames. Interrogate the DCE via the DTE Operators
keyboard about the Network Information received in the Login Acknowledgement.

MES/NSIG/F0/LOGIN REQUEST - OK

MES/NSIG/F1/LOGIN REQUEST - OK

NCS/NCC/F0+R+N1/LOGIN ACKNOWLEDGEMENT

Expected result: LOGIN OK. Network configuration information stored.

(c) Initiate again a Log-in Request (Network version number as indicated in the bulletin board)
make the transmission of the Log-in Request packet successful and transmit a Login
Acknowledgement packet after R+N1 frames (no network configuration information).
Interrogate the DCE via the DTE Operators keyboard about the Network Information received
in the Login Acknowledgement (unchanged).

MES/NSIG/F0/LOGIN REQUEST - OK

NCS/NCC/F0+R+N2/LOGIN ACKNOWLEDGEMENT

MES/NSIG/F1/LOGIN REQUEST - OK

NCS/NCC/F0+R+N1/LOGIN ACKNOWLEDGEMENT

Expected result: LOGIN OK.

Recommended Test Procedures (RTPs), Page: 108


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(d) Repeat as in c), but instead of a Login Acknowledgement, use a Request Status (Barred
Mobile) packet

MES/NSIG/F0/LOGIN REQUEST - OK

NCS/NCC/F0+R+N2/LOGIN ACKNOWLEDGEMENT

MES/NSIG/F1/LOGIN REQUEST - OK

NCS/NCC/F0+R+N1/REQUEST STATUS (Request Barred)

Expected result: LOGIN FAIL - REJECTED

(e) For SES only: Whilst awaiting the Login acknowledgement, send a distress alert at the DTE

MES/NSIG/F0/LOGIN REQUEST - OK

MES/CSIG/F1/DISTRESS ALERT - OK

LES/TDM/F1+R+N1/DISTRESS ALERT ACK

Expected result: Alert OK.

(f) Enter a new NCS ID and channel number in the NCS ID list as follows:

NCS ID 145

Channel No. 12790

Initiate a login request to the NCS (144) and in the login acknowledgement force the MES to tune to
channel 12790.

MES/NSIG/F0/LOGIN REQUEST - OK

NCS/NCC/F0+R+N1/LOGIN ACKNOWLEDGEMENT - 12790

Expected result: LOGIN OK. After the successful Log-in, the MES retunes to the common channel on
12790 and attempt to log-in using an MES Signalling channel associated with the new NCS common
channel.

(g) Initiate a login request to the NCS (144).

Expected Result: The network version number in login request packet should be zero.

(h) Initiate again a login request to the NCS (144).

Expected Result: The network version number in login request packet should be the same as what is
given in the login ACK in step (g).

(i) Make the transmission of the Logout fail

MES/NSIG/F0/LOGOUT - FAIL

Expected result: Logout FAIL after MaxC retransmissions

Recommended Test Procedures (RTPs), Page: 109


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(j) Initiate again a Logout Request make the transmission of the Logout Request packet
successful and transmit a Logout Acknowledgement packet after N2(T0) frames then making
the next Logout Request packet successful transmit another Logout Acknowledgement packet
after N1(T0) frames. Interrogate the DCE via the keyboard about the network information.

MES/NSIG/F0/LOGOUT - OK

NCS/NCC/F0+R+N2/LOGOUT ACKNOWLEDGEMENT

MES/NSIG/F1/LOGOUT - OK

NCS/NCC/F1+R+N1/LOGOUT ACKNOWLEDGEMENT

Expected result: OK- Network information available.

(h) Initiate a login request to the NCS (144).

Expected Result: The network version number in login request packet should be the same as what is
given in the login ACK in step (g).

3 FROM-MOBILE MESSAGE TRANSFER

LES Operating with a Permanent TDM

Login and prepare a test message and initiate a From-Mobile message transfer to the LES with
permanent TDM.

(a) Make the transmission of the Assignment Request fail

MES/CSIG/F0/ASSIGNMENT REQUEST - FAIL

Expected result: ASSIGNMENT FAIL after MaxC retransmissions.

(b) Initiate again the From-Mobile message transfer, make the transmission of the Assignment
Request packet successful but do not transmit an Assignment packet. Following the MaxCC
attempt to transmit the Assignment request, send an assignment from the LES late; interrogate
the DCE via the keyboard about the status of the transaction.

MES/CSIG/F0/ASSIGNMENT REQUEST - OK

......

MES/CSIG/Fn/ASSIGNMENT REQUEST - OK

LES/TDM/Fn+R+N2/LOGICAL CHANNEL ASSIGNMENT

Expected result: ASSIGNMENT FAIL

c) Initiate again the From-Mobile message transfer, make the transmission of the Assignment
Request packet successful and transmit a Forced Clear packet

MES/CSIG/F0/ASSIGNMENT REQUEST - OK

LES/TDM/F0+R+N1/FORCED CLEAR

Recommended Test Procedures (RTPs), Page: 110


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Expected result: FAIL-CLEARED DOWN

(d) Initiate again a From-Mobile message transfer, make the Assignment Request packet
successful and send a Request Status packet as "Rejected"

MES/CSIG/F0/ASSIGNMENT REQUEST - OK

LES/TDM/F0+R+N1/REQUEST STATUS(Rejected)

Expected result: Transfer FAIL-CALL REJECTED

(e) Initiate again a From-Mobile message transfer, make the Assignment Request packet
successful and send a Logical Channel Assignment. Whilst the MES is waiting to transmit the
message send a forced clear from the LES before the MES is scheduled to transmit the
message.

MES/CSIG/F0/ASSIGNMENT REQUEST - OK

LES/TDM/F0+R+N1/LOGICAL CHANNEL ASSIGNMENT

LES/TDM/F1/FORCED CLEAR

Expected Result: Transfer FAIL-FORCED CLEARED

(f) Initiate again the From-Mobile message transfer make the transmission of the Assignment
Request packet successful and transmit an Assignment packet after N1 frames. Acknowledge
the Test Message after N2 frames.

MES/CSIG/F0/ASSIGNMENT REQUEST - OK

LES/TDM/F0+R+N1/LOGICAL CHANNEL ASSIGNMENT

MES/MSG/F1/Test Message

LES/TDM/F(EOM)+N2/ACKNOWLEDGEMENT

MES/SIG/F2/TRANSFER STATUS REQUEST - OK

LES/TDM/F2+R+N2/ACKNOWLEDGEMENT

MES/CSIG/Fn/TRANSFER STATUS REQUEST - OK

LES/TDM/Fn+R+N2/ACKNOWLEDGEMENT

Note: F1 is the frame number assigned by the LES.

Expected result: After MaxCC attempts FAIL-TIMEOUT should be reported.

(g) As above but with a Clear packet from the LES after the first time-out

MES/CSIG/F0/ASSIGNMENT REQUEST - OK

Recommended Test Procedures (RTPs), Page: 111


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

LES/TDM/F0+R+N1/LOGICAL CHANNEL ASSIGNMENT

MES/MSG/F1/Test Message

LES/TDM/F(EOM)+N2/CLEAR

MES/CSIG/F2/TRANSFER STATUS REQUEST - OK

LES/TDM/F2+R+N1/CLEAR

Expected result: Successful Transfer

(h) As above but with an Acknowledgement packet for only a part of the message

MES/CSIG/F0/ASSIGNMENT REQUEST - OK

LES/TDM/F0+R+N1/LOGICAL CHANNEL ASSIGNMENT

MES/MSG/F1/Test Message

LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT(Part)

MES/MSG/F2/Test Message(Missing Part)

LES/TDM/F(EOMP)+N1/CLEAR

Expected result: Successful Transfer

(i) As above but with a subsequent assignment after the first message transfer (retransmit the
whole message)

MES/CSIG/F0/ASSIGNMENT REQUEST - OK

LES/TDM/F0+N1/LOGICAL CHANNEL ASSIGNMENT

MES/MSG/F1/Test Message

LES/TDM/F(EOM)+N1/LOGICAL CHANNEL ASSIGNMENT

MES/MSG/F2/Test Message

LES/TDM/F(EOM)+N1/CLEAR

Note: N2 is the frame number assigned by the LES

Expected result: Successful Transfer

(j) As (h) but with a Forced Clear packet

MES/CSIG/F0/ASSIGNMENT REQUEST - OK

LES/TDM/F0+R+N1/LOGICAL CHANNEL ASSIGNMENT

MES/MSG/F1/Test Message

LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT(Part)

Recommended Test Procedures (RTPs), Page: 112


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

MES/MSG/F2/Test Message(Part)

LES/TDM/F(EOMP)+N1/FORCED CLEAR

Expected result: Transfer FAIL-CLEARED DOWN

(k) As above, but with a Request Status as "Pending". Issue Forced Clear at the DTE Operator
console. The Forced Clear Echo from the NCS(LES) is delayed so that MES times out and
repeats.

MES/CSIG/F0/ASSIGNMENT REQUEST - OK

LES/TDM/F0+R+N1/REQUEST STATUS(Pending)

MES/NSIG/F2/FORCED CLEAR - OK

NCS/NCC/F2+R+N2/FORCED CLEAR

MES/NSIG/F3/FORCED CLEAR - OK

NCS/NCC/F3+R+N1/FORCED CLEAR

Expected result: Transfer Fail.

(l) As above, but with a Request Status as "Pending". In frame N1(T1), send an Announcement
packet make the Announcement Response successful. Continue with a successful
Assignment, Message Transfer and Clear.

MES/CSIG/F0/ASSIGNMENT REQUEST - OK

LES/TDM/F1/REQUEST STATUS(Pending)

NCS/NCC/F1+N1/ANNOUNCEMENT

MES/CSIG/F2/ANNOUNCEMENT RESPONSE - OK

LES/TDM/F2+R+N1/LOGICAL CHANNEL ASSIGNMENT

MES/MSG/F3/Test Message

LES/TDM/F(EOM)+N1/CLEAR

Note: F3 is the frame number assigned by the LES.

Expected result: Successful Transfer

(m) Make the Announcement Response fail

MES/CSIG/F0/ASSIGNMENT REQUEST - OK

LES/TDM/F0+R+N1/REQUEST STATUS(Pending)

NCS/NCC/F0+N1+70/ANNOUNCEMENT

MES/CSIG/F1/ANNOUNCEMENT RESPONSE - FAIL

Recommended Test Procedures (RTPs), Page: 113


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Expected result: Transfer FAIL after MaxC retransmissions of Announcement Response

(n) Request an assignment requiring confirmation. Send a message and perform normal
acknowledgement and clearing. Then send a Confirmation packet from the NCS. Repeat this
test with various settings for the Message Status field. Use the Operator query Message Status
to verify the correct reception of this packet.

MES/CSIG/F0/ASSIGNMENT REQUEST - OK

LES/TDM/F0+R+N1/LOGICAL CHANNEL ASSIGNMENT

MES/MSG/F1/Test Message

LES/TDM/F(EOM)+N1/CLEAR

NCS/NCC/F2/CONFIRMATION

Expected result: Successful Transfer and Message Status displayed should agree with that sent.

(o) Perform (n) once more and following message transmission and confirmation, transmit a
Message Status Request to the LES and confirm that the Message Status packet is received.

MES/CSIG/F0/ASSIGNMENT REQUEST - OK

LES/TDM/F0+R+N1/LOGICAL CHANNEL ASSIGNMENT

MES/MSG/F1/Test Message

LES/TDM/F(EOM)+N1/CLEAR

NCS/NCC/F2/CONFIRMATION

MES/CSIG/F3/MESSAGE STATUS REQUEST - OK

NCS/TDM/F3+R+N1/MESSAGE STATUS

Expected result: Successful transfer and message status should agree with that sent.

(p) For SES only: Initiate the From-Mobile message transfer, make the transmission of the
Assignment Request packet successful and transmit the Distress Alert when awaiting the
assignment.

MES/CSIG/F0/ASSIGNMENT REQUEST - OK

MES/CSIG/F1/DISTRESS ALERT - OK

LES/TDM/F1+R+N1/DISTRESS ALERT ACK

Expected result: Alert OK

(q) For SES only: Initiate again the From-Mobile message transfer, make the transmission of the
assignment request packet successful and send a Logical Channel Assignment. Send the
Distress Alert after reception of the logical channel assignment.

MES/CSIG/F0/ASSIGNMENT REQUEST - OK

Recommended Test Procedures (RTPs), Page: 114


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

LES/TDM/F0+R+N1/LOGICAL CHANNEL ASSIGNMENT

MES/CSIG/F1/DISTRESS ALERT - OK

LES/TDM/F1+R+N1/DISTRESS ALERT ACK

Expected result: Alert OK.

(r) For SES only:

i) Repeat (n) but following the message transmit the Distress Alert whilst awaiting the
Clear.

MES/CSIG/F0/ASSIGNMENT REQUEST - OK

LES/TDM/F0+R+N1/LOGICAL CHANNEL ASSIGNMENT

MES/CSIG/F1/Test Message

MES/CSIG/F2/DISTRESS ALERT - OK

LES/TDM/F2+R+N1/DISTRESS ALERT ACK

Expected result: Alert OK.

ii) Repeat (n) but transmit the Distress Alert during pending period.

MES/NSIG/F0/ASSIGNMENT REQUEST - OK

NCS/NCC/F0+R+N1/REQUEST STATUS(pending)

MES/CSIG/F2/DISTRESS ALERT - OK

LES/TDM/F2+R+N1/DISTRESS ALERT ACK

Expected result: Alert OK.

LES Operating with a Demand Assigned TDM

(s) LES operating in the demand assigned mode. Normal call completion.

MES/NSIG/F0/ASSIGNMENT REQUEST - OK

NCS/NCC/F0+R+N1/REQUEST STATUS(pending)

NCS/NCC/F1+R+N1/ANNOUNCEMENT(From-Mobile)

MES/CSIG/F2/ANNOUNCEMENT RESPONSE - OK

LES/TDM/F2+R+N1/LOGICAL CHANNEL ASSIGNMENT

MES/MSG/F3/Test Message

LES/TDM/F(EOM)+N1/CLEAR

Note: N3 is the frame number assigned by the LES.

Recommended Test Procedures (RTPs), Page: 115


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Expected result: Transfer successful.

(t) Unexpected Announcement from NCS or (pended) message lost. The Forced Clear echo from
the NCS(LES) is delayed so that MES times out and repeats.

NCS/NCC/F0/ANNOUNCEMENT

MES/NSIG/F1/FORCED CLEAR - OK

NCS/NCC/F1+R+N2/FORCED CLEAR

MES/NSIG/F2/FORCED CLEAR - OK

NCS/NCC/F2+R+N1/FORCED CLEAR

Expected result: Transfer Fail.

(u) Repeat Test (t) but without undue delay and return a Forced Clear.

NCS/NCC/F0/ANNOUNCEMENT

MES/NSIG/F1/FORCED CLEAR - OK

NCS/NCC/F1+R+N1/FORCED CLEAR

Expected result: Transfer Fail.

(v) For SES only: Repeat Test (t) but without undue delay and send a Distress alert whilst
awaiting the forced clear echo.

NCS/NCC/F0/ANNOUNCEMENT

MES/NSIG/F1/FORCED CLEAR - OK

MES/CSIG/F2/DISTRESS ALERT - OK

LES/TDM/F2+R+N1/DISTRESS ALERT ACK

Expected result: Alert OK.

(w) Repeat (s) but send the announcement immediately and after receiving Clear packet send a
message status request to the NCS.

MES/NSIG/F0/ASSIGNMENT REQUEST - OK

NCS/TDM/F0+R+N1/ANNOUNCEMENT (From-Mobile)

MES/CSIG/F2/ANNOUNCEMENT RESPONSE

LES/TDM/F2+R+N1/LOGICAL CHANNEL ASSIGNMENT

MES/MSG/F3/Test Message

LES/TDM/F(EOM)+N1/CLEAR

(LES TDM assignment ceases after the clear)

Recommended Test Procedures (RTPs), Page: 116


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

MES/NSIG/F5/MESSAGE STATUS REQUEST - OK

NCS/TDM/F5+R+N1/MESSAGE STATUS

Expected result: Successful transfer and message status should agree with that sent.

(x) Repeat (s) but make the announcement response fail the first time.

MES/NSIG/F0/ASSIGNMENT REQUEST - OK

NCS/NCC/F0+R+N1/REQUEST STATUS(pending)

NCS/TDM/F1/ANNOUNCEMENT (From-Mobile)

MES/CSIG/F2/ANNOUNCEMENT RESPONSE - FAIL

NCS/NCC/F2+N1/ANNOUNCEMENT (From-Mobile)

MES/CSIG/F3/ANNOUNCEMENT RESPONSE - OK

LES/TDM/F3+R+N1/LOGICAL CHANNEL ASSIGNMENT

MES/MSG/F4/Test Message

LES/TDM/F(EOM)+N1/CLEAR

Note: N4 is the frame number assigned by the LES.

Expected result: Announcement response failed after MaxC retransmissions and the MES should
handle the following Announcement followed by the successful transfer.

(y) For SES only: Repeat (s) but send a distress alert when awaiting the assignment.

MES/NSIG/F0/ASSIGNMENT REQUEST - OK

MES/NSIG/F1/DISTRESS ALERT - OK

NCS/NCC/F1+R+N1/DISTRESS ALERT ACK

Expected result: Alert OK.

(z) Repeat (s) but send a distress alert after reception of the logical channel assignment.

MES/NSIG/F0/ASSIGNMENT REQUEST - OK

NCS/TDM/F0+R+N1/ANNOUNCEMENT (From-Mobile)

MES/CSIG/F2/ANNOUNCEMENT RESPONSE

LES/TDM/F2+N1/LOGICAL CHANNEL ASSIGNMENT

MES/NSIG/F3/DISTRESS ALERT - OK

NCS/NCC/F3+R+N1/DISTRESS ALERT ACK

Expected result: Alert OK.

Recommended Test Procedures (RTPs), Page: 117


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4 TO-MOBILE MESSAGE TRANSFER

LES Operating with a Permanent TDM

(a) Send an Announcement packet (To-Mobile) and make the subsequent Assignment Response
fail

NCS/NCC/F0/ANNOUNCEMENT

MES/CSIG/F1/ASSIGNMENT RESPONSE - FAIL

Expected result: Assignment FAIL after MaxC retransmissions.

(b) Send an Announcement packet (To-Mobile) and make the subsequent Assignment Response
successful, send a Forced Clear packet

NCS/NCC/F0/ANNOUNCEMENT

MES/CSIG/F1/ASSIGNMENT RESPONSE - OK

LES/TDM/F1+R+N1/FORCED CLEAR

Expected result: Anomaly Forced Clear

(c) Send an Announcement packet (To-Mobile) and make the subsequent Assignment Response
successful, then issue a Forced Clear from the DTE Operators Console.

NCS/NCC/F0/ANNOUNCEMENT

MES/CSIG/F1/ASSIGNMENT RESPONSE - OK

MES/CSIG/F2/FORCED CLEAR - OK

LES/TDM/F2+R+N1/FORCED CLEAR

Expected result: Forced Clear

(d) Send an Announcement packet (To-Mobile) and make the subsequent Assignment Request
successful, send the Message after timeout at the MES so that the MES requests Transfer
Status.

NCS/F0/ANNOUNCEMENT

MES/F1/ASSIGNMENT RESPONSE - OK

LES/TDM/F1+R+N2/Test Message

MES/CSIG/F2/TRANSFER STATUS REQUEST - OK

LES/TDM/F2+R+N1/ACKNOWLEDGEMENT REQUEST

MES/CSIG/F(FO1)/ACKNOWLEDGEMENT (Whole Message) -OK

LES/TDM/F(FO1)+4/Test Message

LES/TDM/F4/ACKNOWLEDGEMENT REQUEST

Recommended Test Procedures (RTPs), Page: 118


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

MES/CSIG/F(FO2)/ACKNOWLEDGEMENT (no error) - OK

LES/TDM/F(FO2)+R+N1/CLEAR

Note: FO1 and FO2 mean the frame offset specified by the LES for the reserve access.

Expected result: The MES sends the Transfer Status Request and make the call successful.

(e) Send an Announcement packet (To-Mobile) and make the subsequent Assignment Response
successful, send the Message and Request Acknowledgement. When the MES acknowledges
make the transmission fail.

NCS/NCC/F0/ANNOUNCEMENT

MES/CSIG/F1/ASSIGNMENT RESPONSE - OK

LES/TDM/F1+4/Test Message

LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT REQUEST

MES/CSIG/F(FO)/ACKNOWLEDGEMENT (NO ERRS) - FAIL

Expected result: Acknowledgement fail after MaxF retransmissions.

(f) Repeat e) but make the acknowledgement succeed. Then send a Forced Clear.

NCS/NCC/F0/ANNOUNCEMENT

MES/CSIG/F1/ASSIGNMENT RESPONSE - OK

LES/TDM/F1+4/Test Message

LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT REQUEST

MES/CSIG/F(FO)/ACKNOWLEDGEMENT (NO ERRS) - OK

LES/TDM/F(FO)+R+N1/FORCED CLEAR

Expected result: Fail. Message unavailable

(g) For SES only: Send an Announcement packet (To-Mobile) and make the subsequent
Assignment Response successful, then transmit the Distress Alert.

NCS/NCC/F0/ANNOUNCEMENT

MES/CSIG/F1/ASSIGNMENT RESPONSE - OK

MES/CSIG/F2/DISTRESS ALERT - OK

LES/TDM/F2+R+N1/DISTRESS ALERT ACK

Expected result: Alert OK

(h) For SES only: Send an Announcement packet (To-Mobile) and make the subsequent
Assignment Response successful, send the Message and issue the Distress Alert.

Recommended Test Procedures (RTPs), Page: 119


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

NCS/NCC/N0/ANNOUNCEMENT

MES/CSIG/F1/ASSIGNMENT RESPONSE - OK

LES/TDM/F1+4/Test Message

MES/CSIG/F2/DISTRESS ALERT -OK

LES/TDM/F2+R+N1/DISTRESS ALERT ACK

Expected result: Alert OK

(i) For SES only: Send an Announcement packet (To-Mobile) and make the subsequent
Assignment Response successful, send the Message and Request Acknowledgement. Make
the Acknowledgement successful and issue the Distress Alert.

NCS/NCC/F0/ANNOUNCEMENT

MES/CSIG/F1/ASSIGNMENT RESPONSE - OK

LES/TDM/F1+4/Test Message

LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT REQUEST

MES/CSIG/F(FO)/ACKNOWLEDGEMENT - OK

MES/CSIG/F2/DISTRESS ALERT - OK

LES/TDM/F2+R+N1/DISTRESS ALERT ACK

Expected result: Alert OK

(j) Repeat f) but send a normal Clear at end.

NCS/NCC/F0/ANNOUNCEMENT

MES/CSIG/F1/ASSIGNMENT RESPONSE - OK

LES/TDM/F1+4/Test Message

LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT REQUEST

MES/CSIG/F(FO)/ACKNOWLEDGEMENT (NO ERRS) - OK

LES/TDM/F(FO)+R+N1/CLEAR

Expected result: OK-Message available.

(k) Send an Announcement packet (To-Mobile) and make the subsequent Assignment Response
successful, send the Message with 3 blocks in error and request Acknowledgement.
Retransmit the requested blocks without error, Request Acknowledgement and, after receipt of
acknowledgement, perform a normal Clear.

NCS/NCC/F0/ANNOUNCEMENT

MES/CSIG/F1/ASSIGNMENT RESPONSE - OK

Recommended Test Procedures (RTPs), Page: 120


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

LES/TDM/F1+4/Test Message(3 Blocks Error)

LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT REQUEST

MES/CSIG/F(FO1)/ACKNOWLEDGEMENT (3 Blocks Error) - OK

LES/TDM/F(FO1)+4/Test Message(Missing Blocks)

LES/TDM/F(EOMP)+N1/ACKNOWLEDGEMENT REQUEST

MES/CSIG/F(FO2)/ACKNOWLEDGEMENT (No Errors) - OK

LES/TDM/F(FO2)+R+N1/CLEAR

Expected result: OK-Message available.

(l) Repeat Test (j), but instead of Clearing perform a follow-on call by issuing an Assignment.

NCS/NCC/F0/ANNOUNCEMENT

MES/CSIG/F1/ASSIGNMENT RESPONSE - OK

LES/TDM/F1+4/Test Message 1

LES/TDM/F(EOM1)+N1/ACKNOWLEDGEMENT REQUEST

MES/CSIG/F(FO1)/ACKNOWLEDGEMENT (No Errors) - OK

LES/TDM/F(FO1)+R+N1/LOGICAL CHANNEL ASSIGNMENT

MES/CSIG/F2/ASSIGNMENT RESPONSE - OK

LES/TDM/F2+4/Test Message 2 (3 Blocks Error)

LES/TDM/F(EOM2)+N1/ACKNOWLEDGEMENT REQUEST

MES/CSIG/F(FO2)/ACKNOWLEDGEMENT(3 Blocks Error) - OK

LES/TDM/F(FO2)+4/Test Message(Missing Blocks)

LES/TDM/F(EOMP)+N1/ACKNOWLEDGEMENT REQUEST

MES/SIG/F(FO3)/ACKNOWLEDGEMENT (No Errors) - OK

LES/TDM/F(FO3)+R+N1/CLEAR

Expected result: OK-Message available.

(m) Send an Announcement packet (To-Mobile) and make the subsequent Assignment Response
successful, send the Message. Request Acknowledgement after the timeout at the MES, so
that the MES Requests Transfer Status. Repeat the Acknowledgement Request in good time,
but send the Clear late after receiving the Acknowledgement, so that the MES again Requests
Transfer Status. Finally Clear in good time.

NCS/NCC/F0/ANNOUNCEMENT

Recommended Test Procedures (RTPs), Page: 121


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

MES/CSIG/F1/ASSIGNMENT RESPONSE - OK

LES/TDM/F2/Test Message

LES/TDM/F(EOM)+N2/ACKNOWLEDGEMENT REQUEST

MES/CSIG/F3/REQUEST TRANSFER STATUS - OK

LES/TDM/F3+R+N1/ACKNOWLEDGEMENT REQUEST

MES/CSIG/F(FO)/ACKNOWLEDGEMENT(no error) - OK

LES/TDM/F(FO)+R+N2/CLEAR

MES/CSIG/F4/REQUEST TRANSFER STATUS - OK

LES/TDM/F4+R+N1/CLEAR

Expected result: Anomaly Timeout, should be reported on both occasions, but final result should be
OK-Message available.

5 PERFORMANCE VERIFICATION TEST

(a) Issue a PV Test Announcement from the NCS. Attempt a To-Mobile message transfer, but
cause the Assignment Response to fail.

NCS/NCC/F0/ANNOUNCEMENT(PVT)

MES/CSIG/F1/ASSIGNMENT RESPONSE - FAIL

Expected result: PVT Fail after MaxC retransmissions

(b) Issue a PV Test Announcement from the NCS. Perform a successful To-Mobile message
transfer. Attempt a From-Mobile message transfer but make the Assignment Request fail.
Repeat the attempt, failing each time, a total of MaxPVT times.

NCS/NCC/F0/ANNOUNCEMENT(PVT)

MES/CSIG/F1/ASSIGNMENT RESPONSE - OK

LES/TDM/F2/Test Message

LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT REQUEST

MES/CSIG/F(FO)/ACKNOWLEDGEMENT (NO ERRS) - OK

LES/TDM/F(FO)+R+N1/CLEAR

MES/CSIG/F3/ASSIGNMENT REQUEST - FAIL

MES/CSIG/Fn/ASSIGNMENT REQUEST - FAIL

Recommended Test Procedures (RTPs), Page: 122


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Expected result: PVT Fail after MaxPVT attempts each of which failed after MaxC retransmissions.

(c) Issue a PV Test Announcement from the NCS. Perform a successful To-Mobile message
transfer. Perform a successful From-Mobile message transfer. Issue a late Distress Test
Request from the LES causing a timeout and cause the attempt to send a Transfer Status
Request to fail.

NCS/NCC/F0/ANNOUNCEMENT(PVT)

MES/CSIG/F1/ASSIGNMENT RESPONSE - OK

LES/TDM/F2/Test Message

LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT REQUEST

MES/CSIG/F(FO)/ACKNOWLEDGEMENT (NO ERRS) - OK

LES/TDM/F(FO)+R+N1/CLEAR

MES/CSIG/F3/ASSIGNMENT REQUEST - OK

LES/TDM/F3+R+N1/LOGICAL CHANNEL ASSIGNMENT

MES/MSG/F4/Test Message

LES/TDM/F(EOM)+N1/CLEAR

LES/TDM/F5+N2/DISTRESS TEST REQUEST

MES/CSIG/F6/TRANSFER STATUS REQUEST - FAIL

Note: F4 is the frame number assigned by the LES and F5 is equal to the frame number (F(EOM)+N1)
where the Clear packet is sent.

Expected result: PVT Fail after MaxC retransmissions.

(d) Issue a PV Test Announcement from the NCS. Perform a successful To-Mobile message
transfer. Perform a successful From-Mobile message transfer. Issue a late Distress Test
Request from the LES causing a timeout and cause the attempt to send a Transfer Status
Request to succeed. Again issue a Distress Test Request and perform a Distress Test. Send
the Test Result too late causing a timeout and cause the attempt to send a Transfer Status
Request to fail.

NCS/NCC/F0/ANNOUNCEMENT(PVT)

MES/CSIG/F1/ASSIGNMENT RESPONSE - OK

LES/TDM/F2/Test Message

LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT REQUEST

MES/CSIG/F(FO)/ACKNOWLEDGEMENT (NO ERRS) - OK

LES/TDM/F(FO)+R+N1/CLEAR

Recommended Test Procedures (RTPs), Page: 123


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

MES/CSIG/F3/ASSIGNMENT REQUEST - OK

LES/TDM/F3+R+N1/LOGICAL CHANNEL ASSIGNMENT

MES/MSG/F4/Test Message

LES/TDM/F(EOM)+N1/CLEAR

LES/TDM/F5+N2/DISTRESS TEST REQUEST

MES/CSIG/F6/TRANSFER STATUS REQUEST - OK

LES/TDM/F6+R+N1/DISTRESS TEST REQUEST

MES/CSIG/F7/DISTRESS ALERT(TEST) - OK

LES/TDM/F7+R+N1/DISTRESS ALERT ACKNOWLEDGEMENT

LES/TDM/F8+N2/TEST RESULT

MES/CSIG/F9/TRANSFER STATUS REQUEST - FAIL

Note: F8 is equal to the frame number (F7+R+N1) where the Distress Alert Acknowledgement packet
is sent.

Expected result: PVT Fail after MaxC retransmissions.

(e) Repeat Test (d) but make the Transfer Status Request succeed. Then issue a Test Result in
good time but make the Test Result Acknowledgement fail.

NCS/NCC/F0/ANNOUNCEMENT(PVT)

MES/CSIG/F1/ASSIGNMENT RESPONSE - OK

LES/TDM/F2/Test Message

LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT REQUEST

MES/CSIG/F(FO1)/ACKNOWLEDGEMENT (NO ERRS) - OK

LES/TDM/F(FO1)+R+N1/CLEAR

MES/CSIG/F3/ASSIGNMENT REQUEST - OK

LES/TDM/F3+R+N1/LOGICAL CHANNEL ASSIGNMENT

MES/MSG/F4/Test Message

LES/TDM/F(EOM)+N1/CLEAR

LES/TDM/F5+N2/DISTRESS TEST REQUEST

MES/CSIG/F6/TRANSFER STATUS REQUEST - OK

LES/TDM/F6+R+N1/DISTRESS TEST REQUEST

Recommended Test Procedures (RTPs), Page: 124


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

MES/CSIG/F7/DISTRESS ALERT(TEST) - OK

LES/TDM/F7+R+N1/DISTRESS ALERT ACKNOWLEDGEMENT

LES/TDM/F8+N2/TEST RESULT

MES/CSIG/F9/TRANSFER STATUS REQUEST - OK

LES/TDM/F9+R+N1/TEST RESULT

MES/CSIG/F(FO2)/TEST RESULT ACKNOWLEDGEMENT - FAIL

MES/CSIG/F10/TRANSFER STATUS REQUEST - OK

MES/CSIG/F10+7/TRANSFER STATUS REQUEST - OK

LES/TDM/F10+7+N1/FORCED CLEAR

Expected result: PVT Fail.

(f) Repeat Test (e) and make the Test Result Acknowledgement succeed. Perform a LES Clear.
Use the DTE Operator Test Result Query to check the returned Result and repeat the test with
various settings of the Test Result field in the packet.

NCS/NCC/F0/ANNOUNCEMENT(PVT)

MES/CSIG/F1/ASSIGNMENT RESPONSE - OK

LES/TDM/F2/Test Message

LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT REQUEST

MES/CSIG/F(FO1)/ACKNOWLEDGEMENT (NO ERRS) - OK

LES/TDM/F(FO1)+R+N1/CLEAR

MES/CSIG/F3/ASSIGNMENT REQUEST - OK

LES/TDM/F3+R+N1/LOGICAL CHANNEL ASSIGNMENT

MES/MSG/F4/Test Message

LES/TDM/F(EOM)+N1/CLEAR

LES/TDM/F5+N2/DISTRESS TEST REQUEST

MES/CSIG/F6/TRANSFER STATUS REQUEST - OK

LES/TDM/F6+R+N1/DISTRESS TEST REQUEST

MES/CSIG/F7/DISTRESS ALERT(TEST) - OK

LES/TDM/F7+R+N1/DISTRESS ALERT ACKNOWLEDGEMENT

LES/TDM/F8+N2/TEST RESULT

Recommended Test Procedures (RTPs), Page: 125


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

MES/CSIG/F9/TRANSFER STATUS REQUEST - OK

LES/TDM/F9+R+N1/TEST RESULT

MES/CSIG/F(FO2)/TEST RESULT ACKNOWLEDGEMENT - OK

LES/TDM/F(FO2)+R+N1/CLEAR

Expected result: PVT OK. The Test Result shown at the Operator's console should agree with that sent.

(g) Issue a PV test announcement from the NCS. Perform successful To-Mobile and From-Mobile
message transfers. Perform a successful distress alert test but do not send the test results from the LES.

NCS/NCC/F0/ANNOUNCEMENT(PVT)

MES/CSIG/F1/ASSIGNMENT RESPONSE - OK

LES/TDM/F2/Test Message

LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT REQUEST

MES/CSIG/F(FO1)/ACKNOWLEDGEMENT (NO ERRS) - OK

LES/TDM/F(FO1)+R+N1/CLEAR

MES/CSIG/F3/ASSIGNMENT REQUEST - OK

LES/TDM/F3+R+N1/LOGICAL CHANNEL ASSIGNMENT

MES/MSG/F4/Test Message

LES/TDM/F(EOM)+N1/CLEAR

LES/TDM/F5/DISTRESS TEST REQUEST

MES/CSIG/F6/DISTRESS ALERT(TEST) - OK

LES/TDM/F6+R+N1/DISTRESS ALERT ACKNOWLEDGEMENT

MES/CSIG/F7/TRANSFER STATUS REQUEST - OK

Expected result: The transfer status request (waiting for test results) is sent MaxCC-1 times and the
PVT fails (timeout).

(h) Issue a PVT Test Announcement from the NCS. Perform successful To-Mobile and From-Mobile
message transfers. Perform a successful distress alert test and send the test results from the LES but do
not send the final clear.

NCS/NCC/F0/ANNOUNCEMENT(PVT)

MES/CSIG/F1/ASSIGNMENT RESPONSE - OK

LES/TDM/F2/Test Message

LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT REQUEST

Recommended Test Procedures (RTPs), Page: 126


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

MES/CSIG/F(FO1)/ACKNOWLEDGEMENT (NO ERRS) - OK

LES/TDM/F(FO1)+R+N1/CLEAR

MES/CSIG/F3/ASSIGNMENT REQUEST - OK

LES/TDM/F3+R+N1/LOGICAL CHANNEL ASSIGNMENT

MES/MSG/F4/Test Message

LES/TDM/F(EOM)+N1/CLEAR

LES/TDM/F5+N1/DISTRESS TEST REQUEST

MES/CSIG/F7/DISTRESS ALERT(TEST) - OK

LES/TDM/F7+R+N1/DISTRESS ALERT ACKNOWLEDGEMENT

LES/TDM/F8/TEST RESULTS

MES/CSIG/F(FO1)/TEST RESULTS ACKNOWLEDGEMENT - OK

MES/CSIG/F9/TRANSFER STATUS REQUEST - OK

Note: F9 is equal to F(FO1)+R+7

Expected result: The transfer status request (waiting for clear) is sent MaxCC-1 times and the PVT fails
(timeout).

6 OPERATOR TEST REQUEST

(a) Issue a Test Request from the DTE Operator's console. Make the Test Request signal fail.

MES/NSIG/F0/TEST REQUEST - FAIL

Expected result: Test Request Fail after MaxC retransmissions.

(b) Issue a Test Request from the DTE Operator's console. Make the Test Request signal
succeed. Issue a PVT Announcement from the NCS and perform a PV Test.

MES/NSIG/F0/TEST REQUEST - OK

NCS/NCC/F0+R+N1/REQUEST STATUS (Pending)

NCS/NCC/F1+R+N1/ANNOUNCEMENT(PVT)

MES/CSIG/F2/ASSIGNMENT RESPONSE - OK

LES/TDM/F3/Test Message

LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT REQUEST

MES/CSIG/F(FO1)/ACKNOWLEDGEMENT (NO ERRS) - OK

Recommended Test Procedures (RTPs), Page: 127


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

LES/TDM/F(FO1)+R+N1/CLEAR

MES/CSIG/F4/ASSIGNMENT REQUEST - OK

LES/TDM/F4+R+N1/LOGICAL CHANNEL ASSIGNMENT

MES/MSG/F5/Test Message

LES/TDM/F(EOM)+N1/CLEAR

LES/TDM/F6+N1/DISTRESS TEST REQUEST

MES/CSIG/F7/DISTRESS ALERT(TEST) - OK

LES/TDM/F7+R+N1/DISTRESS ALERT ACKNOWLEDGEMENT

LES/TDM/F8+N1/TEST RESULT

MES/CSIG/F(FO2)/TEST RESULT ACKNOWLEDGEMENT - OK

LES/TDM/F(FO2)+R+N1/CLEAR

Note: F5 is the frame number assigned by the LES, F6 is equal to the frame number (F(EOM)+N1)
where the Clear packet is sent and F8 is equal to the frame number (F7+R+N1) where the Distress
Alert Acknowledgement packet is sent.

Expected result: Test Request OK. The Test Result shown at the Operator's console should agree with
that sent.

(c) Issue a Test Request from the DTE Operator's console. Send a Request Status from the NCS
but too late. Cause the Test Request to fail.

MES/NSIG/F0/TEST REQUEST - OK

NCS/NCC/F0+R+N2/REQUEST STATUS (Pending)

MES/NSIG/F1/TEST REQUEST - FAIL

Expected result: Test Request Fail after MaxC retransmissions.

(d) Issue a Test Request from the DTE Operator's console. Send a Request Status from the NCS
but too late. Cause the Test Request to succeed. Re-issue the Request Status and then send an
Announcement from the NCS.

MES/NSIG/F1/TEST REQUEST - OK

NCS/NCC/F1+R+N2/REQUEST STATUS (Pending)

MES/NSIG/F2/TEST REQUEST - OK

NCS/NCC/F2+R+N1/REQUEST STATUS (Pending)

NCS/NCC/F3+R+N1/ANNOUNCEMENT(PVT)

MES/CSIG/F4/ASSIGNMENT RESPONSE - OK

Recommended Test Procedures (RTPs), Page: 128


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

LES/TDM/F5/Test Message

LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT REQUEST

MES/CSIG/F(FO1)/ACKNOWLEDGEMENT (NO ERRS) - OK

LES/TDM/F(FO1)+R+N1/CLEAR

MES/CSIG/F6/ASSIGNMENT REQUEST - OK

LES/TDM/F6+R+N1/LOGICAL CHANNEL ASSIGNMENT

MES/MSG/F7/Test Message

LES/TDM/F(EOM)+N1/CLEAR

LES/TDM/F8+N1/DISTRESS TEST REQUEST

MES/CSIG/F9/DISTRESS ALERT(TEST) - OK

LES/TDM/F9+R+N1/DISTRESS ALERT ACKNOWLEDGEMENT

LES/TDM/F10+N1/TEST RESULT

MES/CSIG/F(FO2)/TEST RESULT ACKNOWLEDGEMENT - OK

LES/TDM/F(FO2)+R+N1/CLEAR

Note: F7 is the frame number assigned by the LES, F8 is equal to the frame number (F(EOM)+N1)
where the Clear packet is sent and F10 is equal to the frame number (F8+R+N1) where the Distress
Alert Acknowledgement packet is sent.

Expected result: PVT OK. The Test Result shown at the Operator's console should agree with that sent.

(e) Issue a Test Request from the DTE Operator's console. Don't send a Request Status from the
NCS but issue an Announcement.

MES/NSIG/F1/TEST REQUEST - OK

NCS/NCC/F1+R+N1/ANNOUNCEMENT(PVT)

MES/CSIG/F2/ASSIGNMENT RESPONSE - OK

LES/TDM/F3/Test Message

LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT REQUEST

MES/CSIG/F(FO1)/ACKNOWLEDGEMENT (NO ERRORS) - OK

LES/TDM/F(FO1)+R+N1/CLEAR

MES/CSIG/F4/ASSIGNMENT REQUEST - OK

LES/TDM/F4+R+N1/LOGICAL CHANNEL ASSIGNMENT

Recommended Test Procedures (RTPs), Page: 129


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

MES/MSG/F5/Test Message

LES/TDM/F(EOM)+N1/CLEAR

LES/TDM/F6+N1/DISTRESS TEST REQUEST

MES/CSIG/F7/DISTRESS ALERT(TEST) - OK

LES/TDM/F7+R+N1/DISTRESS ALERT ACKNOWLEDGEMENT

LES/TDM/F8+N1/TEST RESULT

MES/CSIG/F(FO2)/TEST RESULT ACKNOWLEDGEMENT - OK

LES/TDM/F(FO2)+R+N1/CLEAR

Note: F6 is equal to the frame number (F(EOM)+N1) where the Clear packet is sent and F8 is equal to
the frame number (F7+R+N1) where the Distress Alert Acknowledgement packet is sent.

Expected result: PVT OK.

Recommended Test Procedures (RTPs), Page: 130


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 6-A/1 POLLING AND DATA REPORTING TEST PROCEDURES

1 PURPOSE OF THE TEST

The test shall verify that the access control functions and signalling channel protocol implemented in
the MES under test are compliant with the requirements stated in SDM Volume 1, Volume 4, Volume
5 (sequence diagrams, SDL diagrams and packet format definitions) and in SDM Volume 3, Part 2,
Chapter 3, for Polling and Data Reporting.

2 APPLICABILITY

The test is generally applicable to all classes of Inmarsat-C MES, which support the Polling and Data
Reporting protocols. Some parts of the tests might not be needed for MES models designed for certain
specific applications (see 6 Test Procedure below).

The tests shall be performed first with a LES/NCS operating in a first generation scenario and then
repeated with a second generation scenario.

It has been assumed that the MES DCE - DTE interface has been implemented in accordance with the
recommended interface control codes of SDM Volume 3, Part 2, Chapter 4, allowing the interrogation
of the DCE by the operator. Alternative implementations are acceptable. However it is the
manufacturer's responsibility to submit amended test procedures highlighting the difference between
these procedures and ensuring that the full range of access control tests are still covered.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

The Test Set-up will consist of a NCS/LES simulator attached at RF or IF to the MES. The simulator
is described in Section 7 of this document.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator. The simulator is capable of simulating both normal and error conditions,
including timeouts, in a controlled way to determine the response of the MES under test to all
operational events.

Means for monitoring the results of unexpected events and displaying the information provided in DCE
Indicator messages must be provided.

(b) Other equipment will be used to check the operation of the MES at IF and RF and to
determine that the MES does tune to the appropriate channel at each stage of the test.

6 TEST PROCEDURE

The test procedures are described in the following pages. Part 1 covers Unreserved Data Reporting Part
2 covers Polling and Part 3 covers Reserved Data Reporting.

Recommended Test Procedures (RTPs), Page: 131


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

PART 1 UNRESERVED DATA REPORTING

Test Bulletin Board Setup

Network Version =1

Frame Number =-10 for the first

Signalling Channels =1

Two-frame Count =0

Empty Frame =0

Spare =0

Channel Type = 1 for NCS CC (or 2 for LES TDM)

Local ID =0

Spare =0

Origin ID = 1,44 (hex 6C) for NCS

(or LES Simulator ID for LES)

Status = X1110000 binary for NCS

(or X1111000 Binary for LES)

Services(byte one) = 10100010 binary for NCS

(or 10110010 Binary for LES)

Services(byte two) =0

Randomising = 10

Signalling Channel Descriptor

Available = 1 (Available for Store and Forward Message)

CUG = 1 (Available for Closed User Group use)

Maritime Distress = 1 (Available for Maritime Distress traffic)

Slotted = 1 (Slotted Aloha)

Land Mobile Alert = 1 (Available for Land Mobile Alert traffic)

Spare =0

Sat. Freq. code = As required for the simulator (NCS/LES)

Slot State Markers = 00 binary for all 28 slots

X indicates setting as required for test. The checksums should be set as required for each test.

Recommended Test Procedures (RTPs), Page: 132


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Test 1 Treatment of Bulletin Board and SCD

Test (1.a) Bad Bulletin Boards

(i) Connect the simulators and the MES. Set the NCS/LES TDM to send Basic Test Frames as
defined above.

(ii) Transmit a sequence of at least 100 Basic Test Frames from the NCS with a bad checksum for
the BB and a good checksum for the SCD.

(iii) Initiate a Data Report at the DTE.

Expected Result: The MES does not attempt to tune to the LES Signalling Channel and the DTE shows
the Data Report failed. The Current Channel is still NCS CC and the Status is idle.

Test (1.b) A sequence of three Bad Bulletin Boards

For this test, another Test Frame is defined for the NCS TDM only:

[Test Poll Frame ] ::= [BB][SCD][ Poll Pkt]

with the following field settings:

Bulletin Board same as for the Basic Test Frame, except that the Empty Frame field is set to 1;

SCD same as for the Basic Test Frame;

(i) Pre-program Unreserved Data Reporting parameters as follows:

DNID =4

LES ID = 111

LES TDM = TDM of the LES Simulator.

Sub-address =0

Randomising Interval =0

Start Frame =1

Interval = 100 frames

(ii) Prepare a Group Poll Packet (Initiate Unreserved Data Reporting):

DNID =4

LES ID = 111

LES TDM = TDM of the LES Simulator.

Sub-address =0

Randomising Interval =1

Response = 01

Recommended Test Procedures (RTPs), Page: 133


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Command =5

Sequence No. =1

(iii) Transmit a sequence of Basic Test Frames from the LES TDM channel, each with a bad
checksum for the BB and a good checksum for the SCD, preceded by a sequence with good
BBs and good SCDs on the NCS common channel but use the simulator to transmit to the
MES on the NCS Common Channel a Test Poll Frame in frame -3. In the N+1th frame reset
the BB checksum to good.

Rxd Frame BB Status SCD Status Packets TDM Source


Frame -5 good BB good SCD NCS
Frame -4 good BB good SCD ,,
Frame -3 good BB good SCD Group Poll ,,

Note: Frame(s) may be lost whilst the receiver re-tunes and synchronises with the LES TDM

Frame 1 bad BB good SCD LES


Frame 0 bad BB good SCD ,,
Frame -1 bad BB good SCD ,,
,, ,, ,, ,,
Frame N-3 bad BB good SCD ,,
Frame N-2 bad BB good SCD ,,
Frame N-1 bad BB good SCD ,,
Frame N bad BB good SCD [FAIL] ,,
Frame N+1 bad BB good SCD ,,
Expected result: The MES should tune to the LES TDM but not transmit the Data Report. After
N(MaxD) frames, the MES should tune to the NCS. The DTE shows the Data Report Failed and the
contents of the poll received may be printed out or appear on display to remind the operator of sending
the Data Report later.

Moreover, the MES will attempt to send the data report at every interval until the stop command is
received.

Test (1.c) A sequence of bad Signalling Channel Descriptors

Transmit a sequence of Basic Test Frames from the LES TDM channel, each with a good checksum for
the BB and a bad checksum for the SCD, preceded by a sequence with good BBs and good SCDs on
the NCS Common Channel but use the simulator to transmit to the MES on the NCS Common Channel
a Test Group Poll Frame in frame -3. In the N+1th frame reset the SCD checksum to good.

Rxd Frame BB Status SCD Status Packets TDM Source


Frame -5 good BB good SCD NCS
Frame -4 good BB good SCD ,,
Frame -3 good BB good SCD Group Poll ,,

Note: Frame(s) may be lost whilst the receiver re-tunes and synchronises with the LES TDM

Frame -1 good BB bad SCD LES


Frame 0 good BB bad SCD ,,
Frame 1 good BB bad SCD ,,
,, ,, ,, ,,
Frame N-3 good BB bad SCD ,,
Frame N-2 good BB bad SCD ,,
Frame N-1 good BB bad SCD ,,

Recommended Test Procedures (RTPs), Page: 134


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Frame N good BB bad SCD [FAIL] ,,


Frame N+1 good BB good SCD ,,

Expected result: The MES should tune to the LES TDM but not transmit the Data Report. After
N(MaxD) frames, the MES should tune to the NCS. The DTE shows the Data Report Failed and the
contents of the poll received may be printed out or appear on display to remind the operator of sending
the Data Report later.

Moreover, the MES will attempt to send the data report at every interval until the stop command is
received.

Test (1.d) One good Bulletin Board in last three

(i) Repeat Test (b) up to Frame -3, and then continue the following variations for frame -1 to 1:

(ii) Rxd Frame BB Status SCD Status Packets TDM Source


Frame -1 bad BB good SCD LES
Frame 0 bad BB good SCD ,,
Frame 1 good BB good SCD ,,

Expected result: The MES should tune to the LES Signalling Channel and send a Data Report.

(iii) Rxd Frame BB Status SCD Status Packets TDM Source


Frame -1 good BB good SCD LES
Frame 0 bad BB good SCD ,,
Frame 1 bad BB good SCD ,,

Expected result: The MES should tune to the LES Signalling Channel and send a Data Report.

(iv) Rxd Frame BB Status SCD Status Packets TDM Source


Frame -1 bad BB good SCD LES
Frame 0 good BB good SCD ,,
Frame 1 bad BB good SCD ,,

Expected result: The MES should tune to the LES Signalling Channel and send a Data Report.

Test 2 Bulletin Board and SCD Information Tests

Test (2.a) Bulletin Board - 2-Frame Count

(i) Set the 2-Frame Count field to zero and the randomising interval to 1 in the Bulletin Board (ie,
indicating all slots are 3-Frame slots and no frame randomisation) and only slot 1 is available.

(ii) Initiate a Data Report (3 packets) at the DTE keyboard and time the intervals between
successive bursts on the signalling channel

(iii) Set the 2-Frame count field to 14 (first generation) and repeat step (ii).

(iv) Repeat (i), (ii) and (iii) for second generation operation setting the 2-Frame count field in (iii)
to 28.

Expected result: In (ii) the time interval between bursts should always be consistent with 3-Frame
operation (25.92s in both first and second generation modes). In (iii) the time interval should always be
consistent with 2-Frame operation (17.28s in both first and second generation modes).

Recommended Test Procedures (RTPs), Page: 135


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Test (2.b) Bulletin Board Status - Out of Service

(i) Transmit a sequence of modified Basic Test Frames from the NCS and a sequence of Basic
Test Frames from the LES,in which the only change is to set Bit 6 of the Status byte to 0,
meaning out of service.

(ii) Attempt to send a Data Report at the MES.

Expected Result: The MES does not attempt to use the Signalling Channel and a prompt such as "LES
out of service" should be printed out or appear on display.

Test (2.c) Bulletin Board Status - Restoration mode

Set the NCS TDM Channel Type to Standby NCS Common Channel (restoration mode network
operation) and the LES TDM Channel Type to joint Common Channel and LES TDM.

(i) Transmit a Network Update packet from the NCS with the following fields:

Network Version =2

LES Total =1

LES ID = ID of the Simulator LES.

LES Status = 01111000 Binary

LES Services[1] = 10110010 Binary

LES Services[2] =0

LES TDM = TDM of Simulator LES

(ii) Transmit a continuous sequence of good Basic Test Frames from the NCS with the Channel
Type set to Standby NCS Common Channel.

(iii) Transmit a continuous sequence of good Basic Test Frames from the LES with the Channel
Type set to Joint Common and TDM.

(iv) Verify that a prompt is sent to the operator via the DTE requesting the operator to select a
LES.

(v) Select a LES (only one available in this case).

(vi) Attempt to send a Data Report at the MES

Expected result: The attempt is successful.

Test (2.d) Bulletin Board Status - Stand-alone operation

Retune the LES TDM to the NCS Common Channel frequency and indicate that this is NCS Common
TDM.

(i) Transmit a Network Update packet from the NCS with the following fields:

Network Version =3

Recommended Test Procedures (RTPs), Page: 136


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

LES Total =1

LES ID = ID of the Simulator LES.

LES Status = X1111000 Binary

LES Services[1] = 10110010 Binary

LES Services[2] =0

LES TDM = TDM of Simulator NCS Common Channel

(ii) Transmit a continuous sequence of good Basic Test Frames from the NCS with the Channel
Type set to NCS Common Channel.

(iii) Attempt to send a Data Report at the MES.

Expected result: The attempt is successful.

Test (2.e) Signalling Channel Descriptor - Available bit

(i) Transmit a Sequence of modified Basic Test Frames from the LES, in which the only change
is to set the SCD available bit to zero, meaning 'Signalling channel not available for Store and
Forward messaging'.

(ii) Attempt to send a Data Report at the MES.

Expected Result: The attempt is successful.

Test (2.f) Signalling Channel Descriptor - CUG bit

(i) Transmit a Sequence of Basic Test Frames from the NCS and a Sequence of modified Basic
Test Frames from the LES, in which the Signalling Channel available bit is set to 1, the CUG
bit is set to 0 and the maritime distress bit is set to 1.

(ii) Attempt to send a Data Report at the MES.

Expected Result: The MES does not attempt to use the Signalling Channel and a prompt such as
"Signalling Channel not available" should be printed out or appear on display after N frames.

Test 3 Signalling Control Process

Test (3.a) No Free Slots

(i) Transmit a sequence of Basic Test Frames, a Group Poll in frame -3, from the NCS, each with
a good checksum for both the BB and the SCD. Then use the simulator to transmit to the
MES on the LES TDM a sequence of Test Frames, each having a BB with a good checksum, a
SCD with a good checksum, but the SCD showing all slots reserved.

Rxd Frame BB Status SCD Status Packets TDM Source


Frame -5 good BB good SCD NCS
Frame -4 good BB good SCD ,,
Frame -3 good BB good SCD Group Poll ,,

Note: Frame(s) may be lost whilst the receiver re-tunes and synchronises with the LES TDM

Recommended Test Procedures (RTPs), Page: 137


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Frame -1 good BB good SCD LES


Frame 0 good BB good SCD ,,
Frame 1 good BB good SCD ,,
,, ,, ,, ,,
Frame N-3 good BB good SCD ,,
Frame N-2 good BB good SCD ,,
Frame N-1 good BB good SCD ,,
Frame N good BB good SCD [Fail] ,,
Frame N+1 good BB good SCD ,,

Expected result: The MES should tune to the LES TDM but not transmit the Data Report. The process
shall fail after N(MaxE) frames without any free slots, and then the MES should tune back to the NCS.
The DTE shows Anomaly Congestion and the contents of the poll received may be printed out or
appear on display to remind the operator of sending the Data Report later.

Test (3.b) One Packet per Report (success)

(i) Transmit a sequence of 10 Basic Test Frames from the NCS, each with a good checksum for
both BB and SCD. Then use the simulator to transmit to the MES on the NCS Common
Channel a Test Poll Frame. Transmit a sequence of Basic Test Frames from the LES, having
a BB with a good checksum, a SCD with a good checksum and with only one slot free.

Expected result: The MES should tune to the Signalling Channel and transmit the Data Report.

(ii) Transmit a sequence of Basic Test Frames from the LES, with good BBs and good SCDs and
with the chosen multislot showing burst received.

Expected result: The MES should consider the Data Report successfully received.

Test (3.c) One Packet per Report (error)

(i) Transmit a sequence of Basic Test Frames from the NCS, each with a good checksum for both
BB and SCD. Then use the simulator to transmit to the MES on the NCS Common Channel a
Test Poll Frame, having a BB with a good checksum and a SCD with a good checksum.
Transmit a sequence of Basic Test Frames from the LES with good BBs and good SCDs with
all slots free.

Expected result: The MES should tune to the LES and transmit the Data Report in the free slot on the
LES Signalling Channel.

(ii) Transmit a sequence of Basic Test Frames from the LES, with good BBs and good SCDs, in
which the slot burst received bit is zero.

Expected result: The MES should back-off, re-randomise and try to resend the Data Report. The
current channel should show SIG and the MES Status should remain Busy.

Test (3.d) One Packet per Report (bad response)

(i) Use the simulator to transmit to the MES on the LES TDM a sequence of Test Frames and all
slots free.

Rxd Frame BB Status SCD Status Packets TDM Source


Frame -5 good BB good SCD NCS
Frame -4 good BB good SCD ,,

Recommended Test Procedures (RTPs), Page: 138


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Frame -3 good BB good SCD Group Poll ,,

Note: Frame(s) may be lost whilst the receiver re-tunes and synchronises with the LES TDM

Frame -1 good BB good SCD LES


Frame 0 good BB good SCD ,,
Frame 1 good BB good SCD Data Report. ,,
Frame 2 good BB bad SCD ,,
,, ,, ,, ,,

Expected result: The MES should tune to the Signalling Channel and transmit a Data Report.

(ii) Continue transmitting a sequence of Basic Test Frames from the LES, with good BBs but bad
SCDs.

Expected result: The MES should consider the Data Report successfully received.

Test (3.e) Multiple Packets per Report (Ok)

(i) Transmit a sequence of 10 Basic Test Frames from the NCS and the LES, each with a good
checksum for both BB and SCD.

(ii) Use the Operator command to issue an Extended Data Report (3 packets).

Expected result: The MES should tune to the LES TDM and then the Signalling Channel. Transmit the
first packet of the Data Report with the Continuation bit set.

(iii) On receiving the first packet, transmit a sequence of Basic Test Frames from the LES, with
good BBs and good SCDs and the chosen multislot showing burst received and reserved.

Expected result: The MES should send the second packet of the Data Report with the Continuation bit
set.

(iv) On receiving the second packet, transmit a sequence of Basic Test Frames from the LES, with
good BBs and good SCDs and the chosen multislot showing burst received and reserved.

Expected result: The MES should send the last packet of the Data Report.

(v) On receiving the last packet, transmit a sequence of Basic Test Frames from the LES, with
good BBs and good SCDs and the chosen multislot showing burst received and unreserved.

Expected result: The MES should consider the Data Report successfully received.

(vi) Check the Continuation marker in the last Data Report packet.

Expected result: The Continuation marker is set to zero.

Test (3.f) Multiple Packets per Report (bad response associated with packet 1)

(i) Transmit a sequence of 10 Basic Test Frames from the NCS and the LES, each with a good
checksum for both BB and SCD.

(ii) Use the Operator command to issue an Extended Data Report (3 packets).

Recommended Test Procedures (RTPs), Page: 139


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Expected result: The MES should tune to the LES TDM and then the Signalling Channel and transmit
the first packet of the data report with the Continuation bit set.

(iii) Transmit a sequence of Basic Test Frames from the LES, with good BBs and bad SCDs.

Expected result: The MES should back-off, re-randomise and try to resend the first packet of the Data
Report. The current channel should show SIG and the MES Status should remain Busy.

Test (3.g) Multiple Packets per Report (received bit error associated with packet 1)

(i) Transmit a sequence of 10 Basic Test Frames from the NCS and the LES, each with a good
checksum for both BB and SCD.

(ii) Use the Operator command to issue an Extended Data Report (3 packets).

Expected result: The MES should tune to the LES and then the Signalling Channel and transmit the
first packet of the data report with the Continuation bit set.

(iii) Transmit a sequence of Basic Test Frames from the LES, with good BBs and good SCDs and
all slots with both burst received bit and reserved bit set to zero.

Expected result: The MES should back-off, re-randomise and try to resend the first packet of the Data
Report. The current channel should show SIG and the MES Status should remain Busy.

(iv) Repeat the test steps (i) to (iii) except the multislot showing burst not received but reserved in
step (iii).

Expected result: The MES should back-off, re-randomise and try to resend the first packet of the Data
Report. The current channel should show SIG and the MES Status should remain Busy.

Test (3.h) Multiple Packets per Report (reserved bit error associated with packet 1)

(i) Transmit a sequence of 10 Basic Test Frames from the NCS and the LES, each with a good
checksum for both BB and SCD.

(ii) Use the Operator command to issue an Extended Data Report (3 packets).

Expected result: The MES should tune to the LES and then the Signalling Channel and transmit the
first packet of the data report with the Continuation bit set.

(iii) Transmit a sequence of Basic Test Frames from the LES, with good BBs and good SCDs and
chosen multislot showing burst received but not reserved.

Expected result: The MES should back-off, re-randomise and try to resend the first packet of the Data
Report. The current channel should show SIG and the MES Status should remain Busy.

Test (3.i) Multiple Packets per Report (bad response associated with packet 2)

(i) Transmit a sequence of 10 Basic Test Frames from the NCS and the LES, each with a good
checksum for both BB and SCD.

(ii) Use the Operator command to issue an Extended Data Report (3 packets).

Recommended Test Procedures (RTPs), Page: 140


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Expected result: The MES should tune to the LES TDM and then the Signalling Channel and transmit
the first packet of the data report with the Continuation bit set.

(iii) Transmit a sequence of Basic Test Frames from the LES, with good BBs and good SCDs and
the chosen multislot showing burst received and reserved.

Expected result: The MES should transmit the second packet of the Data Report with the Continuation
bit set.

(iv) Transmit a sequence of Basic Test Frames from the LES, with good BBs and bad SCDs.

Expected result: The MES should consider the second packet of the Data Report successfully received
and try to transmit the last packet.

Test (3.j) Multiple Packets per Report (received bit error associated with packet 2)

(i) Transmit a sequence of 10 Basic Test Frames from the NCS and the LES, each with a good
checksum for both BB and SCD.

(ii) Use the Operator command to issue an Extended Data Report (3 packets).

Expected result: The MES should tune to the LES and then the Signalling Channel and transmit the
first packet of the data report with the Continuation bit set.

(iii) Transmit a sequence of Basic Test Frames from the LES, with good BBs and good SCDs and
the chosen multislot showing burst received and reserved.

Expected result: The MES should transmit the second packet of the Data Report with the Continuation
bit set.

(iv) Transmit a sequence of Basic Test Frames from the LES, with good BBs and good SCDs and
the chosen multislot showing burst not received but reserved.

Expected result: The MES should re-transmit the second packet of the Data Report with the
Continuation bit set.

(v) Repeat the test step (iv).

Expected result: The MES should consider the transmission failed after Max F attempts.

(vi) Repeat the test steps (i) to (iv), except the chosen multislot showing burst not received and
unreserved in the step (iv).

Expected result: The MES should consider the transmission failed and a prompt such as "Slot
Reservation Lost" should be printed out or appear on display.

Test (3.k) Multiple Packets per Reports (reserved bit error associated with packet 2)

(i) Transmit a sequence of 10 Basic Test Frames from the NCS and the LES, each with a good
checksum for both BB and SCD.

(ii) Use the Operator command to issue an Extended Data Report (3 packets).

Recommended Test Procedures (RTPs), Page: 141


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Expected result: The MES should tune to the LES and then the Signalling Channel and transmit the
first packet of the data report with the Continuation bit set.

(iii) Transmit a sequence of Basic Test Frames from the LES, with good BBs and good SCDs and
the chosen multislot showing burst received and reserved.

Expected result: The MES should transmit the second Data Report packet with the Continuation bit set.

(iv) On receiving the Signal, transmit a sequence of Basic Test Frames from the LES, with good
BBs and good SCDs and the chosen multislot showing burst received but not reserved.

Expected result: The MES should consider the transmission failed and a prompt such as "Slot
reservation lost" should be printed out or appear on display.

Test (3.l) Multiple Packets per Report (bad response associated with the last packet)

(i) Transmit a sequence of 10 Basic Test Frames from the NCS and the LES, each with a good
checksum for both BB and SCD.

(ii) Use the Operator command to issue an Extended Data Report (3 packets).

Expected result: The MES should tune to the LES TDM and then the Signalling Channel and transmit
the first packet of the data report with the Continuation bit set.

(iii) Transmit a sequence of Basic Test Frames from the LES, with good BBs and good SCDs and
the chosen multislot showing burst received and reserved.

Expected result: The MES should transmit the second packet of the Data Report with the Continuation
bit set.

(iv) Transmit a sequence of Basic Test Frames from the LES, with good BBs and good SCDs and
the chosen multislot showing burst received and reserved.

Expected result: The MES should transmit the last packet of the Data Report without the Continuation
bit set.

(v) Transmit a sequence of Basic Test Frames from the LES, with good BBs and bad SCDs.

Expected result: The MES should consider the last packet of the Data Report successfully received.

Test (3.m) Multiple Packets per Report (received bit error associated with the last packet)

(i) Repeat the test steps (i) to (iv) in Test (3.l).

Expected result: The MES should transmit the last packet of the Data Report without the Continuation
bit set.

(ii) Transmit a sequence of Basic Test Frames from the LES, with good BBs and good SCDs and
the chosen multislot showing burst not received but reserved.

Expected result: The MES should re-transmit the last packet of the Data Report.

(iii) Repeat the test step (ii).

Expected result: The MES should consider the transmission failed after Max F attempts.

Recommended Test Procedures (RTPs), Page: 142


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(iv) Repeat the test steps (i) and (ii), except the chosen multislot showing burst not received and
unreserved in the step (ii).

Expected result: The MES should consider the transmission failed and a prompt such as "Slot
Reservation Lost" should be printed out or appear on display.

Test (3.n) Multiple Packets per Reports (reserved bit error associated with the last packet)

(i) Repeat the test step (i) in Test (3.m).

Expected result: The MES should transmit the last packet of the Data Report without the Continuation
bit set.

(ii) On receiving the packet, transmit a sequence of Basic Test Frames from the LES, with good
BBs and good SCDs and the chosen multislot showing burst received and reserved.

Expected result: The MES should consider the transmission succeeded and not attempt to resend the
last packet.

Test 4 LES in Demand Assigned Mode

(i) Transmit a sequence of Basic Test Frames from the NCS, each with a good checksum for both
the BB and the SCD. The LES is operating in permanent mode.

(ii) Send a poll to initiate the unreserved data reporting and make the first data report successful.

(iii) Before sending the second data report, transmit the Network Update which shows the LES
operating in demand assigned mode.

Rxd Frame BB Status SCD Status Packets TDM Source


Frame 95 good BB good SCD NCS
Frame 96 good BB good SCD ,,
Frame 97 good BB good SCD Network Update ,,
Frame 98 good BB good SCD ,,
Frame 99 good BB good SCD ,,
Frame 100 good BB good SCD ,,

Expected result: The MES should terminate sending the subsequent data reports until the LES is back
in the permanent mode.

(iv) Initiate a data report by the MES operator command.

Expected result: The MES should tune to the NCS signalling channel, in which the CUG bit is set to 1,
and then send a data report.

(v) Repeat the test step (iv), except that the CUG bit of the NCS signalling channel is set to zero.

Expected result: The MES should not attempt to use the signalling channel and consider the data report
failed after MaxD frames.

(vi) Send another poll to initiate the unreserved data report on the NCS TDM channel, and the
LES TDM is set to FFFF.

Expected result: The MES should tune to the NCS signalling channel and send the data reports.

Recommended Test Procedures (RTPs), Page: 143


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Test 5 LES in Restoration Mode

(i) Send a poll to initiate the unreserved data reporting and make the first data report successful.

(ii) Change the configuration of the LES into Restoration mode and tune the MES to the LES.

Expected result: The MES should terminate sending the subsequent data reports until both NCS and
LES are back to normal status.

Test 6 MES Out of Ocean Region

(i) Send a Poll to initiate unreserved data reporting.

(ii) Initiate a Logout Request after the first data report is completed.

Expected result: The MES should not send data reports any more after receiving the Logout ACK.

(iv) Initiate a Login Request.

Expected result: The MES may resume the unreserved data reporting after receiving the Login ACK.

Test 7 Random Access

Test Bulletin Board Setup

Network Version =2

Frame Number =-10 for the first

= Last frame number + 1 for the rest:

Signalling Channels =2

Two-frame Count =0

Empty Frame =0

Spare =0

Channel Type = 1 for NCS CC (or 2 for LES TDM)

Local ID =0

Spare =0

Origin ID = 1,44 (hex 6C) for NCS

(or LES Simulator Id for LES)

Status = 11110000 binary for NCS

(or 11111000 Binary for LES)

Services(byte one) = 10100010 binary for NCS

(or 10110010 Binary for LES)

Recommended Test Procedures (RTPs), Page: 144


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Services(byte two) =0

Randomising = 10

Signalling Channel Descriptor 1

Available = 1 (Available for Store and Forward Message)

CUG = 1 (Available for Closed User Group use)

(this bit is set to 0 in the test step (iii) below)

Distress = 1 (Available for Distress traffic)

Slotted = 1 (Slotted Aloha)

Spare =0

Sat. Freq. code = As required for the simulator (NCS/LES)

Slot State Markers = only slots 27 and 28 available

(only slot 28 is available in the test step (iii) below)

Signalling Channel Descriptor 2

Available = 0 (Not available for Store and Forward Message)

CUG = 1 (Available for Closed User Group use)

Distress = 0 (Not available for Distress traffic)

Slotted = 1 (Slotted Aloha)

Spare =0

Sat. Freq. code = As required for the simulator (NCS/LES)

Slot State Markers = only slots 24,25 and 26 available

(only slot 28 is available in the test step (iii) below)

Pre-programmed Unreserved Data Reporting Setup:

DNID =4

LES ID = 111

LES TDM = TDM of the LES Simulator.

Sub-address =0

Randomising Interval =0

Start Frame =1

Interval = 10 Frames, if possible;

Recommended Test Procedures (RTPs), Page: 145


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

= 30 Frames, if possible, in the test step (iii) below

Group Poll Packet (Initiate Unreserved Data Reporting)

DNID =4

LES ID = 111

LES TDM = TDM of the LES Simulator.

Sub-address =0

Randomising Interval = 1 (20 in the test step (iii) below)

Response = 01

Command =5

Sequence No. =2

(i) Transmit a sequence of Basic Test Frame from the LES, each with good BBs and good SCDs,
proceeded by a sequence of Basic Test Frames from the NCS TDM channel but use the
simulator to transmit to the MES a Group Poll in frame -3

Rxd Frame BB Status SCD Status Packets TDM Source


Frame -5 good BB good SCD NCS
Frame -4 good BB good SCD ,,
Frame -3 good BB good SCD Group Poll ,,

Note: Frame(s) may be lost whilst the receiver re-tunes and synchronises with the LES TDM

Frame -1 good BB good SCD LES


Frame 0 good BB good SCD ,, Frame
1 good BB good SCD ,,
,, ,, ,, ,,

Expected result: The MES should tune to the LES TDM and transmit the Data Report (one packet) in
frame 1.

(ii) Record the slot number in which the data report is received until 500 reports are obtained.
Then calculate the Xe: (i=24 through 28):

Nei = (no. of bursts transmitted in slot i);

(Nei-100)2
Kei = 100 ;

28
Xe = Xei
i=24

Expected result: Xe < [2.2]

(iii) Change the Setup as defined above and repeat the test step (i).

Recommended Test Procedures (RTPs), Page: 146


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Expected result: The MES should choose a frame at random within frame 1 through 20 and tune to the
LES at least 3 frames prior to transmitting the signal, and then transmit the data report in slot 28 on
Signalling Channel 2 in the chosen frame. The MES would send the second data report within frame
31 through 50 and so on.

(iv) Record the frame number (mod 30,ie, Frame No.-{[Frame No./30] integer x30}, in which the
data report is received until 500 reports are obtained. Then calculate the Xf: (i= 1 through
20):

Nfi= (no. of bursts transmitted in frame i);

(Nfi-25)2
Kfi= 25 ;

20
Xf = Kfi
i=1

Expected result: Xf < [15.3]

Recommended Test Procedures (RTPs), Page: 147


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

PART 2 POLLING

Test 1 Treatment of Packet Priorities

(i) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then use the
simulator to transmit to the MES on the NCS Common Channel a Group Poll and an
Announcement in frame 1.

Rxd Frame Packets TDM Source


Frame -1 NCS
Frame 0 ,,
Frame 1 Group Poll Announcement ,,

Expected result: The MES should handle the Announcement and may save the group poll. After the
call is completed, the MES could start handling the poll.

(ii) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then use the
simulator to transmit to the MES on the NCS Common Channel a Test Group Poll and an
EGC message with routine priority in frame 1.

Rxd Frame Packets TDM Source


Frame -1 NCS
Frame 0 ,,
Frame 1 Group Poll EGC Message ,,

Expected result: The MES should handle the EGC message and may save the Group Poll. After the
EGC message is completed, the MES could start handling the poll.

(iii) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then use the
simulator to transmit to the MES on the NCS Common Channel a Group Poll and an
Individual Poll in frame 1.

Rxd Frame Packets TDM Source


Frame -1 NCS
Frame 0 ,,
Frame 1 Group Poll Individual Poll ,,

Expected result: The MES should handle the Group Poll and may save the Individual Poll, based on the
first-come-first-served system.

(iv) Transmit a sequence of Basic Test Frames from the NCS TDM channel and a poll to initiate a
pre-assigned data reporting with the Start Frame set to 50 and Interval set to 100. Then send
an Announcement in frame 40.

Rxd Frame Packets TDM Source


Frame 38 NCS
Frame 39 ,,
Frame 40 Announcement ,,

Expected result: The MES should handle the Announcement and complete the To-Mobile message
transfer, and then send the pre-assigned data reports at subsequent intervals.

(v) Send an Assignment Request, At the MES, in frame 240.

Recommended Test Procedures (RTPs), Page: 148


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Expected result: The MES should handle the Assignment Request and complete the From-Mobile
message transfer and then send the pre-assigned data reports at subsequent intervals.

(vi) For SES only: Send an Assignment Request with distress priority in frame 450.

Expected result: The MES shall handle the request and complete the call, and then send the pre-
assigned data reports at subsequent intervals.

(vii) For SES or LMES only: Send a distress or land mobile alert, as appropriate, in frame 550.

Expected result: The MES shall stop data reporting and initiate the alert. After the alert is completed,
resume sending the pre-assigned data reports at subsequent intervals.

(viii) Send a long EGC message in frame 740.

Rxd Frame Packets TDM Source


Frame 738 NCS
Frame 739 ,,
Frame 740 EGC ,,
,, EGC ,,
Frame 749 EGC ,,
Frame 750 EGC ,,
Frame 751 EGC ,,
Frame 752 EGC ,,

Expected result: The MES should continue handling the EGC message until it is completed. Then
send the pre-assigned data reports at subsequent intervals.

(ix) Transmit a sequence of Basic Test Frames from the NCS TDM channel and a poll to initiate
an unreserved data reporting with the Start Frame set to 50, Randomising Interval set to 50
and Interval set to 100. Then send an Announcement in frame 55 ,assuming the terminal has
not tuned to the LES.

Rxd Frame Packets TDM Source


Frame 53 NCS
Frame 54 ,,
Frame 55 Announcement ,,

Expected result: The MES should handle the Announcement and complete the To-Mobile message
transfer, and then send the unreserved data reports at subsequent intervals.

(x) Send an Assignment Request, At the MES, in frame 260,assuming the terminal has not tuned
to the LES.

Expected result: The MES should handle the Assignment Request and complete the From-Mobile
message transfer, and then send the unreserved data reports at subsequent intervals.

(xi) For SES or LMES only: Send a distress or land mobile alert, as appropriate, in frame 560,
assuming the terminal has not tuned to the LES.

Expected result: The MES shall stop randomising process and initiate the alert. After the alert is
completed, resume sending the unreserved data reports at subsequent intervals.

(xii) Send an EGC message, as appropriate, in frame 760, assuming the terminal has not tuned to
the LES.

Recommended Test Procedures (RTPs), Page: 149


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Expected result: The MES should handle the EGC message until it is completed. Then send the
unreserved data reports at subsequent intervals.

Test 2 Information in a Poll Packet

For this test another Test Frame is defined:

[Test Poll Frame ] ::= [BB][SCD][Poll Pkt]

with the following field settings:

Bulletin Board same as for the Basic Test Frame, except that the Empty Frame field is set to 1;

SCD same as for the Basic Test Frame;

Individual Poll Packet (Download DNID)

MES ID = ID of the MES under test.

LES ID = ID of the LES Simulator.

Sub-address =0

DNID = 23456

Response = 00

Command = 0A

Sequence No. =1

Member Number = 222

(i) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
Individual Poll to the MES.

(ii) Use the operator enquiry to verify that the DCE has correctly decoded the Polling Packet,

Expected Result: The DNID, LES ID, and Member Number have been stored in non-volatile memory.
The DTE shows the Download Command succeeded.

(iii) Turn off the MES for 24 hours, and then check the parameters again.

Expected Result: The parameters in the MES non-volatile memory shall be retained.

Test 3 Treatment of Wrong ID

(i) Repeat the test steps (i) and (ii) in Test 2, except that the MES ID in the Poll packet is
incorrect, the Sequence Number is set to 2 and Member Number is set to 234 in the individual
poll.

Expected Result: The MES should ignore such a poll. The DNID, LES ID and Member Number should
not be stored.

Recommended Test Procedures (RTPs), Page: 150


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(ii) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
MES the Test Group Poll, with the following settings:

DNID = 4321

LES ID = ID of the LES Simulator.

LES TDM = TDM of the LES Simulator

Sub-address =0

Randomising Interval = 00

Response = 00

Command = 09

Sequence No. =3

Free field [text] = 280 bytes data

Expected Result: The MES should ignore such a data transmission poll.

(iii) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
MES the Test Group Poll, with the following settings:

DNID = 23456

LES ID = Different from the previous ID stored in memory

LES TDM = TDM of the LES Simulator

Sub-address =0

Randomising Interval = 00

Response = 00

Command = 89

Sequence No. =1

Free field [text] = 280 bytes data

Expected Result: The MES should ignore such a data transmission poll and not send back an ACK.

(iv) This test is only possible for the MES which has both EGC receiving and Data Reporting
functions

Send the MES a Group Call EGC message, in which the Group ID is 23456.

Expected Result: The MES should ignore such an EGC message.

(v) This test is only possible for the MES which has both EGC receiving and Data Reporting
functions

Recommended Test Procedures (RTPs), Page: 151


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Download the EGC Group ID 4567 to the MES, and then transmit a "Data Transmission"
Group Poll, in which the DNID is 4567 , "Command" is set to 09 and 280 bytes data is in text
field.

Expected Result: The MES should not receive such data.

Test 4 Treatment of Poll Packets with the same Sequence No.

(i) Set up an Individual Poll Packet (download DNID)

MES ID = ID of the MES under test.

LES ID = 112

Sub-address =0

DNID =4

Response = 00

Command = 8A

Sequence No. =7

Member Number = 222

(ii) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
Download Individual Poll to the MES.

Expected Result: After receiving this poll, the MES should store the relevant parameters, tune to the
LES Signalling Channel and send the ACK.

(iii) Transmit a sequence of Basic Test Frames from the LES, in which the chosen multislot burst
received bit is set.

Expected result: The MES should consider the transmission of the ACK succeeded.

(iv) Repeat the test steps (i) and (ii) 5 times. ( the Sequence No. remaining 7, but the Member
Number set to 223).

Expected Result: After receiving each poll, the MES should tune to the LES Signalling Channel and
send the ACK. But should not take any action to update the parameters stored before, ie the Member
Number remains 222.

(v) Repeat the test steps (i) and (ii), but set the Sequence No. to 8, Member Number to 223.

Expected Result: After receiving the poll, the MES should tune to the LES Signalling Channel and
send the ACK. And the old parameters stored in DCE should be updated.

(vi) Send the following poll to the MES under test

MES ID = ID of the MES under test.

LES ID = 113

Recommended Test Procedures (RTPs), Page: 152


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Sub-address =0

DNID =4

Response = 00

Command = 8A

Sequence No. =7

Member Number = 223

Expected Result: After receiving the above poll, the MES should store the relevant parameters, tune to
the LES Signalling Channel and send the ACK.

(vii) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
MES the Test Group Poll, with the following settings:

DNID =4

LES ID = 113

LES TDM = TDM of the LES Simulator

Sub-address =0

Randomising Interval = 02

Response = 00

Command = 89

Sequence No. =1

Free field [text] = 280 bytes data

Expected Result: The MES should receive such a data transmission poll and send back an ACK.

(viii) Transmit a sequence of Basic Test Frames from the LES, in which the chosen multislot burst
received bit is zero.

Expected result: The MES should back-off, re-randomise and try to resend the ACK. The current
channel should show SIG and the MES Status should remain Busy.

(ix) Repeat the test step (viii).

Expected result: The MES should consider the transmission of the ACK failed after MaxC retries.
However, the poll should be accepted and the data should be routed to the DTE.

(x) Repeat the test step (vii), Sequence No. remaining 1.

Expected Result: The MES should send an ACK to the LES. However, the data should not be received.

(xi) Transmit a sequence of Basic Test Frames from the LES, in which the chosen multislot burst
received bit is set.

Recommended Test Procedures (RTPs), Page: 153


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Expected result: The MES should consider the transmission of the ACK succeeded.

(xii) Repeat the test step (vii), Sequence No. remaining 1.

Expected result: The MES should ignore this poll and not send the ACK to the LES.

(xiii) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
MES the Test Group Poll, with the following settings:

DNID =4

LES ID = 112

LES TDM = TDM of the LES Simulator

Sub-address =0

Randomising Interval = 02

Response = 00

Command = 89

Sequence No. =1

Free field [text] = 280 bytes data

Expected Result: The MES should receive such a data transmission poll and send back an ACK.

Test 5 Individual Polling

Test (5.a) Download DNID with ACK Bit Set

(i) Set up an Individual Poll Packet (Download DNID)

MES ID = ID of the MES under test.

LES ID = ID of the LES Simulator.

Sub-address =0

DNID = 3333

Response = 00

Command = 8A H

Sequence No. =1

Member Number = 44

Text = 280 bytes

(ii) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
Download Individual Poll to the MES.

Recommended Test Procedures (RTPs), Page: 154


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Expected Result: After receiving this poll, the MES should tune to the LES Signalling Channel and
send the ACK as follows:

DNID = 3333

LES ID = ID of the LES Simulator.

Member Number = 44

Category and sub-Category = 80 H

Command = 8A H

Sequence No. =1

(iii) Use the operator enquiry to verify that the DCE has correctly decoded the Polling Packet,

Expected Result: The DNID, LES ID, Member Number and the first 25 characters(IA5) in text field
have been stored in non-volatile memory. The DTE shows the Download Command succeeded.

(iv) Repeat the test steps (i) and (ii) with different DNIDs and Sequence Numbers until the storage
is full.

Expected Result: All data and DNIDs have been stored in non-volatile memory. Record the number of
DNIDs downloaded to fill the memory

(v) Download the new DNID to the MES.

Expected Result: The MES should not accept this new DNID. However,the ACK should be sent out.
Prompt such as " New Downloading DNID Poll has been rejected because the memory is full." may
be printed out or appear on display.

(vi) Use the operator command to inhibit one DNID previously downloaded.

(vii) Repeat the test step (v).

Expected Result: The new DNID, LES ID and Member Number should be accepted and stored in
non-volatile memory. The DNID inhibited should be overwritten.

(viii) Delete a few DNID/LES ID pairs and get enough memory space for the following tests.

Test (5.b) Program Reserved Data Reporting

(i) Set up an Individual Poll Packet

MES ID = ID of the MES under test.

LES ID = ID of the LES Simulator.

Sub-address =0

DNID = 9999

Response = 00

Command = 01

Recommended Test Procedures (RTPs), Page: 155


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Sequence No. =2

Member Number = 88

Logical Channel No. =1

Start Frame = 50

Packets per Report =4

Slot No. =2

Interval = 100 frames

Duration =4

(ii) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
above Individual Poll to the MES.

(iii) Use the operator enquiry to verify that the DCE has correctly decoded the Polling Packet,

Expected Result: The DNID, LES ID, Member Number, Start Frame Number,Slot Number, LCN
Number, Number of Packets per Report, Interval and Duration have been stored in non-volatile
memory.

(iv) Repeat the test steps (i) and (ii) except that the MES ID is incorrect and the Sequence No. is
set to 3.

Expected Result: The MES should ignore the poll.

(v) Set up an Individual Poll Packet (Download DNID)

MES ID = ID of the MES under test.

LES ID = ID of the LES Simulator.

Sub-address =0

DNID = 9999

Response = 00

Command = 8A H

Sequence No. =3

Member Number = 99

Text = 280 bytes

(vi) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
Download Individual Poll to the MES.

Expected Result: After receiving this poll, the MES should tune to the LES Signalling Channel and
send the ACK as follows:

Recommended Test Procedures (RTPs), Page: 156


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

DNID = 9999

LES ID = ID of the LES Simulator.

Member Number = 99

Category and sub-Category = 80 H

Command = 8A H

Sequence No. =3

Expected Result: The previously downloaded parameters should be updated with new member number
and new text. However, all programming related to the previously downloaded DNID/LES ID pair
should remain unchanged.

Test (5.c) Initiate Reserved Data Reporting (optional)

(i) Set up an Individual Poll Packet

MES ID = ID of the MES under test.

LES ID = ID of the LES Simulator.

Sub-address =0

DNID = 9999

Response = 01

Command = 02

Sequence No. =1

MES Signalling Channel = the number given by the LES Simulator

(ii) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
above Individual Poll to the MES.

Expected result: The MES should tune to the required LES TDM, the required Signalling Channel, and
then transmit a data report in slot 2 of Frame 50.

Test (5.d) Program Unreserved Data Reporting (optional)

(i) Set up an Individual Poll Packet

MES ID = ID of the MES under test.

LES ID = ID of the LES Simulator.

Sub-address =0

DNID = 3333

Response = 00

Recommended Test Procedures (RTPs), Page: 157


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Command = 04

Sequence No. =2

Start Frame [text] = 50

Interval [text] = 100

(ii) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
above Individual Poll to the MES.

Expected result: The Start Frame Number and Interval should be stored with the DNID/LES ID pair.

Test (5.e) Initiate Unreserved Data Reporting (optional)

(i) Set up an Individual Poll Packet

MES ID = ID of the MES under test.

LES ID = ID of the LES Simulator.

Sub-address =0

DNID = 3333

Response = 01

Command = 05

Sequence No. =3

(ii) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
above Individual Poll to the MES.

Expected result: The MES should tune to the LES TDM and then the signalling channel, using the
Randomising Interval given in the BB, to transmit data reports.

Test (5.f) Delete DNID

(i) Set up an Individual Poll Packet

MES ID = ID of the MES under test.

LES ID = Different ID from previous one

Sub-address =0

DNID = 3333

Response = 00

Command = 8B

Sequence No. =4

Recommended Test Procedures (RTPs), Page: 158


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(ii) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
above Individual Poll to the MES.

Expected Result: The MES should not handle the poll because the LES ID is not expected. However,
the ACK should be sent back.

(iii) Repeat the test steps (i) and (ii) except that the LES ID is correct but the MES ID is incorrect,
Sequence No. is set to 1.

Expected Result: The MES should ignore the poll.

(iv) Repeat the test steps (i) and (ii) except that the LES ID is correct but DNID is set to 5555,
Sequence No. is set to 2.

Expected Result: The MES should not handle the poll, but sent an ACK.

(v) Repeat the test steps (i) and (ii) and make the LES ID correct.

Expected Result: After receiving this poll, the MES should tune to the LES Signalling Channel and
send the ACK as follows:

DNID = 3333

LES ID = ID of the LES Simulator

Member Number = 44

Category and sub-Category = 80 H

Command = 8B H

Sequence No. =4

Expected Result: The data has been erased from non-volatile memory.

(vi) Repeat the test steps (i) and (ii) in test (5.a).

Expected Result: The DNID, LES ID and Member Number have been stored in non-volatile memory.

Test (5.g) Send Unreserved Report as required in [Response] Field

(i) Set up an Individual Poll Packet:

MES ID = ID of the MES under test.

LES ID = ID of the LES Simulator.

Sub-address =0

DNID = 3333

Response = 01

Command = 00

Sequence No. =3

Recommended Test Procedures (RTPs), Page: 159


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(ii) Prepare a data report at the MES, routed to DNID 3333.

(iii) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
above Individual Poll to the MES.

Expected Result: After receiving this poll, the MES should tune to the LES Signalling Channel and
send the data report.

(iv) On receiving the packet, transmit a sequence of Basic Test Frames from the LES, with good
BBs and good SCDs and the chosen multislot showing burst received.

Expected result: The MES should consider the Data Report successfully received.

(v) Repeat steps (i) to (iii) but set the response to 10 B and prepare a message at the
MES.

Expected result: The MES should send the message after the poll is received.

Test 6 Group Polling

Test (6.a) Program Unreserved Data Reporting

(i) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
Download Individual Poll with the setting below:

DNID = 7777

LES ID = ID of the LES Simulator.

Sub-Address =1

Member Number = 99

Expected Result: The DNID, LES ID and Member Number have been stored in non-volatile memory.
The DTE shows the Download Command succeeded.

(ii) Set up a Group Poll Packet:

DNID = 7777

LES ID = ID of the LES Simulator.

LES TDM = 10000

Sub-address =1

Randomising Interval =1

Response = 00

Command = 84

Sequence No. =5

Start Frame = 50

Interval = 100 frames

Recommended Test Procedures (RTPs), Page: 160


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

User Data = 280 bytes

(iii) Use the operator command to inhibit the DNID 7777, and then transmit a sequence of Basic
Test Frames from the NCS TDM channel and send the above Group Poll to the MES.

Expected result: The MES should ignore this poll and not send an ACK.

(iv) Use the operator command to activate the DNID 7777, and then transmit a sequence of Basic
Test Frames from the NCS TDM channel and send the above Group Poll to the MES.

Expected Result: The MES should accept this poll and use random access, randomising interval 1, to
send the ACK as follows:

DNID = 7777

LES ID = ID of the LES Simulator

Member Number = 99

Category and sub-Category = 80 H

Command = 84 H

Sequence No. =5

Test (6.b) Initiate Unreserved Data Reporting

(i) Set up a Group Poll Packet:

DNID = 7777

LES ID = ID of the LES Simulator.

LES TDM = 12000

Sub-address =1

Randomising Interval = 20

Response = 01

Command = 86

Sequence No. =6

(ii) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
above Group Poll to the MES.

Expected result: The MES should ignore the poll, but send an ACK using the randomsing interval 20
on the relevant signalling channel.

(iii) Repeat step (ii) except that Command is changed to 05 and Sequence No. is changed to 5.

Expected result: The MES should tune to the LES TDM 12000 and then the Signalling Channel,
transmit a data report with random access, the frame in which the first data report is received should be
within Frame 50 through 69.

Recommended Test Procedures (RTPs), Page: 161


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Test (6.c) Stop Unreserved Data Reporting

(i) Set up a Group Poll Packet:

DNID = 7777

LES ID = ID of the LES Simulator.

LES TDM = TDM of the LES Simulator.

Sub-address =2

Randomising Interval = 00

Response = 00

Command = 06

Sequence No. =7

(ii) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
above Group Poll to the MES before Frame 150.

Expected result: The MES should continue sending data reports.

(iii) Repeat the test steps (i) and (ii) except that Sub-address is set to 1 and Sequence No. is
changed.

Expected result: After receiving the poll, the MES should not attempt to send the data reports any more
from Sub-address 1.

(iv) Repeat the step (iii) in the test (6.b).

Expected result: The MES should tune to the LES TDM 12000 and then the Signalling Channel,
transmit a data report with random access, the frame in which the first data report is received should be
within Frame 50 through 69.

(v) Repeat the test steps (i) and (ii) except that the DNID is set to 0 and the LES ID is changed in
the Group Poll.

Expected result: The MES should ignore the poll and continue sending the data reports.

(vi) Repeat the test steps (i) and (ii) except that the DNID is set to 0.

Expected result: After receiving the poll, the MES should terminate sending data reports.

(vii) Repeat the step (iii) in the test (6.b).

(viii) Repeat the test steps (i) and (ii) except that Randomsing interval set to 1, Command set to 83,
Sub-address set to 0 and Sequence No. changed.

Expected result: The MES should ignore the poll, but send an ACK on the signalling channel.

(ix) Repeat the test steps (i) and (ii) except that Sub-address is set to zero.

Expected result: After receiving the poll, the MES should not attempt to send the data reports any more

Recommended Test Procedures (RTPs), Page: 162


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Test (6.d) Initiate Reserved Data Reporting

(i) Pre-programmed set up is as follows:

LES ID = ID of the LES Simulator.

Sub-address =0

DNID = 9999

Member Number = 88

Logical Channel No. =1

Start Frame = 50

Packets per Report =4

Slot No. =2

Interval = 100 frames

Duration =4

(ii) Set up a Group Poll Packet:

DNID = 9999

LES ID = ID of the LES Simulator.

LES TDM = TDM of the LES Simulator.

Sub-address =0

Randomising Interval = 00

Response = 01

Command = 02

Sequence No. =8

Signalling Channel No. = the number given by the LES Simulator

(iii) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
above Group Poll to the MES.

Expected result: The MES should tune to the required LES TDM, the required Signalling Channel, and
then transmit a data report in slot 2 of Frame 50.

(iv) Turn off the MES for a period of 150 frames, and then turn it on.

Expected result: all data related to the reserved data report shall remain in non-volatile memory and the
MES should continue transmitting the data report in the slot 2 of Frame 250. Moreover, the MES shall
not attempt to send any data reports after the 4th data report has been transmitted in frame 350.

Recommended Test Procedures (RTPs), Page: 163


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Test (6.e) Stop Reserved Data Reporting

(i) Set up a Group Poll Packet:

DNID = 9999

LES ID = ID of the LES Simulator.

LES TDM = TDM of the LES Simulator.

Sub-address =1

Randomising Interval = 00

Response = 00

Command = 03

Sequence No. =9

LCN =1

(ii) Repeat the test step (iii) in test (6.d). After the first data report is completed, send the above Group Poll to
the MES.

Expected result: The MES should ignore this poll and continue sending the data report.

(iii) Change Sub-address to 0 and Sequence No. to 8 in the above poll, and then send it to the
MES before the last pre-assigned data report is transmitted.

Expected result: After receiving the poll, the MES should not attempt to send the data reports any
more. However, the DNID, LES ID, Member Number, Start Frame, Slot Number, LCN Number,
Number of Packets per Report, Duration and Interval will remain in non-volatile memory.

(iv) Repeat the test step (iii) in test (6.d) to initiate pre-assigned data reporting again.

(v) Set up a Group Poll Packet:

DNID =0

LES ID = Different ID from the previous one

LES TDM = TDM of the LES Simulator.

Sub-address =0

Randomising Interval = 00

Response = 00

Command = 03

Sequence No. =8

LCN =1

Recommended Test Procedures (RTPs), Page: 164


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(vi) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
above Group Poll to the MES.

Expected result: The MES should ignore the poll and continue sending the data report.

(vii) Change the LES ID back to the ID of the LES Simulator, Sub-address to 5 and LCN to 6 in
the above poll and send it to the MES before the last pre-assigned data report is transmitted.

Expected result: After receiving the poll, the MES should not attempt to send the data reports any
more. However, the DNID, LES ID, Member Number, Start Frame, Slot Number, LCN Number,
Number of Packets per Report, Duration and Interval will remain in non-volatile memory.

Test (6.f) Delete DNID

This test will be done after the area polling test if the MES supports Area Polling Service.

(i) Set up a Poll Packet

DNID = 9999

LES ID = ID of the LES Simulator.

LES TDM = TDM of the LES Simulator.

Sub-address =0

Randomising Interval = 20

Response = 00

Command = 8B

Sequence No. = 10

(ii) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
MES the above Poll except that the LES ID is changed.

Expected Result: The MES should ignore the poll.

(iii) Repeat step (ii) without modifying the above poll.

Expected Result: After receiving this poll, the MES should send an ACK using the randomising
interval (20) given in the poll, and all data related to DNID 9999 should be erased from non-volatile
memory.

Test 7 Area Polling

Test (7.a) All Group Members (Initiate a message transfer)

(i) Set up the MES position and EGC area address:

NAVAREA =9

Position = 34o44'00" N, 135o21'00" E

(ii) Prepare a 8k From-Mobile message and allocate it to DNID 3333.

Recommended Test Procedures (RTPs), Page: 165


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(iii) Set up a Area Poll Packet

DNID = 3333

LES ID = ID of the LES Simulator.

LES TDM = TDM of the LES Simulator.

Sub-address =0

Randomising Interval = 40

Response = 10

Area Type =0

Area Length =0

Command = 00

Sequence No. = 11

(iv) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
above Area Poll to the MES.

Expected result: The MES should tune to the required LES TDM, and then transmit a assignment
request, using the randomising interval given in the poll, on a Signalling Channel to the LES. The
From-Mobile message transfer will succeed.

(v) Repeat the test steps (iii) and (iv) except that the DNID is set to 12345 instead of 3333 and the
Sequence No. is changed in the Area Poll packet.

Expected result: The MES should ignore this Area Poll.

Test (7.b) NAVAREA Area (Initiate Unreserved Data Reporting)

(i) Set up a Area Poll Packet

DNID = 7777

LES ID = ID of the LES Simulator.

LES TDM = TDM of the LES Simulator.

Sub-address =0

Randomising Interval =3

Response = 01

Area Type =1

Area Length =1

Area =8

Recommended Test Procedures (RTPs), Page: 166


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Command = 05

Sequence No. = 12

(ii) Transmit a sequence of Basic Test Frames from the NCS TDM channel and send the MES the
poll which programmes unreserved data reports. Then, send the above Area Poll to the MES.

Expected result: The MES should ignore this Area Poll.

(iii) Repeat the test steps (i) and (ii) except that the DNID is set to 12345, the Navarea address is
set to 9 and Sequence No. is changed in the Area Poll packet.

Expected result: The MES should ignore this Area Poll.

(iv) Repeat the test steps (i) and (ii) except that the Navarea address is set to 9 in the area poll
packet.

Expected result: The MES should tune to the required LES TDM, and then use the randomising
interval (3) given in the poll to transmit a Data Report on the signalling channel which has CUG bit set
to 1.

Test (7.c) Rectangular Area (Stop Unreserved Data Reporting)

(i) Set up a Area Poll Packet

DNID = 7777

LES ID = ID of the LES Simulator.

LES TDM = TDM of the LES Simulator.

Sub-address =0

Randomising Interval =0

Response = 00

Area Type =3

Area Length =4

Area = 250S, 1340E, 500 to the North, 20 to the East.

Command = 06

Sequence No. = 13

(ii) Transmit a sequence of Basic Test Frames from the NCS TDM channel and send the above
poll to the MES.

Expected result: The MES should ignore this area poll.

(iii) Repeat the test steps (i) and (ii) except that the DNID is set to 12345, "50o to the North" is
replaced with "70o to the North" and Sequence No. is changed in the area poll packet.

Recommended Test Procedures (RTPs), Page: 167


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Expected result: The MES should ignore this area poll.

(iv) Repeat the test steps (i) and (ii) except that the Sub-address is set to 3, "50o to the North" is
replaced with "70o to the North" and Sequence No. is changed in the area poll packet.

Expected result: The MES should not take action to stop the unreserved data reporting.

(v) Repeat the test steps (i) and (ii) except that "50o to the North" is replaced with "70o to the
North" in the area poll packet.

Expected result: The MES should stop sending the data reports.

Test (7.d) Circular Area (Data Transmission)

(i) Set up an Area Poll Packet

DNID = 7777

LES ID = ID of the LES Simulator.

LES TDM = TDM of the LES Simulator.

Sub-address =0

Randomising Interval = 40

Response = 00

Area Type =4

Area Length =4

Area = 330N,1340E, Radius 300

Command = 89

Sequence No. = 14

Binary Data = 280 bytes

(ii) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
above Area Poll to the MES.

Expected Result: The MES should correctly decode the data and use random access, randomising
interval 40, to send the ACK as follows:

DNID = 7777

LES ID = ID of the LES Simulator.

Member Number = 99

Category and sub-Category = 80 H

Command = 89 H

Recommended Test Procedures (RTPs), Page: 168


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Sequence No. = 14

(iii) Repeat the test steps (i) and (ii) except that the Circular Area is set to 300S,1340E, Radius
300 and the Sequence No. is changed in the area poll packet.

Expected result: The MES should ignore this area poll.

(iv) Repeat the test steps (i) and (ii) except that the DNID is set to 12345 and the Sequence No. is
changed in the area poll packet.

Expected result: The MES should ignore this area poll.

(iiv) Repeat the test steps (i) and (ii) except that the LES ID and the Sequence No. are changed in
the area poll packet.

Expected result: The MES should ignore this area poll.

Recommended Test Procedures (RTPs), Page: 169


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

PART 3 PRE-ASSIGNED DATA REPORTING

Test 1 Treatment of Bulletin Board and SCD

Test (1.a) A sequence of Three Bad Bulletin Boards

(i) Pre-programmed set up is as follows:

LES ID = ID of the LES Simulator.

Sub-address =0

DNID = 11111

Member Number = 123

Logical Channel No. =4

Start Frame =5

Packets per Report =4

Slot No. =2

Interval = 100 frames

Duration =1

(ii) Set up a Group Poll Packet:

DNID = 11111

LES ID = ID of the LES Simulator.

LES TDM = TDM of the LES Simulator.

Sub-address =0

Randomising Interval = 00

Response = 01

Command = 02

Sequence No. =8

Signalling Channel No. = the number given by the LES Simulator

(iii) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
above Group Poll in frame 0 to the MES.

Rxd Frame BB Status SCD Status Packets TDM Source


Frame -5 good BB good SCD NCS
Frame -4 good BB good SCD ,,
Frame -3 good BB good SCD ,,
Frame -2 good BB good SCD ,,
Frame -1 good BB good SCD ,,

Recommended Test Procedures (RTPs), Page: 170


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Frame 0 good BB good SCD Group Poll ,,

Note: Frames may be lost whilst the receiver re-tunes and synchronises with the LES TDM

Frame 3 bad BB good SCD LES


Frame 4 bad BB good SCD ,,
Frame 5 bad BB good SCD ,,
Frame 6 good BB good SCD [FAIL] ,,

Expected result: The MES should tune to the LES TDM but not transmit the Data Report. After frame
5, the MES should tune to the NCS. The DTE shows Data Report Failed because of TDM lost. This
data report may be re-sent using the unreserved data reporting service later and the randomising
interval should comply with that indicated in the bulletin board.

Test (1.b) A sequence of bad Signalling Channel descriptors

(i) Transmit a sequence of Basic Test Frames from the LES TDM channel, each with a good
checksum for the BB and a bad checksum for the SCD, preceded by a sequence with good
BBs and good SCDs on the NCS common channel but use the simulator to transmit to the
MES on the NCS Common Channel a Test Group Poll Frame in frame 0.

Rxd Frame BB Status SCD Status Packets TDM Source


Frame -5 good BB good SCD NCS
Frame -4 good BB good SCD ,,
Frame -3 good BB good SCD ,,
Frame -2 good BB good SCD ,,
Frame -1 good BB good SCD ,,
Frame 0 good BB good SCD Group Poll ,,

Note: Frames may be lost whilst the receiver re-tunes and synchronises with the LES TDM

Frame 3 good BB bad SCD LES


Frame 4 good BB bad SCD ,,
Frame 5 good BB bad SCD ,,
Frame 6 good BB good SCD ,,

Expected result: The MES should tune to the LES TDM but not transmit the Data Report. After frame
5, the MES should tune to the NCS. The DTE shows Data Report Failed. This data report may be re-
sent using the unreserved data reporting service later and the randomising interval should comply with
that indicated in the bulletin board.

Test (1.c) One good Bulletin Board in last three

(i) Repeat Test (a) up to Frame 0, and then continue the following variations for frame 3 to 5:

(ii) Rxd Frame BB Status SCD Status Packets TDM Source

Frame 3 bad BB good SCD LES


Frame 4 bad BB good SCD ,,
Frame 5 good BB good SCD ,,

Expected result: The MES should tune to the LES Signalling Channel and send a Data Report.

(iii) Rxd Frame BB Status SCD Status Packets TDM Source

Recommended Test Procedures (RTPs), Page: 171


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Frame 3 good BB good SCD LES


Frame 4 bad BB good SCD ,,
Frame 5 bad BB good SCD ,,

Expected result: The MES should tune to the LES Signalling Channel and send a Data Report.

(iv) Rxd Frame BB Status SCD Status Packets TDM Source

Frame 4 good BB good SCD ,,


Frame 5 bad BB good SCD ,,
Frame 3 bad BB good SCD LES

Expected result: The MES should tune to the LES Signalling Channel and send a Data Report.

Test 2 Bulletin Board Information Tests

Test (2.a) Bulletin Board Status - Out of Service

(i) Transmit a Sequence of modified Basic Test Frames from the NCS and a Sequence of Basic
Test Frames from the LES, in which the only change is to set Bit 6 of the Status byte to 0,
meaning out of service.

(ii) Initiate a Pre-assigned Data Report at the MES.

Expected Result: The MES does not attempt to use the Signalling Channel and a prompt such as "LES
out of service" should be printed out or appear on display.

Test (2.b) Bulletin Board Status - Restoration mode

(i) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
Group Poll in frame 0 to initiate a Pre-assigned data reporting

Expected result: The MES should tune to the LES TDM.

(ii) Transmit a sequence of Basic Test Frames with good BBs and good SCDs from the LES TDM
channel, the chosen multislot showing the reserved bit set.

Expected result: The MES should transmit, as pre-programmed, a pre-assigned data report in slot 2 of
frame 5.

(iii) After successful completion of the first pre-assigned data report, set the NCS TDM Channel
Type to Standby NCS Common Channel (Restoration mode Network operation) and the LES
TDM Channel Type to joint Common Channel and LES TDM.

(iv) Transmit a Network Update packet from the NCS with the following fields:

Network Version =2

LES Total =1

LES ID = ID of the Simulator LES.

LES Status = 01111000 Binary

Recommended Test Procedures (RTPs), Page: 172


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

LES Services[1] = 10110010 Binary

LES Services[2] =0

LES TDM = TDM of Simulator LES

(v) Transmit a continuous sequence of good Basic Test Frames from the NCS with the Channel
Type set to Standby NCS Common Channel.

(vi) Transmit a continuous sequence of good Basic Test Frames from the LES with the Channel
Type set to Joint Common and TDM.

(vii) Verify that a prompt is sent to the operator via the DTE requesting the operator to select a
LES.

(viii) Select a LES which is assigned to the MES (only one available in this case).

Expected result: The MES should not attempt to send pre-assigned data report until both NCS and LES
are back to normal status.

Test 3 Signalling Control Process

Test (3.a) Slot not reserved

(i) Transmit a sequence of Basic Test Frames from the NCS TDM channel, and then send the
Group Poll in frame 0 to initiate a Pre-assigned data reporting

Expected result: The MES should tune to the LES TDM.

(ii) Transmit a sequence of Basic Test Frames with good BBs and good SCDs from the LES TDM
channel, the chosen multislot showing the reserved bit not set.

Expected result: The MES should not attempt to use the signalling channel but tune back to the NCS.
The DTE shows the data report failed because of Slot Reservation Lost. This data report ( less than 4
packets) may be re-sent using the unreserved data reporting service later and the randomising interval
should comply with what indicated in the bulletin board.

Test (3.b) One Packet per Report (success)

(i) Repeat the test steps (i) and (ii) in Test (3.a) except the chosen multislot showing the reserved
bit set in the step (ii).

Expected result: The MES should tune to the Signalling Channel and transmit the Data Report.

(ii) Transmit a sequence of Basic Test Frames from the LES, the chosen multislot showing burst
received.

Expected result: The MES should indicate the Data Report successfully received.

Test (3.c) One Packet per Report (error)

(i) Transmit a sequence of Basic Test Frames from the NCS, each with a good checksum for both
BB and SCD and send the Group Poll in frame 0 to initiate Pre-assigned data reporting. Then,

Recommended Test Procedures (RTPs), Page: 173


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

transmit a sequence of Basic Test Frames from the LES with good BBs and good SCDs with
the chosen multislot showing the reserved bit set.

Expected result: The MES should tune to the LES and transmit the Data Report in slot 2 of frame 5.

(ii) Transmit a sequence of Basic Test Frames from the LES, with good BBs and good SCDs, in
which the slot burst received bit is zero.

Expected result: The MES should consider the data report failed. This data report (less than 4 packets)
may be re-sent using the unreserved data reporting service later and the randomising interval should
comply with that indicated in the bulletin board.

Test (3.d) One Packet per Report (bad response)

(i) Transmit a sequence of Basic Test Frames from the NCS, each with a good checksum for both
BB and SCD and send the Group Poll in frame 0 to initiate Pre-assigned data reporting. Then,
transmit a sequence of Basic Test Frames from the LES with good BBs and good SCDs with
the chosen multislot showing the reserved bit set.

Expected result: The MES should tune to the LES and transmit the Data Report in slot 2 of frame 5.

(ii) Continue transmitting a sequence of Basic Test Frames from the LES, with good BBs but bad
SCDs.

Expected result: The MES should consider the data report failed. This data report (less than 4 packets)
may be re-sent using the unreserved data reporting service later.

Test (3.e) Multiple Packets per Report (Ok)

(i) Transmit a sequence of Basic Test Frames from the NCS, each with a good checksum for both
BB and SCD and send the Group Poll in frame 0 to initiate Pre-assigned data reporting (2
packets). Then, transmit a sequence of Basic Test Frames from the LES with good BBs and
good SCDs with the chosen multislot showing the reserved bit set.

Expected result: The MES should tune to the LES TDM and then the Signalling Channel to transmit
the first packet of the Data Report, in slot 2 of frame 5, with the Continuation bit set.

(ii) On receiving the first packet, transmit a sequence of Basic Test Frames from the LES, with
good BBs and good SCDs and the chosen multislot showing burst received and reserved.

Expected result: The MES should send the second packet of the Data Report without the Continuation
bit set.

(iii) On receiving the second packet, transmit a sequence of Basic Test Frames from the LES, with
good BBs and good SCDs and the chosen multislot showing burst received and not reserved.

Expected result: The MES should show the Data Report successfully received.

Test (3.f) Multiple Packets per Report (bad response associated with packet 1)

(i) Transmit a sequence of Basic Test Frames from the NCS, each with a good checksum for both
BB and SCD and send the Group Poll in frame 0 to initiate Pre-assigned data reporting (2
packets). Then, transmit a sequence of Basic Test Frames from the LES with good BBs and
good SCDs with the chosen multislot showing the reserved bit set.

Recommended Test Procedures (RTPs), Page: 174


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Expected result: The MES should tune to the LES TDM and then the Signalling Channel to transmit
the first packet of the Data Report, in slot 2 of frame 5, with the Continuation bit set.

(ii) Transmit a sequence of Basic Test Frames from the LES, with good BBs and bad SCDs.

Expected result: The MES should consider the data report failed. This data report may be re-sent using
the unreserved data reporting service later.

Test (3.g) Multiple Packets per Report (received bit error associated with packet 1)

(i) Transmit a sequence of Basic Test Frames from the NCS, each with a good checksum for both
BB and SCD and send the Group Poll in frame 0 to initiate Pre-assigned data reporting (2
packets). Then, transmit a sequence of Basic Test Frames from the LES with good BBs and
good SCDs with the chosen multislot showing the reserved bit set.

Expected result: The MES should tune to the LES TDM and then the Signalling Channel to transmit
the first packet of the Data Report, in slot 2 of frame 5, with the Continuation bit set.

(ii) Transmit a sequence of Basic Test Frames from the LES, with good BBs and good SCDs and
the chosen multislot showing the burst reserved but not received.

Expected result: The MES should consider the data report failed. This data report may be re-sent using
the unreserved data reporting service later.

Test (3.h) Multiple Packets per Report (reserved bit error associated with packet 1)

(i) Transmit a sequence of Basic Test Frames from the NCS, each with a good checksum for both
BB and SCD and send the Group Poll in frame 0 to initiate Pre-assigned data reporting (2
packets). Then, transmit a sequence of Basic Test Frames from the LES with good BBs and
good SCDs with the chosen multislot showing the reserved bit set.

Expected result: The MES should tune to the LES TDM and then the Signalling Channel to transmit
the first packet of the Data Report, in slot 2 of frame 5, with the Continuation bit set.

(ii) Transmit a sequence of Basic Test Frames from the LES, with good BBs and good SCDs and
the chosen multislot showing burst received but not reserved.

Expected result: The MES should consider the data report failed. This data report may be re-sent using
the unreserved data reporting service later.

Test (3.i) Multiple Packets per Report (bad response associated with packet 2)

(i) Transmit a sequence of Basic Test Frames from the NCS, each with a good checksum for both
BB and SCD and send the Group Poll in frame 0 to initiate Pre-assigned data reporting (2
packets). Then, transmit a sequence of Basic Test Frames from the LES with good BBs and
good SCDs with the chosen multislot showing the reserved bit set.

Expected result: The MES should tune to the LES TDM and then the Signalling Channel to transmit
the first packet of the Data Report, in slot 2 of frame 5, with the Continuation bit set.

(ii) Transmit a sequence of Basic Test Frames from the LES, with good BBs and good SCDs and
the chosen multislot showing burst received and reserved.

Expected result: The MES should transmit the second packet of the Data Report.

Recommended Test Procedures (RTPs), Page: 175


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(iii) Transmit a sequence of Basic Test Frames from the LES, with good BBs and bad SCDs.

Expected result: The MES should consider the data report failed. This data report may be re-sent using
the unreserved data reporting service later.

Test (3.j) Multiple Packets per Report (received bit error associated with packet 2)

(i) Transmit a sequence of Basic Test Frames from the NCS, each with a good checksum for both
BB and SCD and send the Group Poll in frame 0 to initiate Pre-assigned data reporting (2
packets). Then transmit a sequence of Basic Test Frames from the LES with good BBs and
good SCDs with the chosen multislot showing the reserved bit set.

Expected result: The MES should tune to the LES TDM and then the Signalling Channel to transmit
the first packet of the Data Report, in slot 2 of frame 5, with the Continuation bit set.

(ii) Transmit a sequence of Basic Test Frames from the LES, with good BBs and good SCDs and
the chosen multislot showing burst received and reserved.

Expected result: The MES should transmit the second packet of the Data Report.

(iii) Transmit a sequence of Basic Test Frames from the LES, with good BBs and good SCDs and
the chosen multislot showing burst not received but reserved.

Expected result: The MES should consider the data report failed. This data report may be re-sent using
the unreserved data reporting service later.

(iv) Repeat the test steps (i) to (iii), except the chosen multislot showing burst not received and
unreserved in the step (iii).

Expected result: The MES should consider the data report failed. This data report may be re-sent using
the unreserved data reporting service later.

Test (3.k) Multiple Packets per Reports (received bit Ok associated with packet 2)

(i) Transmit a sequence of Basic Test Frames from the NCS, each with a good checksum for both
BB and SCD and send the Group Poll in frame 0 to initiate Pre-assigned data reporting (2
packets). Then, transmit a sequence of Basic Test Frames from the LES with good BBs and
good SCDs with the chosen multislot showing the reserved bit set.

Expected result: The MES should tune to the LES TDM and then the Signalling Channel to transmit
the first packet of the Data Report, in slot 2 of frame 5, with the Continuation bit set.

(ii) Transmit a sequence of Basic Test Frames from the LES, with good BBs and good SCDs and
the chosen multislot showing burst received and reserved.

Expected result: The MES should transmit the second packet of the Data Report.

(iii) Transmit a sequence of Basic Test Frames from the LES, with good BBs and good SCDs and
the chosen multislot showing burst received and reserved.

Expected result: The MES should consider the Data Report successfully received.

Recommended Test Procedures (RTPs), Page: 176


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Test 4 LES in Demand Assigned Mode

(i) Initiate pre-assigned data reporting and make the first data report successful in permanent
mode.

(ii) Before sending the second data report, transmit the Network Update which shows the LES
working in demand assigned mode.

Expected result: The MES should terminate sending the subsequent data reports until the LES is back
into the permanent mode.

(iii) Set up a Group Poll Packet:

DNID = 11111

LES ID = ID of the LES Simulator.

LES TDM = FFFF

Sub-address =0

Randomising Interval = 00

Response = 01

Command = 02

Sequence No. =1

Signalling Channel No. = the number of NCS Signalling Channel

(iv) Transmit the above poll on the NCS TDM channel and the chosen multislot shows the burst
reserved on the selected signalling channel.

Expected result: The MES should tune to the NCS signalling channel and send the data report in slot 2
of frame 5.

Test 5 MES Out of Ocean Region

(i) Initiate pre-assigned data reporting and make the first data report successful.

(ii) Initiate a Logout Request before sending the second data report.

Expected result: The MES should not send data reports any more after receiving the Logout ACK.

(iii) Initiate a Login Request.

Expected result: The MES may resume the reserved data reporting after receiving the Login ACK and
the correct slot logical channel assignment is used.

Recommended Test Procedures (RTPs), Page: 177


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 6-B TDMA SYNCHRONISATION

1 PURPOSE OF THE TEST

The test shall verify that the delays and duration of transmitted bursts from the MES are in accordance
with SDM Volume 3, Part 2, Chapter 2, Section 6.2.1.

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

Temperature

4 TEST SET-UP

TEMPERATURE CHAMBER

NCS/LES COUPLER MES


SIMULATOR

SYNC
RF
DETECTOR

STORAGE
SCOPE
DTE

CONTROLLER

Figure 6-B

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Oscilloscope with memory.

(c) RF detector.

(d) Temperature chamber

6 TEST PROCEDURE

(a) Connect the simulators and the MES as shown in the TEST SET-UP.

Recommended Test Procedures (RTPs), Page: 178


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Initialise the set-up.

(b) Set the Bulletin Board and the Signalling Channel Descriptors.

Randomizing Interval =1;

Return Link Operation = 600 sym/s;

Signalling Channels = 4;

At the MES initiate a request for assignment. Measure and record the time interval from the
end of the received frame to the start of the burst (td) and the transmitted burst duration (tb).

SIG CH no.2 to 4: not available

SIG CH no.1:f=(fa);only slot 1 available

SIG CH no.1,3,4: not available

SIG CH no.2:f=(fb);only slot 2 available

SIG CH no.1,2,4: not available

SIG CH no.3:f=(fc);only slot 3 available

SIG CH no.1,2,3: not available

SIG CH no.4:f=(fd);only slot 4 available

SIG CH no.2 to 4: not available

SIG CH no.1:f=(fa);only slot 5 available

SIG CH no.2 to 4: not available

SIG CH no.1:f=(fa);only slot 6 available

and so on for slots 7 through 14.

(c) Set the Bulletin Board and the Signalling Channel Descriptors:

Randomizing Interval = 1;

Return Link Operation = 600 sym/s;

Signalling Channels = 1;

At the MES initiate a request for assignment. Measure and record the time interval from the
end of the received frame to the start of the burst (td) and the transmitted burst duration (tb)
for the following:

SIG CH no.1:f=(fc);only slot 1 available

SIG CH no.1:f=(fc);only slot 2 available

SIG CH no.1:f=(fc);only slot 3 available

Recommended Test Procedures (RTPs), Page: 179


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

and so on until slot 14.

(d) Set the Bulletin Board and the Signalling Channel Descriptors:

Randomizing Interval =1;

Return Link Operation = 600 sym/s;

Signalling Channels = 1 to 40;

At the MES initiate a request for assignment and measure and record the time interval from
the end of the received frame to the start of the burst (td) and the transmitted burst duration
(tb):

SIG CH no.1;only slot 1 available

All remaining signalling channels; no slots available

Repeat for 1 to 40 signalling channels and then for 1200 sym/s return link operation..

(e) Set the Bulletin Board and the Signalling Channel Descriptors:

Randomizing Interval =1;

Return Link Operation = 1200 sym/s;

Signalling Channels = 40;

At the MES initiate a request for assignment and measure and record the time interval from
the end of the received frame to the start of the burst (td) and the transmitted burst duration
(tb) for the following:

SIG CH no.2 to 40 ; not available

SIG CH no.1 to 40 ;only slot 28 available

(f) With the MES in the temperature chamber at 0 deg C set the Bulletin Board and the Signalling
Channel Descriptors:

Randomizing Interval = 1;

Return Link Operation = 1200 sym/s;

Signalling Channels = 3;

At the MES initiate a request for assignment and measure and record the time interval from
the end of the received frame to the start of the burst (td) and the transmitted burst duration
(tb) for the following:

SIG CH no.2,3: not available/

SIG CH no.1:f=(fa);only slot 1 available

SIG CH no.1,3: not available/

SIG CH no.2:f=(fb);only slot 2 available

Recommended Test Procedures (RTPs), Page: 180


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

SIG CH no.1,2: not available/

SIG CH no.3:f=(fc);only slot 3 available

SIG CH no.2,3: not available/

SIG CH no.1:f=(fa);only slot 4 available

SIG CH no.2,3: not available/

SIG CH no.1:f=(fa);only slot 5 available

and so on with slots 6 through 28.

(g) With the MES in the temperature chamber at +35 deg C set the Bulletin Board and the
Signalling Channel Descriptors:

Randomizing Interval = 1;

Return Link Operation = 1200 sym/s;

Signalling Channels = 1;

At the MES initiate a request for assignment and measure and record the time interval from
the end of the received frame to the start of the burst (td) and the transmitted burst duration
(tb) for the following:

SIG CH no.1:f=(fa);only slot 1 available

SIG CH no.1:f=(fb);only slot 2 available

SIG CH no.1:f=(fb);only slot 3 available

SIG CH no.1:f=(fb);only slot 4 available

and so on with slots 5 through 28.

7 PASS/FAIL CRITERIA

A critical feature of this test is the establishment of the reference time (the instant at which an entire
TDM frame has been received). The results for this test item should be supplied with details of how
this reference is accurately established.

The measured td and tb above shall be within the following limits:

td = 300+208 * no.sig+740 * (slot no.-1) ± 1 TDM symbol periods and

631.75 ≤ tb ≤ 633 TDM symbol periods for first satellite generation.

td = 300+208 * no.sig+370 * (slot no.-1) ± 1 TDM symbol periods and

315.75 ≤ tb ≤ 317 TDM symbol periods for second satellite generation.

Recommended Test Procedures (RTPs), Page: 181


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 6-C RANDOM ACCESS

1 PURPOSE OF THE TEST

The test shall verify that the slot selected by the MES for random access and retransmission are random
with the characteristics indicated in SDM Volume 3, Part 2, Chapter 2, Section 6.2.2.

The check makes use of the Chi-square criterion with a probability of approx. 0.7 and therefore the
statistical nature of the test must be appreciated.

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

NCS/LES
MES
SIMULATOR

DTE
CONTROLLER

Figure 6-C

5 REQUIRED TEST EQUIPMENT AND FACILITIES

a. NCS/LES simulator.

6 TEST PROCEDURE

(a) Connect the simulators and the MES as shown in TEST SET-UP. Initialise the set-up.

(b) Set the BB and the Signalling Channel Descriptor as:

Randomising Interval = 1;

Return Link Operation = 1200 sym/s;

Signalling Channels = 1;

Slots Available = 1 to 5;

Recommended Test Procedures (RTPs), Page: 182


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Send an Announcement.

(c) Record the slot number in which the Assignment Response was received.

(d) Send a Forced Clear from the LES.

(e) Repeat steps (b) through (d) for 499 times and calculate the Xe: (i = 1 through 5);

Nei = (no. of bursts transmitted in slot i);

(Nei-100)2
Kei = 100 ;

5
Xe = ∑kei ;
i=1

(f) Repeat steps (b) through (d) for 500 times with BB and Signalling Channel Descriptor as:

Randomising Interval = 1;

Return Link Operation = 1200 sym/s;

Slots Available = 9 through 28;

Calculate Xf (i = 9 through 28);

Nfi= (no. of bursts transmitted in slot i);

(Nfi-25)2
Kfi= 25 ;

28
Xf = ∑Kfi ;
i=9

(g) Set the BB and the Signalling Channel Descriptor as:

Randomising Interval = 5;

Return Link Operation = 1200 sym/s;

Slots Available = 9 through 28;

Send an Announcement.

(h) Make the received assignment response fail.

(i) Record the frame in which the second Assignment Response was sent.

(j) Send a Forced Clear from the LES.

(k) Repeat steps (g) through (i) for 99 times and calculate the Xj (i = 9 through 28);

Nji= (no. of bursts transmitted in frame i);

Recommended Test Procedures (RTPs), Page: 183


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(Nji-20)2
Kji= 20 ;

5
Xj = ∑Kji ;
j=1

7 PASS/FAIL CRITERIA

The calculated Xe,Xf and Xj shall be:

Xe≤[2.2];

Xf≤[15.3];

Xj≤[2.2];

Manufacturers are also requested to submit a brief description of the technique employed for random
number generation as part of this test.

Recommended Test Procedures (RTPs), Page: 184


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 6-D COMMON CHANNEL SELECTION

1 PURPOSE OF THE TEST

The test shall verify the MES's memory capability in respect to the NCS common channels and their
selection under different network scenarios as indicated in SDM Volume 3, Part 2, Chapter 2, Section
6.3.

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

Refer to figure 6-C.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

6 TEST PROCEDURE

Part A

(a) Connect the simulators and the MES as shown in 4, TEST SET-UP. Enter the 76 NCS
channels in the MES memory. Set configuration LESs in the simulator

(b) Tune the NCS/LES simulator and the MES to channel no.1108010.

(c) Transmit in the TDM frame an announcement packet for the MES under test; check and
record that the MES sent an assignment response packet.

(d) Turn off the MES and turn it on again after 5 minutes.

(e) Repeat steps b. through c. with each of the NCS channels entered in step a.

Part B

(a) Set simulator in "restoration mode". Connect the simulators and the MES as shown in 4,
TEST SET-UP. Enter the 76 NCS channels in the MES memory. Set configuration LESs in
the simulator, including a LES ID 101 (1200010)

(b) After the MES received the Network Update packet from the standby NCS, check that the
operator was prompted to select a LES.

(c) Select the standby NCS and make a From-Mobile message transfer, a To-Mobile message
transfer and a distress call (SES only).

(d) Try to send log-in requests, PV test requests and log-out requests from the MES; check and
record whether any packets have been actually generated.

Recommended Test Procedures (RTPs), Page: 185


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(e) For the class 2 (Inmarsat-C mode) and class 3 MESs, transmit a SafetyNet EGC and a
FleetNet EGC on the standby NCS common channel.

(f) Select the LES ID 101 (joint common and TDM) and repeat step (c) to (e). But a SafetyNet
EGC is transfered on the standby common channel and a FleetNet EGC is transmitted on the
joint common and TDM.

(g) For the class 2 MES, set the terminal to EGC mode and transmit a SafetyNet on the standby
common channel and FleetNet EGC on the joint common and TDM channel.

Part C

(a) Enter the 76 NCS channels in the MES memory. Set configuration LESs in the simulator.

(b) Set the current NCS to 144 and the simulator to 144.

(c) Transmit two NCS common channels, one of which is set to a global beam NCS common
channel with NCS ID 144 and power level [X dBw], and the other is set to a spot beam
common channel with NCS ID 150, and the power level [X+5 dBw].

(d) Connect the simulators and the MES as shown in 4, TEST SET-UP.

(e) From the DTE, enter a command to scan the NCS common channel frequencies.

(f) Check the NCS ID which the MES tuned to and the Log-in request was transmitted.

(g) Transmit two NCS common channels. One is set to a global beam NCS common channel with
NCS ID 244 and the power level [X dBw], and the other is set to a spot beam common
channel with NCS ID 250 and the power level [X+5 dBw].

(h) After the MES could not synchronise to any NCS common channels in AOR-E, check that a
prompt to scan other ocean regions was sent to the operator via the DTE.

(i) Start scanning in the other ocean regions [POR, IOR, AOR-W] manually.

(j) Check that the MES tuned to the spot beam NCS in POR and Log-in request was sent.

(k) Keep the MES idle for more than 24 hours and check that the MES starts scanning procedures
automatically after 24 hours.

7 PASS/FAIL CRITERIA

The following responses from the MES are expected:

Part A

steps c and e. valid assignment responses to the LES;

Part B

step b. A prompt to select a LES is sent to the operator.

step c. All calls are successful.

step d. No packets are transmitted.

Recommended Test Procedures (RTPs), Page: 186


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

step e. The class 2 (Inmarsat-C mode) and class 3 MESs receive both a SafetyNet EGC and
a FleetNet EGC.

step f. A To-Mobile message transfer, From-Mobile message transfer and distress call (SES
only) are successful The log-in, PVT and Log-out packets are not transmitted. The
class 2 (Inmarsat C mode) MES can only receive a FleetNet EGC and the class 3
MES receives both EGCs

step g. The class 2 MES can only receive a SafetyNet EGC.

Part C

step f. The MES tune to NCS ID 150 and valid Log-in request is transmitted.

step h. The prompt is sent to the operator.

step j. The MES tuned to NCS ID 250 and valid Log-in request is transmitted.

step k. Automatic scanning starts.

Recommended Test Procedures (RTPs), Page: 187


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 6-E OCEAN REGION REGISTRATION

1 PURPOSE OF THE TEST

The test shall verify the MESs functions in respect to the Ocean Region registration as indicated in
SDM Volume 3, Part 2, Chapter 2, Section 6.5.

2 APPLICABILITY

All classes of MES.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

Refer to figure 6-C.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

6 TEST PROCEDURE

(a) Enter the 76 NCS IDs and channel numbers into the MES.

(b) Set the simulator NCS ID to 144 with the simulator disconnected, and erase the network
information from the MES memory or set the current NCS ID different from ID 144..

(c) Turn the MES off and connect the simulators and the MES as shown in 4, TEST SET-UP.

(d) Turn the MES on and check that after td minutes a log-in request is sent to the NCS, measure
and record td and packet received.

(e) Repeat steps (c) to (d) with the simulator NCS ID 150 (1100010).

(f) Set the preferred ocean region to AOR-E and repeat steps (c) to (d) with the simulator NCS ID
244 (1258010).

(g) Set the preferred ocean region off and repeat steps (c) to (d) with the simulator NCS ID 244
(1258010).

(h) Repeat steps (c) to (d) with the simulator NCS ID 344 (1084010).

(i) Send manually a request for log-out from the MES and inspect via the DTE and the packet
received by the simulator.

7 PASS/FAIL CRITERIA

The following responses and MES status of the MES shall be observed:

step d and e. a valid log-in transmitted and td≤30 minutes;

Recommended Test Procedures (RTPs), Page: 188


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

step f. no log-in request packets transmitted and a prompt for NCS scanning sent to the
operator via the DTE;

step g and h. a valid log-in request transmitted and td≤2 hours and a new network information
received;

step i. a valid log-out transmitted;

Recommended Test Procedures (RTPs), Page: 189


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 6-E/1 OCEAN REGION LES SUPPORT

1. Purpose of the Test


To verify the MES will support up to 64 LES’ s in an Ocean Region as indicated in
SDM Vol.3 Pt.3 Chap.1 Section 2.8.1 (Number of LES’s Supported)
SDM Vol.4 Chap.3 Sect. 3.1.6 (Network Update)
SDM Vol.5 Chap.3

2. Applicability
All Classes
For LMES and LPES omitt tests (h)(i)(j)

3. Environmental Conditions
Normal Ambient

4. Test Set-up
Refer to figure 6-C

5. Required Equipment and Facilities


NCS/LES Simulator

6. Test Procedure
(a) With Simulator disconnected set simulator NCS ID 044 (AORW)

(b) Turn off the MES and connect to the simulator as per test set-up

(c) Turn on the MES initiate a scan and check that it logs into the NCS (Please supply screen
dump of MES indicating Sync and logged into AORW)

(d) Prepare a Network update packet in the simulator with a new network version number ,
supporting 63 LES’ s in that ocean region with an LES Descriptor for each LBS in that ocean
region.

(e) Send the network update packet on the NCS TDM 044 , record the packet received at the at
the MES provide Hex printout. Record the MES behaviour provide protocol printouts
Result: The MES should not respond but should update its network information.

(f) Send a from mobile message to every 5th one of the 63 LES’s in the region and record the
signalling and message protocol and provide protocol and hex printouts.
Result: The MES should follow the signalling and message requirements in the SDM All
messages should be successful.

(g) Send a to mobile message from every 5th one of the 64 LES’s in the region. Record the
signalling and message protocols and provide Hex and protocol printouts.
Result: The MES should follow the signalling and message requirements in the SDM All
messages should be successful.

Recommended Test Procedures (RTPs), Page: 190


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(h) Send a distress priority message from the MES to anyone of the 64 LES’s in the ocean region.
Record the signalling and message protocols and provide hex and protocol printouts. Result:
The Message should be successful.

(i) Repeat (f) for 5 different LES’s in the region but after the channel assignment is received by
the MES send a Distress Alert. Record the signalling and message protocol and provide Hex
and protocol printouts.
Result: The Distress Alert should be successful.

(j) Send a Distress Alert to any one of the LES’s in the ocean region but don’t send the
Distress Alert Ack from the LES, send the Distress Alert Ack from the NCS.
Result: The MES should send the distress alert MaxCD times before retuning to the
NCS to send the distress alert. The Distress Alert to the NCS should be successful.

(k) Switch off the MES and disconnect all power for 6 hours , reconnect MES and switch on,
interrogate the DTE for Network information e.g. number of LES’s in the ocean region
Result: Network information should be as before.

Recommended Test Procedures (RTPs), Page: 191


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 6-F IDLE AND BUSY CONDITIONS

1 PURPOSE OF THE TEST

The test shall verify that the MES operation complies with the requirements stated in SDM Volume 3,
Part 2, Chapter 2, Section 6.6. The response of the MES when idle and under various busy conditions
will be recorded.

For Class 2 and 3 MESs, the test shall also check the operation of the MES as an EGC receiver.

2 APPLICABILITY

All classes of MESs; Parts B and C of the test procedure are applicable to Class 2 and 3 MESs only.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

NCS/LES simulator connected to the MES as for test item 6-A. Refer to figure 6-C.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

6 TEST PROCEDURE

PART A

(a) Connect the simulator to the MES. Initialise the set-up.

(b) Set the DTE off-line and transfer a test message from the simulator (To-Mobile message
transfer). Check if the message has been received and stored by retrieving it with the DTE on-
line.

(c) Disconnect the DTE and repeat step (b). Reconnecting the DTE, retrieve the message and
record.

(d) Prepare a test message with the DTE and transfer it to the DCE. Establish a From-Mobile
message transfer and with the DTE initiate a request for forced clearing. Record throughout
the test the packets transmitted by the MES and their relative time.

(e) Prepare a test message from the simulator (approx. one minute duration) and initiate a To-
Mobile message transfer. After the ANNOUNCEMENT, force clear from the MES and
record all the packets transmitted by the MES and their relative time.

(f) Repeat step (d) but force clear during the message being transferred. [Try to retrieve the
message from the DCE].

(g) Repeat step (e) but force clear, after receiving the ACKNOWLEDGEMENT REQUEST and
sending out the ACKNOWLEDGEMENT, from the simulator at the end of the first transfer of
the message.

Recommended Test Procedures (RTPs), Page: 192


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

PART B

Note: This part of the procedure is applicable to Class 2 MESs only.

(a) Maintaining the same set-up, select the MES operation as "EGC receiver"; throughout the
following steps observe and record the response of the MES and the received EGC message.

(b) Send in the same NCS TDM frame a valid ANNOUNCEMENT packet and a valid EGC
packet (service other than distress).

Note: "valid" means that the information contained in the packets (MES ID or Geographical
Address, etc) will match the MES ID and its set-up, so that the packets will be recognised by
the MES.

(c) Continue to send in the following ten frames valid EGC and ANNOUNCEMENT packets.

(d) Prepare a test message at the MES and try to initiate a From-Mobile message transfer.

(e) Select the operation of the MES as "Inmarsat-C terminal".

(f) Prepare at the simulator a long EGC message (Priority 0, lasting at least 3 frames), which
should be split into multiple packets, as stated in SDM, Volume 4, Chapter 3, Section 3.11.

(g) Start sending the EGC message together with a valid ANNOUNCEMENT packet with
priority 0 in the same frame as the first EGC packet (the ANNOUNCEMENT first).

(h) Repeat step (g), but with the first EGC packet before the ANNOUNCEMENT in the same
frame.

(i) Repeat step (g), but with the ANNOUNCEMENT and the seond EGC packet in the same
frame.

(j) Prepare at the simulator a long EGC message (Priority 1, lasting at least 3 frames), which
should be split into multiple packets.

(k) Start sending the EGC message together with a valid ANNOUNCEMENT packet with
priority 0 in the same frame ( the ANNOUNCEMENT first)

(l) Repeat step (k), but with the ANNOUNCEMENT and the seond EGC packet in the same
frame.

(m) For SES only: Repeat step (k), but with the ANNOUNCEMENT (Distress Priority ) and the
seond EGC packet in the same frame.

(n) Prepare at the simulator a long EGC message (Priority 3, lasting at least 3 frames), which
should be split into multiple packets.

(o) Start sending the EGC message together with a valid ANNOUNCEMENT packet with
priority 0 in the same frame ( the ANNOUNCEMENT first)

(p) For SES only: Repeat steps (n) and (o), but with the ANNOUNCEMENT (Distress Priority)
and the seond EGC packet in the same frame.

Recommended Test Procedures (RTPs), Page: 193


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(r) Initialise the set-up, simulating a network which includes a LES operating in Demand
Assignment (DA), prepare a long EGC message (service as Distress, lasting at least 10 TDM
frames).

(s) For SES only: Start sending the EGC message (split into packets) and during the reception of
the second or third TDM frame initiate a DISTRESS ALERT from the MES (to the DA-LES).
At the simulator follow the process described in Volume 5, Fig. 3.5.6 for MES Process
Control (eg in the smoothest way, making all packet transactions successful), but still keeping
the transmission of the EGC packets.

(x) For SES only: Prepare a test message at the MES and repeat step (s), but initiate an
ASSIGNMENT REQUEST (distress priority) for a From-Mobile message transfer from the
MES.

PART C

Note: This part of the procedure is applicable only to Class 3 MESs.

(a) As in steps (f), (g) and (i), Part B.

(b) As in steps (j), (k) and (m), Part B.

(c) As in step (n), (o) and (p), Part B.

(d) Start sending the EGC message (split into packets) and during the reception of the second or
third TDM frame initiate an ASSIGNMENT REQUEST (From-Mobile message transfer) to a
LES (in Permanent Assignment operation).

(e) For SES only: Repeat step (d) but initiate a DISTRESS ALERT from the MES.

7 PASS/FAIL CRITERIA

PART A

(b,c): the message shall be retrieved error free;

(d): the FORCED CLEAR packet shall be transmitted and the transmission of the message
terminated;

(e): the FORCED CLEAR packet shall be transmitted;

(f,g): the FORCED CLEAR packet shall be transmitted and no message or any part of it shall be
available;

PART B (applicable to Class 2 MESs only)

With reference to the above procedure:

(b,c): All EGC packets received correctly;

(d): The EGC packets received correctly and no From-Mobile message transfer shall have been
initiated;

Recommended Test Procedures (RTPs), Page: 194


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(g,h,i,m,p): The MES receiver shall have tuned to the LES TDM indicated in the
ANNOUNCEMENT;

(k,l,o): the EGC packets received correctly and tha ANNOUNCEMENT ignored;

(s): For SES only: The MES shall have successfully completed the distress alert transaction;

(x): For SES only: The MES shall have successfully completed the distress message transfer.

PART C (applicable to Class 3 MESs only)

With reference to the above procedure, the reception of the EGC messages shall be successfully
accomplished after each step (a) through (e) as well as the transactions (message transfers, Distress
Alerts (SES only) etc.) in which the MES was engaged.

Recommended Test Procedures (RTPs), Page: 195


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 7-A CHARACTER CODES

1 PURPOSE OF THE TEST

The test shall demonstrate that the DTE will correctly operate using character codes according the
International Alphabet 5 (IA5) as specified in greater detail in SDM Volume 3, Part 2, Chapter 2,
Section 7.2; in the event of parity errors detected on a character, the "low/line" character shall be
displayed and/or printed.

If the MES uses additional (optional) character codes such as ITA 2, these shall also be tested.

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient only.

4 TEST SET-UP

Refer to figure 6-C.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator;

6 TEST PROCEDURE

(a) Connect the simulators and the MES as shown in figure 6-C. Tune the NCS/LES simulator
and the MES to channel no. 1100010.

(b) Initiate a To-Mobile message transfer from the NCS/LES simulator with a 512 byte message
to be transferred; the content (bytes) of the message shall encompass the complete IA5 with
some bytes not valid as IA5 characters.

(c) After completion, display the received message and check its contents.

(d) Repeat steps (a), (b) and (c) for additional character codes if applicable.

7 PASS/FAIL CRITERIA

Step (c): The message received shall be the same as the transmitted one on a character basis except for
the bytes invalid as IA5 characters. If detectable these shall be displayed and/or printed as a "low/line"
character (5/15 in CCITT Rec. T.50).

Recommended Test Procedures (RTPs), Page: 196


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 7-B DISPLAY DEVICES

1 PURPOSE

To verify the message display of the DTE, be it a character display or printer, complies with SDM
Volume 3, Part 2, Chapter 2, Section 7.3; and to verify the status display, which may be in the DCE
and/or DTE, also complies with SDM Volume 3, Part 2, Chapter 2, Section 7.3.

2 APPLICABILITY

All classes of MESs, and alternative DTE equipment.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

Temperature

Humidity

Power supply

Vibration

4 TEST SET-UP

NCS/LES MES MES


SIMULATOR EME IME

POWER
SUPPLY
DTE

CONTROLLER
TEMPERATURE CHAMBER/VIBRATION TABLE

Figure 7-B

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Power supplies in which voltage and/or frequency can be varied. One appropriate power
supply is required for each of the power interfaces which may be supplied with the MES (i.e.
AC mains, DC mains, battery).

(c) Environmental chamber (temperature and humidity)

Recommended Test Procedures (RTPs), Page: 197


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(d) Vibration table

6 TEST PROCEDURE

MESSAGE DISPLAY

a) Initiate a transmission from the NCS/LES simulator, consisting of at least 150 lines of QBF
message.

b) Check that the message is displayed or printed at the MES correctly, without any errors.

c) Initiate a transmission from the NCS/LES simulator consisting of at least 75 lines of *RY
message. Check that the message is printed at the MES correctly, without any errors.

d) Repeat steps (a) through (c) at +35°C and 0°C.

e) Repeat steps (a) through (c) at 40 C and 95 % relative humidity.

f) Repeat steps (a) through (c) with vibration in each of three mutually orthagonal directions.

g) Repeat steps (a) through (c) with relevant power supply variations.

Note: *RY message is a repetition of alternating characters "R" and "Y"

STATUS DISPLAY

a) With NCS/LES simulator transmitting a TDM, check that the status display indicates frame
synchronization.

b) Turn off or remove the TDM, and check that the status display indicates loss of frame
synchronisation.

c) Initiate a transmission. Check that the status display indicates that the transmitter is on.

7 PASS/FAIL CRITERIA

All QBF and RY messages are received and displayed or printed with no errors.

The MES indicates correctly when frame synchronisation is achieved (or lost), when the transmitter is
on.

Recommended Test Procedures (RTPs), Page: 198


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 7-C KEYBOARD

1 PURPOSE

To verify the keyboard is operational over environmental conditions; that it complies with SDM
Volume 3, Part 2, Chapter 2, Section 7.4.

2 APPLICABILITY

All classes of MESs, and alternative DTE equipment.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

Temperature

Humidity

Vibration

Power Supply

4 TEST SET-UP

NCS/LES MES MES INTERFACE


SIMULATOR EME IME ANALYSER

POWER
SUPPLY

CONTROLLER DTE

TEMPERATURE CHAMBER/VIBRATION TABLE

Figure 7-C

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator

(b) Interface monitor (e.g. logic analyser)

(c) Power supplies in which voltage and/or frequency can be varied. One appropriate power
supply is required for each of the power interfaces which may be supplied with the MES (i.e.
AC mains, DC mains, battery).

(d) Environmental chamber (temperature and humidity)

Recommended Test Procedures (RTPs), Page: 199


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(e) Vibration table

6 TEST PROCEDURE

(a) Transfer an all character message from the DTE to the DCE, and initiate transmission. The all
character message is a QBF line followed by the characters on all remaining keys. This
message must be typed in character by character rather than being selected from the DTE
memory. The purpose here is to test each of the keyboard keys.

(b) Verify that the message is received at the NCS/LES simulator without any errors.

(c) Vibrate the keyboard in each of three mutually orthogonal directions, while continuously
monitoring the interface. Verify that no characters have been transmitted to the DCE. Also, to
the extent possible, verify that the keyboard has not sent any characters to any part of the
DTE.

(d) Repeat steps (a) and (b) at 0°C and 35°C, keeping the keyboard at the defined temperature
throughout the test.

(e) Repeat steps (a) through (b) at 40 C and 95 % relative humidity keeping the environmental
conditions constant throughout the test.

(f) Repeat steps (a) and (b) with voltage and frequency (if applicable) variations on the power
supply, as defined on the results sheet.

7 PASS/FAIL CRITERIA

No errors in any of the QBF messages, and no false keystrokes during vibration.

Recommended Test Procedures (RTPs), Page: 200


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 7-D MES MEMORY CAPACITY

1 PURPOSE OF THE TEST

The test shall demonstrate that

(a) the size of the memory allocated in the DCE for message storage and its management comply
with the requirements of SDM Volume 3, Part 2, Chapter 2, Section 7.5.1; and

(b) the characteristics of the non/volatile memory are retained under different environmental
conditions (refer to SDM Volume 3, Part 2, Chapter 2, section 7.5.2).

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

Temperature

Power supply

4 TEST SET-UP

TEMPERATURE CHAMBER

NCS/LES
SIMULATOR
MES

POWER
SUPPLY
DTE
CONTROLLER

Figure 7-D

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Temperature chamber

(c) Power supplies in which.voltage and/or frequency can be varied.

Recommended Test Procedures (RTPs), Page: 201


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6 TEST PROCEDURE

(a) Connect the simulators and the MES as shown in figure 7-D.

Tune the NCS/LES simulator and the MES to channel no. 1100010.

Ensure that the MES message memory is cleared (fully available).

(b) Initiate a To-Mobile message transfer from the NCS/LES simulator with a 32,768-byte
message to be transferred.

(c) After completion, display the received message and check its contents.

(d) Repeat step b. with 2048-byte test messages until the MES memory overflows.

(e) Check that an indication is received at the DTE and the latest message(s) (received after the
memory overflow) are displayed and/or printed.

(f) Set/up the MES with the following data:

[NCS channels, Ocean Region, preferred Ocean Region etc] and initiate a log-out request.

(g) By interrogating the DCE via the DTE, check the parameters entered in the MES non-volatile
memory and record them.

(h) Repeat step (g) under temperature extremes and main power variations.

(i) Turn off the MES and leave it in these conditions for 24 hours and repeat step (g).

7 PASS/FAIL CRITERIA

Step (c): the message shall be displayed with no errors.

Step (e): the latest messages shall be displayed error-free.

Steps(g): the data in the MES non-volatile memory shall be retained as entered during step (f).

Recommended Test Procedures (RTPs), Page: 202


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 7-E DCE/DTE INTERFACE CHARACTERISTICS

1 PURPOSE OF THE TEST

The test shall demonstrate that the mechanical, electrical and circuital characteristics of the interface
DCE - DTE comply respectively with either:

(RS-449) ISO 4902, CCITT V.11 and CCITT V.24;

or

(RS-232C) ISO 2110, CCITT V.28 and CCITT V.24.

Refer to SDM Volume 3, Part 2, Chapter 2, section 7.6.1 and SDM Volume 3, Part 2, Chapter 4,
section 3.

2 APPLICABILITY

The test is applicable to MESs provided with a separate DTE or with an Auxiliary DTE Interface port.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

Temperature

Power supply

4 TEST SET-UP

TEMPERATURE CHAMBER

DVM
NCS/LES
SIMULATOR MES

SCOPE

POWER
SUPPLY
DTE
CONTROLLER

Figure 7-E

Note: refer also to the Sections of CCITT recommendations mentioned above.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) Multimeter;

Recommended Test Procedures (RTPs), Page: 203


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(b) Oscilloscope;

(c) Power supply;

6 TEST PROCEDURE

Depending whether the DCE/DTE interface fitted is RS-449 or RS-232C type, the procedures in 6.1 or
6.2 shall be followed.

6.1 References are made to the CCITT V.11 Recommendation.

6.1.1 Connector and pin assignment checks;

6.1.2 Electrical characteristics:

a) Generator polarities (V.11, Section 4.1)

b) Receiver levels (V.11, Section 4.2)

c) Resistance and DC offset (V.11, Section 5.1)

d) Open-circuit (V.11, Section 5.2.1)

e) Termination (V.11, Section 5.2.2)

f) Short-circuit (V.11, Section 5.2.3)

g) Power-off (V.11, Section 5.2.4)

h) Dynamic balance and rise time (V.11, Section 5.3)

i) Input voltage-current (V.11, Section 6.2)

j) DC input sensitivity (V.11, Section 6.3)

Repeat a) through j) under high temperature/high power and low temperature/low power supply
conditions.

6.2 References are made to the CCITT V.28 Recommendation.

6.2.1 Connector and pin assignment checks;

6.2.2 Electrical characteristics:

a) Load characteristics (V.28, Section 3)

b) Generator characteristics (V.28, Section 4)

c) Levels (V.28, Section 5)

d) Signal (V.28, Section 6)

Repeat a) through d) under high temperature/high power supply and low temperature/low power supply
conditions.

Recommended Test Procedures (RTPs), Page: 204


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

7 PASS/FAIL CRITERIA

The results from tests 6.1.2 or 6.2.2 shall comply with the limits given in the referred Sections of the
CCITT Recommendations.

Recommended Test Procedures (RTPs), Page: 205


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 7-F INTERFACE CONTROL CODES

1 PURPOSE OF THE TEST

The test shall demonstrate that for each operator control function the corresponding codes exchanged
via the DCE/DTE interface comply with the requirements as set in SDM Volume 3, Part 2, Chapter 4.

2 APPLICABILITY

All classes of MESs with a DTE interface intended to make use of the control codes provided in SDM
Volume 3, Part 2, Chapter 4.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

NCS/LES INTERFACE
MES
SIMULATOR ANALYSER

DTE
CONTROLLER

Figure 7-F

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) Interface Analyser Test Set capable of displaying the signals exchanged both ways via the
interface in ASCII or Hexadecimal form.

(b) NCS/LES simulator.

6 TEST PROCEDURE

a. Connect the simulator, the DCE, DTE and the Interface Test Set as shown in 4. Tune the
NCS/LES simulator and the MES to channel no. 1100010. Ensure that the MES message
memory is cleared (fully available).

b. Perform each step indicated below and record the full data sequences transmitted to and
received from the DCE;

Recommended Test Procedures (RTPs), Page: 206


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

b.1 Enter the NCS common channel frequencies to channel 8000, 8100, 8200 up to channel
14000;

b.2 Set the AOR as the preferred Ocean Region;

b.3 For SES only: Set the distress message to [TBD];

b.4 Select a LES (LES = [TBD]);

b.5 Select Destination = 1234567;

b.6 Select Telex Service;

b.7 Initiate a scan of NCS common channels;

b.8 Request a Performance Verification test;

b.9 Interrogate the DCE about:

. NCS common channels in memory;

. Preferred OR selected;

. Log-in status;

. For SES only: Distress Message;

. LES,Destination ID and Service selected;

b.10 Enquiry about the current TDM;

b.11 Transfer via the NCS/LES simulator three different test messages (To-Mobile) and after
completion, enquiry the DCE about messages not read;

b.12 Enquiry about the received messages' characteristics;

b.13 Retrieve the first received message;

b.14 Ask for the number of errored BB received;

b.15 Ask for the result of the last PV test (step b.8);

b.16 Ask for the Network Information data;

b.17 Prepare a 16K test message and transfer it to the DCE;

b.18 Initiate a From-Mobile message transfer (with the parameters selected during steps b.4
through b.6);

b.19 While transmitting, ask for the current channel being used;

b.20 While still transmitting, interrogate the DCE about the status of the message transfer and
initiate a forced clear;

b.21 For SES only: Initiate a Distress Alert (with the parameters selected during step b.3);

Recommended Test Procedures (RTPs), Page: 207


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

b.22 For SES only: Initiate a Test Distress Alert (with the parameters selected during step b.3);

b.23 Tune to NCS channel 9000 (since the NCS/LES simulator is still tuned to ch, 11000, the MES
will eventually revert to the original NCS channel);

b.24 Prepare a test message, transfer it to the DCE and abort the operation;

b.25 Log-out;

7 PASS/FAIL CRITERIA

The control codes exchanged between the DTE and DCE during steps b.1 through b.25 shall be
complying with the format given at SDM Volume 3, Part 2, Chapter 4.

All steps should be accomplished successfully.

Recommended Test Procedures (RTPs), Page: 208


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 9-A FAIL-SAFE AND MONITORING

1 PURPOSE OF THE TEST

The test shall verify that the MES will alert the operator and inhibit transmission under fault
conditions, as stated in SDM Volume 3, Part 2, Chapter 2, Section 9.1; and that the MES monitors and
updates the received Bulletin Board error rate as established in SDM Volume 3, Part 2, Chapter 2,
Section 9.2.

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

Temperature

4 TEST SET-UP

TEMPERATURE CHAMBER

NCS/LES
SIMULATOR COUPLER UP
CONVERTER MODULATOR

POWER
METER

CONTROLLER
DTE
GENERATOR

Figure 9-A

5 REQUIRED TEST EQUIPMENT AND FACILITIES

a. NCS/LES simulator, interfaced at L-band

b. Coupling network

c. Signal generator

d. Power meter

e. Temperature chamber

Recommended Test Procedures (RTPs), Page: 209


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6 TEST PROCEDURE

(a) Transmitter disable

Connect the MES to the NCS/LES simulator and a power meter through a suitable coupling network.
Disconnect and re-connect each board, module and connector (to the extent possible), verifying that
none of these conditions causes the MES to transmit.

(b) Unauthorized transmission

Inject a signal into the upconverter from an external source. The signal at the upconverter should be at
the normal level and frequency. Record the status of the failure condition indicator.

(c) RF switch

Note: Omit this test if an RF switch is not used in the MES. Disconnect the HPA output to the RF
switch, and use a low level signal to check continuity through the switch, from the HPA input to the
switch to the antenna port. Initiate a transmission. Disconnect the DC power supply from the switch
and verify that the HPA has been disconnected from the antenna port.

(d) Watchdog timer

While the MES is in standby mode, disconnect the software tickler time to the watchdog timer. Record
the time elapsed before the software is reset. Verify that no transmission occurs at any time. Repeat
the test with the MES initially transmitting a message and verify that the transmission ceases when the
software is reset.

(e) Self Monitoring (Bulletin Board Error Rate)

Initialise the MES and begin transmitting TDM frames with Bulletin Boards from the simulator.
Interrogate the DCE from the DTE and verify that a correct result (BBER) is received. Repeat,
simulating errors in the BBs from the simulator.

7 PASS/FAIL CRITERIA

The MES shall conform with SDM Volume 3, Part 2, Chapter 2, Sections 9.1 and 9.2.

Recommended Test Procedures (RTPs), Page: 210


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 9-B PERFORMANCE VERIFICATION & COMMISSIONING

1 PURPOSE OF THE TEST

This test shall verify that the MES correctly performs the Performance Verification and
Commissioning Tests as described in SDM Volume 3, Part 2, Chapter 2, Section 9.3 (and Volume 1,
Chapter 4, Section 10).

2 APPLICABILITY

All classes of MESs

3 ENVIRONMENTAL CONDITIONS

Normal ambient

4 TEST SET-UP

NCS/LES MES
SIMULATOR

DTE
CONTROLLER

Figure 9-B

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator

6 TEST PROCEDURE

(a) Send a Performance Verification test request from the MES to the NCS/LES simulator.
Verify that the request transmitted is correct.

(b) Send a test announcement from the NCS/LES simulator to the MES on the NCS common
channel.

(c) Verify that the MES transmits a valid assignment response to the simulator on the MES
signalling channel.

Recommended Test Procedures (RTPs), Page: 211


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(d) Send the "test pattern" message from the simulator to the MES on the LES TDM channel,
with one or more errors in the test message.

The test pattern below may be used.

FF83 DF17 3209 4ED1 E7CD 8A91 C6D5 C4C4

4021 184E 5586 F4DC 8A15 A7EC 92DF 9353

3018 CA34 BFA2 C759 678F BA0D 6DD8 2D7D

540A 5797 7039 D27A EA24 3385 ED9A 1DE0

Following the message, send a request for acknowledgement. Verify that the MES requests
the LES to re-transmit the message.

(e) Transmit the test pattern from the LES without errors, followed by a request for
acknowledgement.

(f) Verify that the MES sends an acknowledgement to the LES on the MES signalling channel.

(g) Transmit a logical channel clear from the simulator to the MES.

(h) Verify that the MES immediately transmits an assignment request to the LES on the MES
signalling channel.

(i) Send a logical Channel Assignment from the NCS/LES simulator on the LES TDM.

(j) Verify that the MES automatically transmits the message received from the LES (in (d)
above). The information field should be set to one byte and contain an eight bit representation
of the (current) bulletin board error rate.

(k) Transmit a re-transmission request (negative acknowledgement) from the NCS/LES simulator
on the LES-TDM.

(l) Verify that the MES repeats step (j).

(m) Transmit a positive acknowledgement from the NCS/LES simulator on the LES TDM.

(n) Send a test result packet from the LES (Volume 1, Chapter 4, Section 10.2.5). Verify that the
MES sends a test result acknowledgement packet and stores and displays the test results.

(o) Clear the call from the LES.

(p) Initiate a PVT at the NCS using a different test message (the test message should be 4 kbytes)
to that shown in (d). Verify that the message transferred in the From-Mobile direction is
identical to that sent in the To-Mobile direction and that the test is completed successfully.

(This test is also covered in detail in Test Item 6-A).

7 PASS/FAIL CRITERIA

The MES must operate according to the protocols defined in SDM Volume 3, Part 2, Chapter 2,
Section 9.3 and Volume 1, Chapter 4, Section 10. The test results shall be made available for the
operator.

Recommended Test Procedures (RTPs), Page: 212


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 10-A MAINS CONDUCTED SPURIOUS EMISSIONS

1 PURPOSE OF THE TEST

This test shall verify that the electromagnetic emissions from the MES along the mains power cable are
within the limits described in SDM Volume 3, Part 2, Chapter 2, Section 10.2, when measured
according to the recommendations of CISPR publication 16 (second edition, 1987).

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

4 TEST SET-UP

NCS/LES
SIMULATOR MES

DTE
SEE NOTE*

ARTIFICIAL
MAINS MEASURING
NETWORK DEVICE

CONTROLLER

MAINS EMI
NOTE*: Screened Cable not SHIELD
longer than 600mm. POWER

Figure 10-A

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator

(b) Artificial Mains Networks which comply with CISPR publication 16, clause 8.

(c) Measuring device such as quasi-peak measuring receivers which complies with CISPR
Publication 16, Section One (equivalent to British Standards Institution BS727, clause 4).

Examples of artificial mains networks (ref. CISPR 16, Appendix E.) are shown in figures 10-A/1 and
10-A/2.

Recommended Test Procedures (RTPs), Page: 213


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

REQUIRED TEST EQPT Test Item 10-A TO SES


(Measurements in Band A) SCREENED CABLE
NOT LONGER THAN 600mm

250 µH 50 µH 0.25 µF 50 ž

4 µF 8 µF
10 ž 5ž 1000 ž
TO MAINS
POWER
10 ž 5ž 1000 ž
4 µF 8 µF 0.25 µF

250 µH 50 µH TO 50 OHM
MEASURING
DEVICE
EMI SHIELD

Figure 10-A/1

REQUIRED TEST EQPT Test Item 10-A


(Measurements in Band B) TO SES
SCREENED CABLE
NOT LONGER THAN 600mm

L1 100 nF 100 ž 50 ž

C2 1000 ž
TO
MAINS ADD'L
POWER FILTER
1000 ž
C2

L1 TO 50 OHM
100 nF 100 ž
MEASURING
EMI DEVICE
SHIELD

Figure 10-A/2

Note: these networks are valid for all two-wire mains (DC or single-phase AC) supplies. Careful
attention must be paid to ensure proper shielding and earthing (grounding).

L,C and components of the additional filter (if necessary) must be chosen such that the impedance of
the network + mains + measuring device from each terminal of the MES to earth (ground) is 150 ± 20
ohms with a phase angle not exceeding 20 degrees for all frequencies in Band B.

6 TEST PROCEDURE

(a) Connect the equipment as shown, using an artificial network suitable for Band A
measurements. If a printer is used with the MES, the printer must be connected and be

Recommended Test Procedures (RTPs), Page: 214


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

operational. The MES, artificial network and measuring device must be connected to a
common earth (ground) plane.

(b) Band A measurements

While the MES is transmitting, tune the measuring device with a bandwidth of 200 Hz across
Band A (10kHz to 150kHz) and record the level of conducted spurious. Repeat with the MES
in receive mode and printing a message if a printer is used. Record the levels which were
measured. Repeat the test with the measuring apparatus connected to the other supply
conductor.

(c) Band B measurements

Replace the artificial network with a network suitable for Band B measurements. Repeat part
(b) with a bandwidth of 9kHz, tuning from 150kHz to 30MHz. Repeat the test with the
measuring apparatus connected to the other supply conductor.

(d) All results should be referred to the MES mains terminals.

7 PASS/FAIL CRITERIA

Within the limits shown in SDM Volume 3, Part 2, Chapter 2, figure 4-9.

Recommended Test Procedures (RTPs), Page: 215


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 11-A VIBRATION FREQUENCY RESPONSE

1 PURPOSE OF THE TEST

The test will check the mechanical response of the MES under vibration conditions: its main purpose
is to demonstrate that the mechanical design of the MES is suitable for use under conditions of
vibration up to those specified in the Technical Requirements Document (refer to SDM Volume 3, Part
2, Chapter 2, Section 11.2). Moreover frequencies of vibration at which mechanical resonance occurs
will be identified and recorded for subsequent use during performance tests under vibration.

2 APPLICABILITY

All classes of MESs; the test shall be separately performed on EME, IME, Printers and Keyboards(if
applicable) with the appropriate vibration conditions.

3 ENVIRONMENTAL CONDITIONS

Normal ambient conditions and vibration as specified.

4 TEST SET - UP

VIBRATION TABLE

NCS/LES
SIMULATOR MES

PLOTTER

TRANSDUCER

DTE

CONTROLLER

Figure 11-A

5 REQUIRED TEST EQUIPMENT

- Vibration Table capable of transmitting to the equipment under test vibration conditions as
specified in Table 1 below.

- Accelerometers in suitable number to be mounted on the most significant points of the


equipment capable to produce an electrical signal proportional to the induced acceleration.

- NCS/LES simulator.

Recommended Test Procedures (RTPs), Page: 216


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6 TEST PROCEDURE

Three mutually perpendicular major axes shall be defined for the equipment under test: for clarity, in
the following they will be called as X, Y, and Z-axis.

a) Install the EME on the vibration table to vibrate along the X-axis.

b) The equipment shall be turned on and vibrated with a swept vibration frequency: the sweep
rate shall be low enough to enable any resonance effects to be noted and investigated as
necessary and the amplitude of the vibration excitation appropriate for the type of equipment
being tested (refer to table 1).

c) Any vibration frequency at which resonance (*) occurs shall be recorded and a plot of the
vibration responses over the relevant frequency range should be produced.

d) At the end of the sweep, check the integrity of the equipment and inspect for any mechanical
damages; it shall remain operational and capable to meet the performance specifications as set
forth in the Technical Requirements Document. For this purpose, some simple functional
checks will suffice (eg a From-Mobile and a To-Mobile message transfer with the NCS/LES
simulator; having the message printed if the Printer is the equipment under test).

e) Repeat steps b) through d) for the Y-axis.

f) Repeat steps b) through d) for the Z-axis.

g) Repeat steps b) through f) for the IME.

h) Repeat steps b) through f) for the Printer(if applicable).

i) Repeat steps b) through f) for the Keyboard (if applicable).

(*) Resonant frequencies are assumed to be the vibration frequencies at which the amplification
factor is greater than (3); the amplification factor is defined as the ratio of the acceleration of
the equipment subject to a sinusoidal vibration excitation to the acceleration of the excitation
itself.

7 PASS/FAIL CRITERIA

The equipment under vibration testing shall not reveal any mechanical alterations and should be
capable to complete successfully the functional checks in steps d). Although there are no specified
limits for amplification factors at resonant frequencies, the Manufacturer is encouraged to damp the
response at those frequencies to the extent possible.

Recommended Test Procedures (RTPs), Page: 217


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

TABLE 1

EXTERNALLY MOUNTED EQUIPMENT

Frequency Range Level

2 - 10 Hz 2.54 mm peak constant amplitude

10 - 100 Hz 1.0 g acceleration

INTERNALLY MOUNTED EQUIPMENT

Frequency Range Level

2 - 15.8 Hz 1.00 mm peak constant amplitude

15.8 - 100 Hz 1.0 g acceleration

REDUCED SPECIFICATIONS (for printers only)

Frequency Range Level

2 - 13.6 Hz 0.4 mm peak amplitude

13.6 - 50 Hz 0.3 g acceleration

Recommended Test Procedures (RTPs), Page: 218


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 11-B RAIN TEST

1 PURPOSE OF THE TEST

The test shall demonstrate that the mechanical design of the Externally Mounted Equipment (EME) is
suitable for use under rain conditions and under such conditions the functions of the MES under test
are not adversely affected. Refer to SDM Volume 3, Part 2, Chapter 2, section 11.2

2 APPLICABILITY

All classes of MESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient conditions and simulated precipitation according to the procedure (see 6).

4 TEST SET-UP

NOZZLE

SPRAY
NCS/LESSIM
ULATOR
ANT

MES MES
EME IME

CONTROLLER

DTE

Figure 11-B

5 REQUIRED TEST EQUIPMENT

- Water supply capable of delivering up to 100 litres/min.

- Nozzle with internal diameter of 12.5 mm

- NCS/LES simulator.

6 TEST PROCEDURE

The procedure for conducting this test is also described in section 2.1.7 of this document,
Environmental Condition Tests, (D).

The test shall be carried out by spraying the equipment from all directions with a stream of water from
a nozzle; throughout the test the equipment shall be operating normally.

Recommended Test Procedures (RTPs), Page: 219


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

a) Install the MES equipment under test in a suitable location for the test.

b) The water pressure at the nozzle should be adjusted to achieve the specified delivery rate. The
water should rise freely for a vertical distance of approximately 8 metres above the nozzle.

c) Turn on the equipment and spray the EME from all practicable directions keeping the distance
from the nozzle to the EME at approximately 3 metres; keep on spraying for at least (30)
minutes.

d) Stop spraying and inspect the EME for ingress of water; remove the antenna and connect the
NCS/LES simulator to the MES under test.

e) Perform simple functional tests (eg To-Mobile and From-Mobile message transfers) and
record the results.

7 PASS/FAIL CRITERIA

Step d): the EME shall not reveal any water leaks which might affect the performance of the
equipment.

Step e): the functional test shall be successfully completed.

Recommended Test Procedures (RTPs), Page: 220


Section 2, Part 2: Phase 1 Tests for Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3. PHASE 1 TESTS FOR SHIP EARTH STATIONS

3.1 INTRODUCTION AND REQUIRED TESTS

3.1.1 GENERAL

This section describes the Phase I tests for an Inmarsat-C Ship Earth Station (SES), which is a Mobile Earth
Station designed specifically for maritime use.

The purpose of the Phase I tests is to demonstrate that all the relevant INMARSAT performance requirements
are satisfied over the range of environmental conditions in which the SES is designed to operate. This Section
outlines the minimum requirements of a Phase I test plan and presents test procedures and test data sheets which
can be used by the manufacturers in developing their own test plan.

The characteristics of an SES are generally the same as those of a Mobile Earth Station as described in Section 2
of this document. An SES must pass the general tests applicable to all MESs as described in Section 2 and in
addition must pass tests relating to the following functions:

(a) 2-digit prefixed code addressing for From-Mobile Safety messages,

(b) transmission of distress alerts,

(c) transmission of distress priority messages.

(d) Message Processing Requirements

An indication of reception of a valid distress alert acknowledgement from an LES following


transmission of an initial distress alert by the SES shall be provided.

additional information to be held in non-volatile memory concerning distress alert parameters.

(e) Performance Verification Testing

The PVT also includes a distress alert test. The SES operator will be prompted to activate a distress
alert within two minutes following receipt of the prompt.

(f) Additional environmental conditions.

Also note that in Section 2, a number of tests are qualified by the comment: "For SES only". Those tests are not
repeated here but are required for type approval.

(g) Annex A : Additional phase 1 tests for SOLAS SES`S for CN114 compliance.

3.1.2 REQUIRED TESTS

As a minimum, the functions and characteristics listed in Table 1 shall be tested with the indicated variations in
the environmental conditions.

For each test in Table 1, reference is made to the relevant technical requirement stated in SDM Volume 3, Part
2.

Recommended Test Procedures (RTPs), Page: 1


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.1.3 FUNCTIONAL CHECKS

In order to reliably check the signalling protocols for the SES under test and to shorten the time for testing, the
manufacturer shall use a test simulator (NCS/LES simulator) which can simulate the basic responses and signal
processing of an NCS and LES, and a channel simulator to simulate the RF environment in which the SES will
be used (signal impairments such as noise, fading, doppler, interferers etc).

The minimum functional characteristics and technical requirements for test simulators are presented in Section 7
of this document.

3.1.4 TESTS FOR EGC RECEPTION

When the SES model for which type approval is sought, is capable of receiving EGC messages (Class 2 or Class
3), the applicable tests for EGC receivers shall be performed and checks that the EGC reception does not
interfere with the normal Inmarsat-C operation (according to the Class definition) shall also be done.

The basic test requirements for EGC receivers are presented in Section 6 of this document.

3.1.5 TESTS PERFORMED BY ORIGINAL EQUIPMENT MANUFACTURERS

For some subsystems, the SES manufacturer may not be the original equipment manufacturer (OEM). In such
cases, the SES manufacturer may submit the test procedures and results of the OEM, rather than repeat all tests.
Use of OEM test procedures and results to satisfy the Phase I test requirements may suffice if the procedures
and the results are clearly adequate. The test procedures presented here are suggested as a suitable basis for the
relevant tests to be conducted by the OEM.

3.1.6 INPUT/OUTPUT DEVICES

In some cases the DTE might not be an integral part of the Internally Mounted Equipment (IME), being
connected via the DTE-DCE interface with characteristics as specified in SDM Volume 3, Part 2, Chapter 2,
Section 7.6. In this case, the DTE shall be tested under the applicable environmental conditions, for use with
SES models wishing to comply with the GMDSS requirements.

However, for this purpose, test procedures and results obtained previously in type approving a different SES
model could be provided on the condition that they relate to the same DTE model using the same interface.
INMARSAT may be satisfied with the documentation provided and require no further testing.

3.1.7 ENVIRONMENTAL CONDITIONS TESTS

Each test item is to be performed under the relevant limits of the environmental conditions variations, specified
by the manufacturers. In principle it is desirable to test the SES as a whole system under environmental
condition variations. However, since the environmental test facilities available to the SES manufacturers are
often limited, it is acceptable to perform the tests which require environmental conditions to be applied to both
Externally Mounted Equipment (EME) and the IME in two phases. Where in each phase, the EME and IME
shall be separately checked in turn with the appropriate conditions. A demonstration that the performance will
still remain within the specified limits, when the whole SES system is subject to the environmental conditions
variations, shall be provided.

In order to keep the duration of a test within reasonable limits, when more than one type of environmental
variations are required, the tests may be combined. Therefore it will be acceptable to perform a particular

Recommended Test Procedures (RTPs), Page: 2


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

performance test under two different types of environmental conditions at the same time (eg under high voltage
and high temperature together).

The test procedures outlined in this document indicate the acceptable combinations of environmental conditions.

The procedures presented below assume the environmental conditions limits as stated in SDM Volume 3, Part 2,
Chapter 5, Section 11.

A Procedures for Tests under Temperature and Humidity Variations.

A.0 Start of procedure (ambient conditions).

A.1 Place the equipment under test in the environmental test chamber(s) (temperature and
humidity).

A.2 Power-up the equipment at ambient.

A.3 Define the next Test Environment (TE) as TE1 (T=55°C for EME, T=45°C for IME) with a tr
= x *.

A.4 Change the environmental conditions from ambient TE0 to TE1 and leave the equipment at
these conditions for at least 3 hours or until thermal equilibrium has been attained.

A.5 Carry out the relevant test and record the results.

A.6 Bring the equipment to ambient TE0 in not less than one hour and leave it for at least 3 hours
or until thermal equilibrium has been attained.

A.7 Perform steps A.4 through A.6 with the next test environment as TE1 (T=40°C,RH=95%) and
tr = 3 hours.

A.8 Perform steps A.4 through A.6 with TE1 (T=-35°C for EME, T=0°C for IME) and tr = x *.

A.9 End of procedure.

The diagrams in fig.1 show schematically the test cycle.

TE0 is defined as the ambient conditions, i.e. T=20°-27°C and RH=45-75%.

tr is time it shall take to reach a specified condition (next test environment) from ambient.

* tr = x means at discretion of test engineer.

Recommended Test Procedures (RTPs), Page: 3


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

x >3 hr >1 hr

+55ÞC +55ÞC >3 hr >3 hr >1 hr


+45ÞC
+45ÞC
+40ÞC +40ÞC
95% RH >3 hr 95% RH

>3 hr
Ambient
>3 hr
0ÞC EME 0ÞC

IME
-35ÞC Test
-35ÞC
x >1 hr

Figure 1Temperature and Humidity Cycles

B Procedures for Tests Under Power Supply Variations.

B.0 Start of procedure.

B.1 Turn on the equipment at nominal power supply conditions.

B.2 Choose as new conditions P1 (V=1.1V0, f=1.06f0)

B.3 Vary the power supply conditions from P0 to P1 and leave the equipment in these conditions
for at least 5 mins.

B.4 Carry out the relevant test and record the results.

B.5 Return to the nominal power supply conditions P0.

B.6 Perform steps B.3 through B.5 with P1 (V=0.9V0, f=0.94f0).

B.7 Perform steps B.3 through B.5 with P1 (V=1.35Vdc) if applicable (battery-powered).

B.8 Perform steps B.3 through B.5 with P1 (V=0.8Vdc) if applicable (battery-powered).

B.9 End of procedure.

P0 is defined as the nominal power supply conditions, i.e. V=V0, f=f0 (and V=Vdc if applicable).

V0 and f0 are the nominal values of mains voltage and frequency respectively and Vdc is the nominal value of
the voltage of the battery (if present).

C Procedures for Tests under Vibration

Three mutually perpendicular major axes shall be defined for the equipment under test: for clarity, in the
following they will be called as X, Y and Z-axis (or, alternatively, in the test procedures they might be referred
to as "front-to-back","left-to-right" and "up-down" directions).

Recommended Test Procedures (RTPs), Page: 4


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The procedure for the test under vibration consists basically of two parts:

Procedure C.1

Investigation of mechanical response of the equipment and its resonant frequencies; this test needs to be
performed only once (for each major axis) during the Phase I test plan for the externally mounted equipment
(EME), the internally mounted equipment (IME) and the DTE (if applicable). This test is covered by Test Item
11-A.

C.1.0 Start of procedure.

C.1.1 Install the EME on the vibration table to vibrate along the X-axis.

C.1.2 The equipment shall be turned on and vibrated with a swept vibration frequency: the sweep
rate shall be low enough and the amplitude of the vibration excitation as convenient (e.g. 0.4
mm peak) to enable any resonance effects to be noted and investigated as necessary.

C.1.3 Any vibration frequency at which resonance (*) occurs shall be recorded and a plot of the
vibration response over the relevant frequency range should be provided.

C.1.4 At the end of the sweep, the equipment shall remain operational and virtually capable to meet
the performance specifications as set forth in the Technical Requirements Document.

C.1.5 Repeat steps C.1.2 to C.1.4 for the Y-axis.

C.1.6 Repeat steps C.1.2 to C.1.4 for the Z-axis.

C.1.7 Repeat steps C.1.1 to C.1.6 for the IME.

C.1.8 Repeat steps C.1.1 to C.1.6 for the DTE (if applicable).

C.1.9 End of procedure.

(*) Resonant frequencies are assumed to be the vibration frequencies at which the amplification factor, or
Q, is greater than 3; the amplification factor is defined as the ratio of the acceleration of the equipment subject
to a sinusoidal vibration excitation to the acceleration of the excitation itself.

For this test, the use of electrical vibration pickups mounted in the most significant points of the equipment
under test is recommended.

Procedure C.2

For each test item to be performed under vibration conditions, the procedure below shall be followed; in
principle, it should be desirable to test the SES as a whole system under vibration.

However, recognising the fact that usually the vibration test facilities available to the SES manufacturers are
limited, it will be acceptable to perform tests which require vibration conditions to be applied to both EME and
IME in two phases: where in each phase, the EME and IME shall be separately vibrated in turn with the
appropriate amplitude.

A demonstration that the performance will still remain within the specified limits when the whole SES system is
subject to vibration shall be provided.

The procedure below is also applicable to DTE performance testing.

Recommended Test Procedures (RTPs), Page: 5


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

C.2.0 Start of procedure.

C.2.1 Install the equipment under test on the vibration table(s) to vibrate along the X-axis.

C.2.2 Carry out the relevant test at each resonant frequency recorded during step C1.3 of procedure
1 for every vibration frequency sub-range: if no resonant frequencies have been found in a
sub-range, the test will be conducted at the highest frequency;

The frequency sub-ranges and the corresponding vibration amplitudes which shall be applied
are defined below. The vibration frequency, amplitude and test results shall be recorded.

C.2.2 (alternative) Carry out the relevant test using a random vibration with spectrum characteristics
specified below.

C.2.3 Repeat steps C.2.1 to C.2.2 for the Y-axis.

C.2.4 Repeat steps C.2.1 to C.2.2 for the Z-axis.

C.2.5 End of procedure.

Externally Mounted Equipment

Frequency Range Level

2 - 10 Hz 2.54 mm peak amplitude

10-100 Hz 1.0 g acceleration

Internally Mounted Equipment

Frequency Range Level

2 - 15.8 Hz 1.00 mm peak amplitude

15.8-100 Hz 1.0 g acceleration

Reduced Specifications (for printers only)

Frequency Range Level

2 - 13.6 Hz 0.4 mm peak amplitude

13.6-100 Hz 0.3 g acceleration

Random Vibration Spectrum (for performance tests)

Frequency Range Spectral Power Density

2 - 100 Hz [0.0005] g2/Hz

D Procedure for Rain and Spray Tests

The test shall be carried out by spraying the equipment from all practicable directions with

(a) a stream of water from a nozzle

Recommended Test Procedures (RTPs), Page: 6


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The test conditions should be the following:

- internal diameter of the nozzle: 12.5 mm;

- delivery rate: 100 l/min;

- water pressure at the nozzle: 100 kPa (1 bar)

(The pressure should be adjusted to achieve the specified delivery rate. At 100 kPa the water should
rise freely for a vertical distance of approximately 8 metres above the nozzle).

(b) a stream of solid droplets

Throughout the test the equipment shall be operating normally.

D.0 Start of procedure.

D.1 Install the SES equipment under test in a suitable location for the test.

D.2 Turn on the equipment and spray the EME from all practicable directions keeping the distance
from the nozzle to the EME at approximately 3 metres; carry out the relevant tests as required
(for at least 30 mins).

D.3 Stop spraying and inspect the EME for ingress of water.

D.4 End of procedure.

3.1.8 TEST SET-UP WITH NCS/LES SIMULATOR

For further information regarding NCS/LES simulator functions and facilities reference should be made to
Section 7 of this document; Test Simulators.

3.1.8.1 INITIALISATION

For each test item requiring an NCS/LES simulator, the following suggested procedure may be performed prior
to testing and it will be referred to in all applicable test procedures as the "Test set-up initialisation".

The parameters to be used for set-up purposes, unless otherwise stated in the procedure, may be as follows:

Notes: - all dimensionless figures in Hex notation unless otherwise indicated;

- xxxx indicates the frame counter;

- chks indicates the checksum (two bytes);

NCS

- at ch. 11080 (f = 1537.700 MHz received by the SES);

- BULLETIN BOARD as (whole packet)

7DFFxxxx5020206CFFFFFF03chks

- SIGNALLING CHANNEL DESCRIPTOR as (whole packet):

Recommended Test Procedures (RTPs), Page: 7


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6CF036AE00000000000000chks

SES

- NCS Common Channels = ch. 11080 as a minimum;

- Preferred Ocean Region = 1;

- Destination LES = 00710;

- Transmit Service = as required (10 = Telex SFU);

After having entered these data in the simulator (NCS) and SES, transmit NCS TDM frames on the Common
Channel, incrementing the frame number. After synchronisation, the SES should respond with a LOG-IN
REQUEST if in its non-volatile memory there is no data pertaining to the current Ocean Region; if this Normal
Initialisation has already been performed in another test, the log-in phase will be skipped.

Upon reception of the LOG-IN-REQUEST from the SES, the simulator (NCS) shall set the SIGNALLING
CHANNEL DESCRIPTOR to reflect a successful reception of the packet from the SES and transmit within 3
frames a LOG-IN ACKNOWLEDGEMENT.

SIGNALLING CHANNEL DESCRIPTOR:

Will depend on the slot chosen (in this particular case the Signalling Channel available is only one, at ch. 36AE,
corresponding to f = 1646.495 MHz transmitted by the SES); eg. if the LOG-IN REQUEST was in slot 5 then
the Descriptor is

6CF036AE00800000000000chks.

LOGIN ACKNOWLEDGEMENT:

At this point the test is ready to commence, as the SES has received all the required information about the
(simulated) network.

The network, as seen by the SES, may comprises for example 15 LESs in addition to the NCS, with different
operating characteristics:

LES 1 to LES 6

- IDs = 00110 to 00610 ;

- operating with a permanent TDM at chs.

1F40, 1F42, 232E, 27A4, 2AF8 and 2F14 (f =

1530.000, 1530.005, 1532.515, 1535.370, 1537.500 and

1540.130 MHz) on an operational satellite;

- 600 sym/s RTN link operation;

- in service and clear;

- all Services offered;

Recommended Test Procedures (RTPs), Page: 8


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

LES 7 to LES 10:

- IDs = 00710 to 01010;

- operating with a permanent TDM at chs.

32F2, 35AE, 36AE and 36B0 (f = 1542.605, 1544.355, 1544.995 and

1545.000 MHz) on an operational satellite

- 1200 sym/s RTN link operation;

- in service and clear;

- all Services offered;

LES 11:

- ID = 01110;

- operating with a demand-assigned TDM on an operational satellite;

- 600 sym/s RTN link operation;

- in service and clear;

- all Services offered;

LES 12:

- ID = 01210;

- operating with a demand-assigned TDM on an operational satellite;

- 1200 sym/s RTN link operation;

- in service and clear;

- all Services offered;

LES 13:

- ID = 01310;

- operating with a demand-assigned TDM on a spare satellite;

- out of service;

- in service and clear;

- all Services offered;

LES 14:

- ID = 01410;

- operating with a permanent TDM at ch. 232E (f = 1532.515 MHz) on a spare satellite;

Recommended Test Procedures (RTPs), Page: 9


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

- 600 sym/s RTN link operation;

- in service and congested;

- Distress alerting, Safetynet, Std. C traffic, Telex SF and Fleetnet only;

LES 15:

- ID = 01510;

- operating with a permanent TDM at ch. 27A4 (f = 1535.370 MHz) on a spare satellite;

- out of service

3.1.8.2 SET-UP OF CALLS USING NCS/LES SIMULATOR

a. For checking purposes, whenever a To-Mobile message transfer has to be initiated, the simulator will
send (in an NCS frame) an ANNOUNCEMENT related to a message of one line of QBF (56 characters) to be
transferred from LES 7.

b. From-Mobile message transfers

The SES will initiate the call by sending an ASSIGNMENT REQUEST to LES 7. Upon reception of the
ASSIGNMENT REQUEST from the SES, the simulator (LES) shall set the SIGNALLING CHANNEL
DESCRIPTOR to reflect a successful reception of the packet from the SES (eg. if the ASSIGNMENT
REQUEST was received in slot 10 then the Descriptor is 6CF036AE00002000000000chks ) and transmit within
7 frames a LOGICAL CHANNEL ASSIGNMENT.

This LOGICAL CHANNEL ASSIGNMENT is for an SES Message at ch. 11110, with a frame offset of 2
frames and slot no. 1; the test message from the SES is based on one frame (10368 symbols, interleaver size N =
4) transmission.

3.1.8.3 OTHER FUNCTIONS

a. Distress Alerting

Depending upon the destination LES selected, the SES will send the distress alert packet either to the LES
(permanent TDM) or the NCS (demand assigned TDM). Selection of parameters is not specified here.

The NCS/LES simulator should be able to respond with a Distress Alert Acknowledgement set up for the SES
ID.

b. Performance Verification Testing

For conducting PVTs the LES simulator should be set up with a suitable test message, ie the 512 bit test pattern
suggested in SDM Volume 3, Part 2, Chapter 5, section 6.3.3.1. It should also be possible to change this to a
longer message of approximately 4 kbytes.

c. EGC Messages

For testing the EGC functions of EGC receivers and Class 2 and 3 Inmarsat-C MESs, the simulator should be
set up to allow the assembly and insertion of single and double header EGC packets into frames.

Recommended Test Procedures (RTPs), Page: 10


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

d. Continuation Packets

It should be possible to fill TDM frames with dummy packets and/or EGC packets and force relevant signalling
and data packets to be spilt across frames as continuation packets A and B in order to verify that the SES will
detect and respond to such packets.

Recommended Test Procedures (RTPs), Page: 11


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

TABLE 1 : PHASE 1 TEST PLAN


Only items not tested in Section 1 are listed here

ITEM TEST DESIGNATION A T H P V SDM REF

5 TRANSMITTER PERFORMANCE TESTS

S5-C Signalling Channel Characteristics - Distress Priority X Chap 5: 5

S5-G 2-digit Special Access Codes - Sig channel character X Vol 4: Chapter 4

S5-H 2-digit Special Access Code - Msg channel character X Vol 4 : Chapter 5

7 MESSAGE PROCESSING

S7-B Display Devices X X X X X Chap 5: 7.3

S7-D SES Memory Capacity X X X Chap 5: 7.5

8 DISTRESS ALERTING FUNCTIONS

S8-A Distress Message Generator X Chap 5: 8.2

S8-B Distress Alert Activation X X X X X Chap 5: 8.3

9 TESTING FUNCTIONS

S9-B Performance Verification and Commissioning X Chap 5: 9.3

Notes:

A: ambient temperature

T: temperature

H: humidity

P: power

V: vibration

SDM REF: SDM Volume 3, Part 2, Chapter and section number

Recommended Test Procedures (RTPs), Page: 12


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

3.2 TEST PROCEDURES

ITEM S5-C SIGNALLING CHANNEL CHARACTERISTICS

1 PURPOSE

The test shall verify that distress priority packets transmitted on the SES signalling channel are
correctly formatted with Unique Word insertion, coding and scrambling as specified in SDM, Volume
3, Part 2, Chapter 5, Section 5, under different environmental conditions.

2 APPLICABILITY

All classes of SESs intending to meet the IMO GMDSS requirements.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

4 TEST SET-UP

ENVIRONMENTAL CHAMBER/ VIBRATION TABL

NCS/LES SIMULATOR
SES

DEMODULATOR

DATA
ANALYSER DTE

CONTROLLER

Figure S5-C

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Data analyser.

6 TEST PROCEDURE

(a) Connect the simulator and the SES as indicated in Figure S5-C. Initialise the set-up.

In steps (b) to (d) below record the signalling packet received by the NCS/LES simulator in
hexadecimal format both before and after unique word removal, descrambling and decoding
(i.e. two hexadecimal listings for each packet type). Indicate the transmission/reception bit

Recommended Test Procedures (RTPs), Page: 13


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

order (i.e. whether the least significant bit or the most significant bit of each displayed byte is
transmitted/received first).

(b) Cause the SES to send a Distress Alert packet to the NCS/LES simulator (maritime protocol).
Record the values assumed for:

- the SES ID;

- the LES ID;

on the test data sheet.

(c) Cause the SES to send a Distress Alert Test packet to the NCS/LES simulator (maritime
protocol). Record the values assumed for:

- the SES ID;

- the LES ID;

on the test data sheet.

(d) Cause the SES to send an Assignment Request packet with distress priority to the NCS/LES
simulator (store-and-forward message service). Record the values for:

- the SES ID;

- the LES ID;

- the message length;

- the destination type;

- the extension length;

- the address location;

- the destination extension;

- the telex destination code;

on the test data sheet.

7 PASS/FAIL CRITERIA

The data at the simulator demodulator output shall indicate that the packet content, checksum,
scrambling, coding and UW insertion are as specified in SDM Volume 4, Chapter 4 and SDM, Volume
3, Part 2, Chapter 5, Section 5 for each packet type.

Recommended Test Procedures (RTPs), Page: 14


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM S5-G 2-DIGIT SPECIAL ACCESS CODE ADDRESSING - SIGNALLING CHANNEL


CHARACTERISTICS

1 PURPOSE

The test shall verify all packets transmitted on the SES signalling channel, relating to 2-digit Special
Access codes, are correctly formatted as specified in SDM Volume 4, Chapter 4.

2 APPLICABILITY

All classes of SESs supporting Special Access Codes. Note that for GMDSS, 2-digit Special Access
codes are mandatory.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

4 TEST SET-UP

See Figure S5-C.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Data analyser.

6 TEST PROCEDURE

(a) Connect the simulator and the SES as indicated in Figure S5-C. Initialise the set-up.

In the steps below, record the signalling packet received by the NCS/LES simulator in
hexadecimal format after unique word removal, descrambling and decoding. Indicate the
transmission/reception bit order (i.e. whether the least significant bit or the most significant bit
of each displayed byte is transmitted/received first).

(b) Cause the SES to send an Assignment Request packet with distress priority to the NCS/LES
simulator. The protocol should be Special Access Code using a 2-digit Code. Record the
values for the following fields on the test data sheet:

- the SES ID (3 bytes);

- the LES ID (1 byte)

- the message length (1 byte; number of message packets);

- the destination type (3 bits; value 6);

- the extension length (2 bits; value 0);

- the address location (3 bits; value 0);

Recommended Test Procedures (RTPs), Page: 15


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

- the address (6 bytes; a 2-digit code in IA5. The remaining bytes are filled to the right
with 00H).

Note that no destination extension field is present for Special Access Code addressing.

(c) Repeat (b), but cause the SES to send an Assignment Request packet with normal priority to
the NCS/LES simulator.

(d) Verify that in all the above cases, the formatting of the fields is in accordance with the SDM.
Verify that the correct padding is used for short fields.

7 PASS/FAIL CRITERIA

The data at the simulator demodulator output shall indicate that the packet content, is as specified in
SDM Volume 4, Chapter 4 for each packet type.

Hex coded output should be provided as part of the test.

Recommended Test Procedures (RTPs), Page: 16


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM S5-H SPECIAL ACCESS CODE ADDRESSING - MESSAGE CHANNEL


CHARACTERISTICS

1 PURPOSE

The test shall verify that the transmitted data messages on the SES message channel are correctly
formatted in respect of packet content, as stated in SDM Volume 4, Chapter 5, under different
environmental conditions.

2 APPLICABILITY

All classes of SESs supporting Special Access Codes. Note that for GMDSS, 2-digit Special Access
codes are mandatory.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

4 TEST SET-UP

See Figure S5-C.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Data analyser.

6 TEST PROCEDURE

In the tests below record the message frames received by the NCS/LES simulator after preamble and
unique word removal, de-interleaving, decoding and descrambling have all been performed.

The message frames should be recorded in hexadecimal format and an indication of the
transmission/reception bit order should be given (i.e. whether the least significant bit or the most
significant bit of each displayed byte is transmitted/received first).

For International Alphabet 5 (if supported) the text content of the recovered frame(s) should be
displayed with odd parity.

Listings of original text messages should show the position of all non-printable characters (e.g. CR LF
= carriage return, linefeed) in the message.

(a) Connect the simulator and the SES as indicated in Figure S5-C and initialise the set-up.

(b) Cause the SES to transmit a message with the following characteristics:

protocol Special Access Code

message length < 120 characters ( = 1 packet);

message block size N 0;

character representation data;

Recommended Test Procedures (RTPs), Page: 17


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

and indicate on the test data sheet the values assumed for the class, confirmation request,
logical channel number, presentation, last count and additional information fields.

The Additional Information field of the first Message packet should be empty.

(c) Repeat test (b) for the Prefixed Store and Forward Protocol, if the protocol is supported.

(d) Verify that in all the above cases, the formatting of the fields is in accordance with the SDM.

7 PASS/FAIL CRITERIA

The data at the simulator demodulator output shall indicate that the packet content, is as specified in
SDM Volume 4, Chapter 5 for each packet type.

Hex coded output to be provided as part of test.

Recommended Test Procedures (RTPs), Page: 18


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM S7-B DISPLAY DEVICES

1 PURPOSE

To verify the status display, which may be in the DCE and/or DTE, also complies with SDM Volume
3, Part 2, Chapter 2, Section 7.3. An indication of reception of a valid distress alert acknowledgement
from an LES following transmission of an initial distress alert by the SES shall be provided.

2 APPLICABILITY

All classes of SESs intending to meet the IMO GMDSS requirements.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

Temperature

Humidity

Power supply

Vibration.

4 TEST SET-UP

NCS/LES SES SES


SIMULATOR EME IME

POWER
SUPPLY
DTE

CONTROLLER
TEMPERATURE CHAMBER/VIBRATION TABLE

Figure S7-B

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Power supplies in which voltage and/or frequency can be varied. One appropriate power
supply is required for each of the power interfaces which may be supplied with the SES (i.e.
AC mains, DC mains, battery).

(c) Environmental chamber (temperature and humidity)

Recommended Test Procedures (RTPs), Page: 19


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(d) Vibration table

6 TEST PROCEDURE

a) With NCS/LES simulator transmitting a TDM, check that the status display indicates frame
synchronization.

b) Turn off or remove the TDM, and check that the status display indicates loss of frame
synchronisation.

c) Initiate a transmission. Check that the status display indicates that the transmitter is on.

d) Initiate a distress alert from the SES. Send a distress alert acknowledgement from the
NCS/LES simulator. Check that the status display indicates that the distress call has been
acknowledged.

(e) Repeat steps (b) through (d) at high temperature/high power, humidity, low temperature/low
power and vibration.

7 PASS/FAIL CRITERIA

The SES indicates correctly when a distress message has been acknowledged.

Recommended Test Procedures (RTPs), Page: 20


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM S7-D SES MEMORY CAPACITY

1 PURPOSE OF THE TEST

The test shall demonstrate that

(a) the size of the memory allocated in the DCE for message storage and its management comply
with the requirements of SDM Volume 3, Part 2, Chapter 5, Section 7.5, and

(b) the characteristics of the non/volatile memory are retained under different environmental
conditions (refer to SDM Volume 3, Part 2, Chapter 5, section 7.5).

2 APPLICABILITY

All classes of SESs intending to meet the IMO GMDSS requirements.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

Temperature

Power supply

4 TEST SET-UP

TEMPERATURE CHAMBER

NCS/LES
SIMULATOR
SES

POWER
SUPPLY
DTE
CONTROLLER

Figure S7-D

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Temperature chamber

(c) Power supplies in which.voltage and/or frequency can be varied.

Recommended Test Procedures (RTPs), Page: 21


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6 TEST PROCEDURE

(a) Connect the simulators and the SES as shown in figure S7-D.

Tune the NCS/LES simulator and the SES to channel no. 1100010.

Ensure that the SES message memory is cleared (fully available).

(b) Initiate a To-Mobile message transfer from the NCS/LES simulator with a 32,768-byte
message to be transferred.

(c) After completion, display the received message and check its contents.

(d) Repeat step b. with 2048-byte test messages until the SES memory overflows.

(e) Check that an indication is received at the DTE and the latest message(s) (received after the
memory overflow) are displayed and/or printed.

(f) Set/up the SES with the following data:

[NCS channels, Ocean Region, preferred Ocean Region etc] and initiate a log-out request.

(g) By interrogating the DCE via the DTE, check the parameters entered in the SES non-volatile
memory and record them.

(h) Repeat step (g) under temperature extremes and main power variations.

(i) Turn off the SES and leave it in these conditions for 24 hours and repeat step (g).

7 PASS/FAIL CRITERIA

Step (c): the message shall be displayed with no errors.

Step (e): the latest messages shall be displayed error-free.

Steps(g): the data in the SES non-volatile memory shall be retained as entered during step (f).

Recommended Test Procedures (RTPs), Page: 22


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM S8-A DISTRESS MESSAGE GENERATOR

1 PURPOSE OF THE TEST

The test shall demonstrate that the distress message is assembled and transmitted by the SES according
to the format specified in SDM Volume 4, Chapter 4 with the contents specified in SDM Volume 3,
Part 2, Chapter 5, section 8.2.

2 APPLICABILITY

All classes of SESs intending to meet the IMO GMDSS requirements.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

NCS/LES SES
SIMULATOR

NAV EQPT
(OPT)

DTE

CONTROLLER

Figure S8-A

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Navigational equipment (optional).

6 TEST PROCEDURE

The abbreviation DM = Distress Message is used.

a. Connect the simulators and the SES as shown in S8-A. Tune the NCS/LES simulator and the
SES to channel no. 1100010.

b. Manually set the distress message to "test DM" = [TBD]

c. Initiate a distress alert transmission and record the packet received at the NCS/LES simulator.

Recommended Test Procedures (RTPs), Page: 23


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

d. Repeat step c. using in turn the following DMs: [TBD]

If facilities for automatic updating of the Distress Message from other navigational equipment are
included in the MES's design, continue performing steps e. through h.

e. Connect the navigation equipment to the SES under test.

f. Record the data displayed by the navigation eqpt. (eg position coordinates, course etc).

g. Initiate a distress alert transmission and record the packet received at the NCS/LES simulator.

h. Repeat step g. with the following data simulated at the navigation equipment :

Geographical Positions = [TBD]

7 PASS/FAIL CRITERIA

Steps c.:The packets, as received at the NCS/LES simulator shall correspond to the transmitted DMs
with the format specified in SDM Volume 4, Chapter 4.

Steps g.(only if the SES has built/in facilities for automatic updating of the DM from external
navigation eqpt.): Same as above.

Recommended Test Procedures (RTPs), Page: 24


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM S8-B DISTRESS ALERT ACTIVATION

1 PURPOSE OF THE TEST

The test will demonstrate that the distress alert activation function of the SES complies with the
requirements given in SDM Volume 3, Part 2, Chapter 5, Section 8.3 under different environmental
conditions. The fail/safe operation of a remote distress button facility (when provided) will also be
checked.

2 APPLICABILITY

All classes of SESs intending to meet the IMO GMDSS requirements.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

Temperature

Humidity

Power supply

Vibration.

4 TEST SET-UP

ENVIRONMENTAL CHAMBER/VIBRATION TABLE

NCS/LES
SIMULATOR
SES

POWER
REMOTE SUPPLY DTE
CONTROLLER DISTRESS
(OPT)

Figure S8-B

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Environmental chamber (temperature and humidity)

(c) Power supplies in which....

Recommended Test Procedures (RTPs), Page: 25


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(d) Vibration table

6 TEST PROCEDURE

The abbreviation DM = Distress Message is used.

a. Connect the simulators and the SES as shown in Fig. S8-B. Tune the NCS/LES simulator and
the SES to channel no. 1100010.

b. Initiate a From-Mobile message transfer.

c. Manually set the distress message DM for test = [TBD]

d. Whilst the message is being transferred, initiate a distress alert transmission and record the
packets received at the NCS/LES simulator.

e. Repeat step d. during reception of a To-Mobile message.

f. If a remote distress button facility is provided, repeat steps b. through e. initiating the distress
alert transmission from the remote distress button.

g. Repeat steps b. through f. at high temperature/high power, humidity, low temperature/low


power and vibration.

If a remote distress button facility is provided, continue with steps h. and i.

h. Short-circuit the cable connecting the remote button to the SES and record the packets (if any)
received by the NCS/LES simulator.

i. Open-circuit the cable connecting the remote button to the SES and record the packets (if any)
received by the NCS/LES simulator.

7 PASS/FAIL CRITERIA

Steps d. and e.: The existing call should be cleared and the distress alert message successfully
received at the NCS/LES simulator.

Steps h. and i.: (only if the SES has a built/in facility for a remote distress button): No packets
should have been originated by the SES.

Recommended Test Procedures (RTPs), Page: 26


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM S9-B PERFORMANCE VERIFICATION & COMMISSIONING

1 PURPOSE OF THE TEST

This test shall verify that the SES correctly performs the Performance Verification and Commissioning
Tests as described in SDM Volume 3, Part 2, Chapter 5, Section 9.3 (and Volume 1, Chapter 4, Section
10).

The PVT also includes a distress alert test. The SES operator will be prompted to activate a distress
alert within two minutes following receipt of the prompt.

If the SES operator fails to initiate the distress alert test, the SES shall automatically transmit the
distress alert packet 120 seconds after receiving the distress test request packet from the LES. The
distress alert test packet shall indicate if it was automatically or manually activated.

2 APPLICABILITY

All classes of SESs intending to meet the IMO GMDSS requirements.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

4 TEST SET-UP

NCS/LES SES
SIMULATOR

DTE
CONTROLLER

Figure S9-B

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator

6 TEST PROCEDURE

(a) Send a Performance Verification test request from the SES to the NCS/LES simulator. Verify
that the request transmitted is correct.

Recommended Test Procedures (RTPs), Page: 27


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(b) Send a test announcement from the NCS/LES simulator to the SES on the NCS common
channel.

(c) Verify that the SES transmits a valid assignment response to the simulator on the SES
signalling channel.

(d) Send the "test pattern" message from the simulator to the SES on the LES TDM channel, with
one or more errors in the test message.

The test pattern below may be used.

FF83 DF17 3209 4ED1 E7CD 8A91 C6D5 C4C4

4021 184E 5586 F4DC 8A15 A7EC 92DF 9353

3018 CA34 BFA2 C759 678F BA0D 6DD8 2D7D

540A 5797 7039 D27A EA24 3385 ED9A 1DE0

Following the message, send a request for acknowledgement. Verify that the SES requests the
LES to re-transmit the message.

(e) Transmit the test pattern from the LES without errors, followed by a request for
acknowledgement.

(f) Verify that the SES sends an acknowledgement to the LES on the SES signalling channel.

(g) Transmit a logical channel clear from the simulator to the SES.

(h) Verify that the SES immediately transmits an assignment request to the LES on the SES
signalling channel.

(i) Send a logical Channel Assignment from the NCS/LES simulator on the LES TDM.

(j) Verify that the SES automatically transmits the message received from the LES (in (d) above).
The information field should be set to one byte and contain an eight bit representation of the
(current) bulletin board error rate.

(k) Transmit a re-transmission request (negative acknowledgement) from the NCS/LES simulator
on the LES-TDM.

(l) Verify that the SES repeats step (j).

(m) Transmit a positive acknowledgement from the NCS/LES simulator on the LES TDM,
followed by a distress test request.

(n) Verify that the SES displays a message requesting the operator to initiate a distress alert
within a certain time.

(o) Transmit a distress alert from the SES and verify that a distress alert test is sent to the LES.

(p) Send a test result packet from the LES (Volume 1, Chapter 4, Section 10.2.5). Verify that the
SES sends a test result acknowledgement packet and stores and displays the test results.

(q) Clear the call from the LES.

Recommended Test Procedures (RTPs), Page: 28


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(r) Initiate a PVT at the NCS using a different test message (the test message should be 4 kbytes)
to that shown in d. Verify that the message transferred in the From-Mobile direction is
identical to that sent in the To-Mobile direction and that the test is completed successfully.

7 PASS/FAIL CRITERIA

The SES must operate according to the protocols defined in SDM Volume 3, Part 2, Chapter 5, Section
9.3 and Volume 1, Chapter 4, Section 10. The test results shall be made available for the operator.

Recommended Test Procedures (RTPs), Page: 29


Section 3: Phase 1 Tests for Ship Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4. PHASE 1 TESTS FOR LAND MOBILE EARTH STATIONS

4.1 INTRODUCTION AND REQUIRED TESTS

4.1.1 GENERAL

The purpose of these tests is to demonstrate that all the relevant INMARSAT performance requirements in
Volume 3, Part 2, Chapter 6 of the SDM are satisfied by Land Mobile Earth Stations, over the full range of
environmental conditions in which they are designed to operate. This Section outlines the minimum
requirements of a test plan for both Phase I and Phase II tests. The test procedures and test data sheets presented
here can be used by manufacturers in developing their detailed test plans.

4.1.2 REQUIRED TESTS

As a minimum, the functions and characteristics listed in Table 1 for Land Mobile Earth Stations, shall be
tested with the indicated variations in environmental conditions. Each test procedure for the tests listed in Table
1 makes reference to the relevant requirements in Volume 3, Part 2, Chapter 6 of the SDM.

4.1.3 FUNCTIONAL CHECKS

The manufacturer shall use a test simulator (NCS/LES simulator) and an RF simulator to verify the correct
operation of LMES. The former shall be capable of simulating the basic responses and signal processing of an
NCS and LES, and the latter shall simulate the RF environment in which the LMES will be used.

4.1.4 TESTS FOR EGC RECEPTION

When the LMES models for which type approval are sought, are capable of receiving EGC messages (Class 2
or Class 3), the applicable tests for EGC receivers shall be made and checks that the EGC reception does not
interfere with the normal INMARSAT-C operation (according to the Class definition) shall also be made.

EGC function tests are limited to FleetNETTM only, " General Call" and "INMARSAT System message"
receptions according to the requirements in Volume 3, Part 2, Chapter 6 of the SDM. The basic test
requirements for LMES EGC receivers are presented in Section 6 of this document. The relevant tests shall be
made under the environmental conditions for the LMES.

4.1.5 TESTS BY ORIGINAL EQUIPMENT MANUFACTURERS

For some subsystems, the LMES manufacturer may not be the original manufacturer (OEM). In such cases, the
manufacturer may elect to submit the test procedures and results of the OEM, rather than repeat all tests. Use of
OEM test procedures and results to satisfy the LMES test requirements may suffice if the procedures and results
are clearly adequate. The test procedures presented here are suggested as a suitable basis for the relevant tests
to be conducted by the OEM.

Recommended Test Procedures (RTPs), Page: 1


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.1.6 ENVIRONMENTAL CONDITIONS TESTS

Each test item is to be performed under the relevant limits of the environmental conditions variations, specified
by the manufacturers. In principle it is desirable to test the LMES as a whole system under environmental
condition variations. However, since the environmental test facilities available to the manufacturers are often
limited, it is acceptable to perform the tests which require environmental conditions to be applied to both
Externally Mounted Equipment (EME) and the IME in two phases. Where in each phase, the EME and IME
shall be separately checked in turn with the appropriate conditions. A demonstration that the performance will
still remain within the specified limits, when the whole LMES system is subject to the environmental conditions
variations, shall be provided.

In order to keep the duration of a test within reasonable limits, when more than one type of environmental
variations is required, the tests may be combined. It will be acceptable to perform a particular performance test
under two different types of environmental conditions at the same time (eg under high voltage and high
temperature together).

The test procedures outlined in this document indicate the acceptable combinations of environmental conditions.

4.1.6.1 TEST PROCEDURES FOR LAND MOBILE EARTH STATIONS

The procedures presented below assume the environmental conditions limits as stated in Volume 3, Part 2,
Chapter 6, Section 11 of the SDM.

A Procedures for Tests under Temperature and Humidity Variations.

A.0 Start of procedure (ambient conditions).

A.1 Place the equipment under test in the environmental test chamber(s) (temperature and
humidity).

A.2 Power-up the equipment at ambient.

A.3 Define the next Test Environment (TE) as TE1 (T=50°C for EME, T=55°C for IME) with a tr
= x *.

A.4 Change the environmental conditions from ambient TE0 to TE1 and leave the equipment at
these conditions for at least 3 hours or until thermal equilibrium has been attained.

A.5 Carry out the relevant test and record the results.

A.6 Bring the equipment to ambient TE0 in not less than one hour and leave it for at least 3 hours
or until thermal equilibrium has been attained.

A.7 Perform steps A.4 through A.6 with the next test environment as TE1 (T=40°C,RH=95%) and
tr = 3 hours.

A.8 Perform steps A.4 through A.6 with TE1 (T=-25°C for both EME and IME) and tr = x *.

A.9 Perform steps A.4 and A.6 with TE1 ( T=-40°C for both EME and IME) and tr = x *, and
then step A.5.

A.10 Perform steps A.4 and A.6 with TE1 ( T=80°C for both EME and IME) and tr = x *, and
then step A.5.
Recommended Test Procedures (RTPs), Page: 2
Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

A.11 End of procedure.

The diagrams in fig.1A show schematically the test cycle.

TE0 is defined as the ambient conditions, i.e. T=20°-27°C and RH=45-75%.

tr is time it shall take to reach a specified condition (next test environment) from ambient.

* tr = x means at discretion of test engineer.

x >3 hr >1 hr

+55ÞC +55ÞC >3 hr >3 hr >1 hr


+50ÞC
+50ÞC

+40ÞC95 >3 hr
% RH +40ÞC9
5% RH >3 hr
Ambient

0ÞC EME
-25ÞC
IME
-35ÞC Test
x >3 hr >1 hr

Figure 1A Temperature and Humidity Cycles

B Procedures for Tests Under Power Supply Variations.

B.0 Start of procedure.

B.1 Turn on the equipment at nominal power supply conditions.

B.2 Choose as new conditions P1 (V=1.3Vdc)

B.3 Vary the power supply conditions from P0 to P1 and leave the equipment in these conditions
for at least 5 mins.

B.4 Carry out the relevant test and record the results.

B.5 Return to the nominal power supply conditions P0.

B.6 Perform steps B.3 through B.5 with P1 (V=0.9Vdc).

B.9 End of procedure.

P0 is defined as the nominal power supply conditions.

Vdc is the nominal value of the voltage of the battery .

C Procedures for Tests under Vibration

Recommended Test Procedures (RTPs), Page: 3


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Three mutually perpendicular major axes shall be defined for the equipment under test: for clarity, in the
following they will be called as X, Y and Z-axis (or, alternatively, in the test procedures they might be referred
to as "front-to-back","left-to-right" and "up-down" directions).

For each test item to be performed under vibration conditions, the procedure below shall be followed; in
principle, it should be desirable to test the LMES as a whole system under vibration.

However, recognising the fact that usually the vibration test facilities available to the LMES manufacturers are
limited, it will be acceptable to perform tests which require vibration conditions to be applied to both EME and
IME in two phases: where in each phase, the EME and IME shall be separately vibrated in turn with the
appropriate amplitude.

A demonstration that the performance will still remain within the specified limits when the whole LMES system
is subject to vibration shall be provided.

The procedure below is also applicable to DTE performance testing.

Procedure

C.2.0 Start of procedure.

C.2.1 Install the equipment under test on the vibration table(s) to vibrate along the X-axis.

C.2.2 Carry out the relevant test using a random vibration with spectrum characteristics specified
below.

C.2.3 Repeat steps C.2.1 to C.2.2 for the Y-axis.

C.2.4 Repeat steps C.2.1 to C.2.2 for the Z-axis.

C.2.5 End of procedure.

Random Vibration Spectrum *

(for performance tests)

Frequency Range Spectral Power Density

5 - 20 Hz [0.005] g2/Hz

20 - 150 Hz -3dB/oct.

[0.5 g rms]

(for survival tests)

Frequency Range Spectral Power Density

5 - 20 Hz [0.05] g2/Hz

20 - 150 Hz -3 dB/oct.

[1.7 g rms]

Note:

Recommended Test Procedures (RTPs), Page: 4


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The random vibration testing is strongly recommended. However, consideration will be given to changing these
vibration conditions if the manufactures have no random vibrating tables. An acceptable condition is given
below:

(for performance tests)

Frequency Range Level

5 - 20 Hz [0.8 mm] peak amplitude

20 - 150 Hz [1.3 g] peak acceleration

(for survival tests)

Frequency Range Level

5 - 20 Hz [2.7 mm] peak amplitude

20 - 150 Hz [4.3 g] peak acceleration

D Procedure for Mechanical Shock tests (survival tests)

D.0 Start of procedure.

D.1 Place the equipment under test on the table.

D.2 3 shocks* in each of 3 mutually perpendicular axes, a total of 18 shocks shall be

performed.

D.3 End of procedure.

* Half sinewave shock with a peak of 20g and a duration of 11 ms.

E Procedure for Rain Tests

The test shall be carried out by spraying the equipment from all practicable directions with a stream of water
from a nozzle; throughout the test the equipment shall be operating normally.

The test conditions should be the following:

5 cm/hour, droplet size 0.5 to 4.5 mm.

Procedure

E.0 Start of procedure.

E.1 Install the LMES equipment under test in a suitable location for the test.

E.2 Turn on the equipment and spray the EME from all practicable directions keeping the distance
from the nozzle to the EME at approximately 3 metres; carry out the relevant tests as required
(for at least 30 mins).

E.3 Stop spraying and inspect the EME for ingress of water.

E.4 End of procedure.

Recommended Test Procedures (RTPs), Page: 5


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.1.7 TEST SET-UP WITH NCS/LES SIMULATOR

For further information regarding NCS/LES simulator functions and facilities reference should be made to
Section 7 of this document, Test Simulators.

4.1.7.1 Initialisation

For each test item requiring an NCS/LES simulator, the following suggested procedure may be performed prior
to testing and it will be referred to in all applicable test procedures as the "Test set-up initialisation".

The parameters to be used for set-up purposes, unless otherwise stated in the procedure, may be as follows:

Notes: - all dimensionless figures in Hex notation unless otherwise indicated;

- xxxx indicates the frame counter;

- chks indicates the checksum (two bytes);

NCS

- at ch. 11080 (f = 1537.700 MHz received by the LMES or LPES);

- BULLETIN BOARD as (whole packet)

7DFFxxxx5020206CFFFFFF03chks

- SIGNALLING CHANNEL DESCRIPTOR as (whole packet):

6CF036AE00000000000000chks

LMES

- NCS Common Channels = ch. 11080 as a minimum;

- Preferred Ocean Region = 1;

- Destination LES = 10710;

- Transmit Service = as required (10 = Telex SFU);

After having entered these data in the simulator (NCS) and LMES, transmit NCS TDM frames on the Common
Channel, incrementing the frame number. After synchronisation, the LMES should respond with a LOG-IN
REQUEST if there is no data pertaining to the current Ocean Region in its non-volatile memory. If this Normal
Initialisation has already been performed in another test, the log-in phase will be skipped.

Upon reception of the LOG-IN-REQUEST from the LMES, the simulator (NCS) shall set the SIGNALLING
CHANNEL DESCRIPTOR to reflect a successful reception of the packet from the LMES and transmit within 3
frames a LOG-IN ACKNOWLEDGEMENT.

SIGNALLING CHANNEL DESCRIPTOR:

Will depend on the slot chosen (in this particular case the Signalling Channel available is only one, at ch. 36AE,
corresponding to f = 1646.495 MHz transmitted by the LMES). E.g. if the LOG-IN REQUEST was in slot 5
then the Descriptor is

Recommended Test Procedures (RTPs), Page: 6


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6CF036AE00800000000000chks.

LOGIN ACKNOWLEDGEMENT:

At this point the test is ready to start, as the LMES has received all the required information about the
(simulated) network.

The network, as seen by the LMES may, for example, comprise 15 LESs in addition to the NCS, with different
operating characteristics:

LES 1 to LES 6

- IDs = 00110 to 00610;

- operating with a permanent TDM at chs.

1F40, 1F42, 232E, 27A4, 2AF8 and 2F14 (f =

1530.000, 1530.005, 1532.515, 1535.370, 1537.500 and

1540.130 MHz) on an operational satellite;

- 600 sym/s RTN link operation;

- in service and clear;

- all Services offered;

LES 7 to LES 10:

- IDs = 00710 to 01010;

- operating with a permanent TDM at chs.

32F2, 35AE, 36AE and 36B0 (f = 1542.605, 1544.355, 1544.995 and

1545.000 MHz) on an operational satellite

- 1200 sym/s RTN link operation;

- in service and clear;

- all Services offered;

LES 11:

- ID = 01110;

- operating with a demand-assigned TDM on an operational satellite;

- 600 sym/s RTN link operation;

- in service and clear;

Recommended Test Procedures (RTPs), Page: 7


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

- all Services offered;

LES 12:

- ID = 01210;

- operating with a demand-assigned TDM on an operational satellite;

- 1200 sym/s RTN link operation;

- in service and clear;

- all Services offered;

LES 13:

- ID = 01310;

- operating with a demand-assigned TDM on a spare satellite;

- out of service;

- in service and clear;

- all Services offered;

LES 14:

- ID = 01410;

- operating with a permanent TDM at ch. 232E (f = 1532.515 MHz) on a spare satellite;

- 600 sym/s RTN link operation;

- in service and congested;

- Distress alerting, Safetynet, Std. C traffic, Telex SF and Fleetnet only;

LES 15:

- ID = 01510;

- operating with a permanent TDM at ch. 27A4 (f = 1535.370 MHz) on a spare satellite;

- out of service

4.1.7.2 Set-up of calls using NCS/LES simulator

a. For checking purposes, whenever a To-Mobile message transfer has to be initiated, the simulator will
send (in an NCS frame) an ANNOUNCEMENT related to a message of one line of QBF (56
characters) to be transferred from LES 7.

b. From-Mobile message transfers

Recommended Test Procedures (RTPs), Page: 8


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The LMES will initiate the call by sending an ASSIGNMENT REQUEST to LES 7. Upon reception
of the ASSIGNMENT REQUEST from the LMES, the simulator (LES) shall set the SIGNALLING
CHANNEL DESCRIPTOR to reflect a successful reception of the packet from the LMES (eg. if the
ASSIGNMENT REQUEST was received in slot 10 then the Descriptor is
6CF036AE00002000000000chks ) and transmit within 7 frames a LOGICAL CHANNEL
ASSIGNMENT.

This LOGICAL CHANNEL ASSIGNMENT is for an LMES Message at ch. 11110, with a frame
offset of 2 frames and slot no. 1; the test message from the MES is based on one frame (10368
symbols, interleaver size N = 4) transmission.

4.1.7.3 Other functions

a. Land Mobile Alerting

The relevant bits in the "LES services" field of the bulletin board and Signalling Channel
Descriptors,of the LES and NCS simulators should be alterable for testing this function. It should be
possible to confirm that Land Mobile Alert packets are sent from the LMESs in the correct format.

The NCS/LES simulator should be able to respond with a Land Mobile Alert Acknowledgement set up
for the LMES ID. The acknowledgement is the same as the land mobile alert acknowledgement.

b. Performance Verification Testing

For conducting PVTs the LES simulator should be set up with a suitable test message, ie the 512 bit
test pattern suggested in Volume 3, Part 1, Chapter 2, section 6.3.3.1 of the SDM. It should also be
possible to change this to a longer message of approximately 4 kbytes.

Also, LES simulator should send a Test Alert Acknowledgement to the LMES during PVT.

c. EGC Messages

For testing the EGC functions of EGC receivers and Class 2 and 3 INMARSAT-C LMESs, the
simulator should be set up to allow the assembly and insertion of single and double header EGC
packets into frames.

d. Continuation Packets

It should be possible to fill TDM frames with dummy packets and/or EGC packets and force relevant
signalling and data packets to be spilt across frames as continuation packets A and B in order to verify
that the LMES will detect and respond to such packets.

Recommended Test Procedures (RTPs), Page: 9


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

TABLE 1: PHASE 1 TEST PLAN FOR LMES

In this table tests prefixed with L are new or modified tests described in this section. All other tests are exactly
as described in section 2.

ITEM TEST DESIGNATION A T H P V SDM REF

1 ANTENNA TESTS

L1-A Gain Profile X 3.2*, 3.3.1*, 3.4.1*

1-B Polarisation and Axial Ratio X 3.2.2, 3.2.3

2 RECEIVING SYSTEM TESTS

2-A Noise Temperature X 3.3.1

L2-B G/T Calculations 3.3.1*

2-C Tuning X X 3.3.4, 6.3.1

2-D Selectivity X X X 4.3

3 TRANSMITTING SYSTEM TESTS

3-A Output Power and Frequency Response X X X X 3.4.1*, 3.4.9

L3-B EIRP Calculations 3.4.1*

3-C Transmitted Spectrum X 3.4.2

L3-D Transmitter Off Power Level X X X X 3.4.3*

L3-E Spurious Outputs X X X X 3.4.4*

3-F Harmonics Outputs X X 3.4.5

3-G Phase Noise X X X 3.4.6*

3-H Tuning X X 3.4.7

3-I Frequency Accuracy and Stability X X X X 3.4.8

4 RECEIVER PERFORMANCE TESTS

L4-A Packet Error Rate X X X X X 3.3.3*, 4.4, 4.5

L4-B Packet Error Rate/Short Term Blockage X X X X X 4.7*

L4-C Carrier and Frame Acquisition X X X X X 4.4*, 4.6*

L4-D Carrier Acquisition/Long Term Blockage X X X X X 4.7*

Recommended Test Procedures (RTPs), Page: 10


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM TEST DESIGNATION A T H P V SDM REF

5 TRANSMITTER PERFORMANCE TESTS

5-A Modulation Characteristics X X X 5.1

5-B First Generation Operation X 5.2

L5-C Signalling Channel Characteristics X 5.3*

5-D Message Channel Characteristics X 5.4

6 ACCESS CONTROL TESTS

6-A General Access Control X 6.1

L6-A/1 Land Mobile Alert Access Control X 8*

L6-A/2 PVT Access Control X 8*

6-B TDMA Synchronization X X 6.2.1

6-C Random Access X 6.2.2

L6-D Common Channel Selection X 6.3*

L6-E Region Registration Procedures X 6.5*

6-F Idle and Busy Conditions X 6.6

7 MESSAGE PROCESSING

7-A Character Codes X 7.2

7-B Display Devices X X X X X 7.3

7-C Keyboard X X X X X 7.4

7-D MES Memory Capacity X X X 7.5

7-E DCE/DTE Interface Characteristics X X X 7.6.1 and Chap. 4 Sect.3

7-F Control Codes X 7.6.3 and Chap. 4

8 ALERTING FUNCTIONS

L8-A Alert Generator X 8.2*

L8-B Alert Activation X X X X X 8.3*

Recommended Test Procedures (RTPs), Page: 11


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM TEST DESIGNATION A T H P V SDM REF

9 TESTING FUNCTIONS

9-A Fail-Safe and Monitoring X X 9.1, 9.2

L9-B Performance Verification and Commissioning X 9.3*

L10 ELECTROMAGNETIC COMPATIBILITY

10-A Mains Conducted Spurious Emissions X 10.2

11 PHYSICAL CHARACTERISTICS TESTS

L11-A Vibration Frequency Response X 11.2*

L11-B Shock Test X 11.2*

L11-C Rain Test X 11.2*

Notes: A: ambient temperature

T: temperature

H: humidity

P: power

V: vibration

SDM REF: SDM Volume 3, Part 2 Chapter 2 section

* SDM Volume 3, Part 2, Chapter 6 section

Recommended Test Procedures (RTPs), Page: 12


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4.2 TEST PROCEDURES

ITEM L1-A ANTENNA GAIN PROFILE

1 PURPOSE

The purpose of the test is to measure the antenna gain profile in elevation and azimuth over the
required frequency ranges. The results are to be used in Test Item L2-B and L3-B to show that the G/T
and EIRP requirements are met. Refer to Volume 3, Part 2, Chapter 6, Section 3.3.1 and 3.4.1 of the
SDM.

2 APPLICABILITY

All classes of LMESs

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

See Test Item 1-A.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item 1-A.

6 TEST PROCEDURE

See Test Item 1-A.

7 PASS/FAIL CRITERIA

The results will be used together with the test results from Test Item L2-A in the G/T calculations (Test
Item L2-B) and Test Item L3-A in the EIRP calculations (refer to Test Item L3-B) to demonstrate that
the G/T and EIRP will stay within the specified limits for the LMES.

Recommended Test Procedures (RTPs), Page: 13


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM L2-B G/T CALCULATIONS

1 PURPOSE

The calculations shall demonstrate that the G/T of the LMES complies with the requirements stated in
Volume 3, Part 2, Chapter 6, Section 3.3.1 of the SDM

2 APPLICABILITY

All classes of LMESs.

3 PROCEDURE

See Test Item 2-B, where the results of Test Items L1-A and L2-A are used in the calculations.

4 PASS/FAIL CRITERIA

For the LMES, the antenna G/T shall be greater than the superimposed mask for any elevation angle
between 0o and 90o and any azimuth direction.

Models of LMES found to exhibit marginal G/T performance may still be acceptable if the
manufacturer is able to demonstrate that the demodulator/decoder performance is such that the
equipment is able to meet the output performance (Packet Error Rate) of Volume 3, Part 2, Chapter 2,
Section 4.5 with all relevant signal impairments.

Recommended Test Procedures (RTPs), Page: 14


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM L3-B EIRP CALCULATIONS

1 PURPOSE

The calculations shall demonstrate that the maximum and minimum EIRP, calculated from results of
Test Items L1-A and L3-A, complies with the requirements of Volume 3, Part 2, Chapter 6, Section
3.4.1.

2 APPLICABILITY

All classes of LMESs.

3 PROCEDURE

See Test Item 3-B.

4 PASS/FAIL CRITERIA

The plots resulting from these calculations must fall within the limits (an elevation angle between 0°
and 90°) of Volume 3, Part 2, Chapter 2, Figure 4-3.

Recommended Test Procedures (RTPs), Page: 15


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM L3-D TRANSMITTER OFF POWER LEVEL

1 PURPOSE

The test shall verify that the output power of the transmitter, when in a non-operative state, complies
with the requirements of Volume 3, Part 2, Chapter 6, Section 3.4.3, and to check for "fail-safe"
operation capability, i.e, that no transmission shall occur inadvertently under all realistic conditions.

2 APPLICABILITY

All classes of LMESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

Temperature.

Humidity.

Power supply.

4 TEST SET-UP

See Test Item 3-D.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item 3-D.

6 TEST PROCEDURE

6.1 The test procedure for the LMES:

(a) Set power supply to nominal level. Switch on LMES (idle mode). Record actual power in the
frequency band 0Hz - 18 GHz at the antenna (measured power plus coupling loss)

(b) Switch on LMES (idle mode).Set the coupling network to measure the total power at the
antenna for each of the following frequency band:

(i) 100 KHz to 1000 MHz

(ii) 1000 MHz to 4000 MHz

(c) Increase power supply frequency to maximum as shown on the results sheets (if applicable).
Monitor the power meter while slowly (over two seconds minimum) increasing the power
supply voltage to the maximum shown. Record the maximum actual power level at the
antenna.

(d) Decrease power supply frequency to minimum as shown on the results sheets (if applicable).

Monitor the power meter while slowly (over 10 seconds) decreasing the power supply voltage
to zero. Then slowly increase the power supply voltage to nominal. Record the maximum
actual power level at the antenna.

Recommended Test Procedures (RTPs), Page: 16


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(e) With power supply voltage and frequency at nominal, monitor the output power with the peak
power or RF detector while disconnecting and reconnecting the power supply five times. The
power supply must be physically disconnected from the LMES each time, and not merely
switched on and off. Record any anomalies or increases in the LMES output power above its
nominal value, onto the data sheet.

(f) With nominal power supply voltage and frequency, switch the LMES off and on ten times in
quick succession. Record any anomalies or increases in the LMES output power above its
nominal value, onto the data sheet.

(g) Repeat steps (a) through (f) for all types of power supplies which may be supplied with the
LMES.

(h) Repeat steps (a) through (f) at -250C, 400C with 95% relative humidity, and at 550C.

(i) Monitor the output level with the peak power or RF detector while performing the following
on both the IME and the EME of the LMES. Record any anomalies or transients seen at the
LMES antenna connector.

i.1 Drop from a height of not less than 10 cm (4 inches) onto a hard surface.

i.2 Apply a shock with a plastic or rubber hammer (with a mass of at least 250g) to the LMES in
each of three mutually orthogonal planes.

i.3 Disconnect and reconnect each connector inside the IME and EME. This includes edge and
RF connectors.

i.4 Apply a spark to the LMES casing (from 50V source).

7 PASS/FAIL CRITERIA

Under all possible conditions the LMES power output and power output transients shall not exceed -45
dBW in the band 0Hz to 18 GHz, -87dBW in the band 100 kHz to 1000 MHz and -77 dBW in the band
1000 MHz to 4000 MHz when the transmitter is in a non-operative state.

Recommended Test Procedures (RTPs), Page: 17


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM L3-E SPURIOUS OUTPUTS

1 PURPOSE

The test shall verify that the spurious outputs of the transmitter comply with the requirements of
Volume 3, Part 2, Chapter 6, Section 3.4.4.

2 APPLICABILITY

All classes of LMESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

Temperature.

Humidity.

Vibration.

4 TEST SET-UP

See Test Item 3-E.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item 3-E.

6 TEST PROCEDURE

See Test Item 3-E.

In addition, the total power of all spurious outputs falling within each of the bands specified below
should be calculated, and the calculation should be submitted together with the results.

7.1 PASS/FAIL CRITERIA FOR LMES

As the criteria in Test Item 3-E with the additional requirement that the total radiated power (excluding
harmonics) in the following bands should not exceed the levels specified below:

Frequency Band Total Radiated Power

100 kHz-1000MHz -66 dBW

1000 MHz-1626.5 MHz -60 dBW

1646.5 MHz-4000 MHz -60 dBW

Recommended Test Procedures (RTPs), Page: 18


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM L4-A PACKET ERROR RATE

1 PURPOSE

The test shall verify that the performance of the receiver in terms of packet error rate (PER) is within
the limits specified in Volume 3, Part 2, Chapter 2, Section 4.5 with all the impairments* therein
specified in Volume 3, Part 2, Chapter 2, section 4.4.

Moreover, the degradation of receiver performance in the presence of out-of-band interfering signals
will be checked according to Volume 3, Part 2, Chapter 6, Section 3.3.3.

*Note: The value of the doppler variation should be +/-50 Hz over 10s according to the specification in
Volume 3, Part 2, Chapter 6, section 4.7.

2 APPLICABILITY

All classes of LMESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

Temperature.

humidity.

Main power supply.

Vibration.

4 TEST SET-UP

See Test Item 4-A.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item 4-A.

6 TEST PROCEDURE

See Test Item 4-A except for step (i) where the out of band interference should cover the bands
specified in Volume 3, Part 2, Chapter 6 and an additional test procedure below should be followed:

(i) If any spurious responses are discovered (indicated by degradation in PER), then the
frequencies of these responses should be noted.

(i-1) The receiver should be rechecked for PER degradation at these identified out of band
frequencies with the interference at the lower level of +100 dBc.

(i-2) If any spurious response (PER degradation) is observed at this lower level due to the receiver's
image response, then the level of interference at which PER degradation occurs should be
measured and noted.

Recommended Test Procedures (RTPs), Page: 19


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

In addition, for the case of image response described above, the frequency band in which the image
response lies should be stated and information on potential sources of interference in that band should
be supplied.

7 PASS/FAIL CRITERIA

The packet error rate shall not exceed the following values:

PFD (dBW/M2) [C/No (dBHz)]* PER% (48) PER% (128)

-145.5 [35] 0.7 2.0

-146.5 [34] 2.7 8.0

Recommended Test Procedures (RTPs), Page: 20


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM L4-B PACKET ERROR RATE UNDER SHORT TERM REPETITIVE BLOCKAGE
CONDITIONS

1 PURPOSE

The test shall verify that the performance of the receiver in terms of packet error rate (PER) is within
the limits specified in Volume 3, Part 2, Chapter 6, Section 4.7.3 with all the impairments* except
multipath fading therein specified in Volume 3, Part 2, Chapter 2, section 4.4.

*Note: The value of the doppler variation should be +/-50 Hz over 10s according to the specification
in Volume 3, Part 2, Chapter 6, section 4.7.

2 APPLICABILITY

All classes of LMESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

Temperature

humidity

Main power supply

Vibration

4 TEST SET-UP

ENVIRONMENTAL CHAMBER/VIBRATION TABLE

NCS/LES CHANNELSI
SIMULATOR MULATOR LMES

SYNC

TIMER COUNTER POWER


SUPPLY DTE
CONTROLLER

Figure L4-B

5 REQUIRED TEST EQUIPMENT AND FACILITIES

(a) NCS/LES simulator.

(b) Channel simulator system comprising (refer to figure L4-B/1):

Recommended Test Procedures (RTPs), Page: 21


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

b.1 Additive white gaussian noise;

b.2 Phase noise;

b.3 Short-term doppler;

b.4 Adjacent channel interference;

SWITCH
IN
UPCONVERT
ER

BAND
PASSFI SIGNAL
BPSKMODUL IF/RFGENER LTER GENERA
ATOR ATOR TOR
TIMER
INTERFERENCE(ADJA
EXT PM
CENT CHANNEL) WIDE
BAND INTERFERENC
NOISE E(OUT OF
BAND)
LPFEQUALI ADDITIVE
SER NOISE
FUNCTIONG
PHASE ENERATOR
NOISE LF
NOISESO SHORT-TERM
URCE DOPPLER

Figure L4-B/1

(c) Signal generator (for out-of-band interference);

(d) Environmental chamber(s) (temperature and humidity);

(e) Vibration table;

(f) Power supplies in which voltage can be varied. An appropriate power supply is required for
each of the power interfaces which may be supplied with the LMES (ie. DC mains or DC
battery).

6 TEST PROCEDURE

(a) Connect the simulators and the LMES as shown in figure L4-B.

Initialise the set-up.

Prior to the tests, the various subsystems of the Channel simulator unit need to be calibrated to
ensure that the impairments introduced during the tests are as specified.

(b) Set the channel simulator for the following conditions:

Recommended Test Procedures (RTPs), Page: 22


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

b.1 Received carrier level corresponding to a PFD of -145.5 dBW/m2 at the LMES
antenna*;

b.2 Phase noise and short-term doppler present (ON);

b.3 Carrier frequency offset = +850 Hz, Clock offset = -0.06 Hz;

b.4 Interferers, ACI 5 kHz above the nominal carrier frequency at +5 dBc.

*Note :This should be equivalent to C/No = 35 dB Hz at the demodulator input, with a G/T =
-23 dBK-1, however the G/T measured should be taken into account; refer to Item 2-B G/T
calculations.

(c) Start sending in every frame four 128 byte test packets and activate the timer/function
generator to interrupt RF signal for 2s during every 8.9s.

(d) Run the test for time sufficient to transmit the LMES a total of 5000 test packets. Record the
number of packet error.

Calculate the PEP% as:

PE128
PER%(128) = 50

(e) After changing the received carrier level to correspond to a PFD of - 144.5 dBW/m2 (C/No =
36 dB-Hz at the demodulator), see note* in (b), run the Test for a time corresponding to 5000
test packets transmitted.

Calculate the PEP% as:

PE128
PER%(128) = 50

(f) Repeat steps (c) and (d), with all the impairments specified in (b),at high temperature/high
power and low temperature/low power.

(g) Repeat steps (e), with all the impairments specified in (b), at humidity.

(h) Set blocked period to 2.7s,with all the impairments specified in (b), repeat steps (c) and (d) at
normal ambient , and step (e) at vibration.

7 PASS/FAIL CRITERIA

The packet error rate shall not exceed the following values:

PFD (dBW/M2) [C/No (dBHz)] PER% (B=2s) PER% (B=2.7s)

-145.5 [35] 10 not specified

-144.5 [36] 2 10

Recommended Test Procedures (RTPs), Page: 23


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM L4-C CARRIER AND FRAME ACQUISITION

1 PURPOSE

The test shall verify that the performance of the receiver in terms of carrier/symbol/frame acquisition is
within the limits specified in Volume 3, Part 2, Chapter 2, Section 4.6 with all the impairments* stated
in Volume 3, Part 2, Chapter 2, Section 4.4.

*Note: The value of the doppler variation should be +/-50 Hz over 10s according to the specification in
Volume 3, Part 2, Chapter 6, section 4.7.

2 APPLICABILITY

All classes of LMESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

Temperature

humidity

Main power supply

Vibration

4 TEST SET-UP

See Test Item 4-B.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item 4-B.

6 TEST PROCEDURE

See Test Item 4-B.

7 PASS/FAIL CRITERIA

Refer to Test Item 4-B.

Recommended Test Procedures (RTPs), Page: 24


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM L4-D CARRIER ACQUISITION UNDER LONG TERM BLOCKAGE CONDITIONS

1 PURPOSE

The test shall verify that the performance of the receiver in terms of carrier acquisition is within the
limits specified in Volume 3, Part 2, Chapter 6, Section 4.7.4 with all the impairments except multipath
fading stated in Volume 3, Part 2, Chapter 2, Section 4.4.

*Note: The value of the doppler variation should be +/-50 Hz over 10s according to the specification
in Volume 3, Part 2, Chapter 6, section 4.7.

2 APPLICABILITY

All classes of LMESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

Temperature

humidity

Main power supply

Vibration

4 TEST SET-UP

See Test Item L4-B.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item L4-B.

6 TEST PROCEDURE

(a) Connect the simulators and the LMES as shown in figure L4-B.

Initialise the set-up.

Prior to the tests, the various subsystems of the Channel simulator unit need to be calibrated to
ensure that the impairments introduced during the tests are as specified.

Tune the NCS/CES simulator and the MES to channel no.1100010.

Set the channel simulator system for the following conditions:

Received carrier level corresponding to a PFD of -145.5 dBW/m2 at the LMES

antenna;

Phase noise and short term doppler(+/-50 Hz over 10s): ON;

Carrier frequency offset = -850 Hz;

Recommended Test Procedures (RTPs), Page: 25


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Data rate offset = 0.06 Hz;

Interference: ON.

(b) Start sending continuously test frames and activate the time/function generator to interrupt the
RF signal with blockage length(B) set to 5s. For each blockage, set dF (the difference in
frequency of the carrier between the start and end of the blockage) to the maximum limit
given in Volume 3, Part 2, Chapter 6, Section 4.7.4.

(c) After each blockage, measure on the counter, the time taken to re-acquire the carrier and
timing ( clock recovery), Traq, and record the result.

(d) Repeat step (b) 300 times, record Traq each time, and then calculate the average Traq.

(e) Repeat step (d) with a carrier frequency offset of +850 Hz and a data rate offset of -0.06 Hz.

(f) Repeat step (e) at high temperature/high power with a carrier frequency offset of -850 Hz and
again with humidity.

(g) Repeat step (e) at low temperature/low power with a carrier frequency offset of -850 Hz and
again with vibration.

(h) Set blockage length (B) to 24s, 85s and 180s respectively and repeat step (b) through step (g)
for each blockage length.

7 PASS/FAIL CRITERIA

The average Traq and the maximum Traq shall be within the following limits:

Range of blockage B Limits of dF Traq

5s - 25s +/- 100 Hz < 1 sec.

25s - 90s +/- 200 Hz 4s max: 2 secs average

90s - 180s +/- 500 Hz 10s max: 5 secs average

Recommended Test Procedures (RTPs), Page: 26


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM L5-C SIGNALLING CHANNEL CHARACTERISTICS

1 PURPOSE

The test shall verify all packets transmitted on the signalling channel are correctly formatted with
Unique Word insertion, coding and scrambling as specified in Volume 3, Part 2, Chapter 2, Section
5.3.

2 APPLICABILITY

All classes of LMESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

See Test Item 5-C. For LMESs intending to provide Land Mobile Alerting, a Land Mobile Alert (Test)
packet should be sent as an additional step (p).

(p) Cause the LMES to send a Land Mobile Alert (Test) packet to the NCS/LES simulator.
Record the values assumed for:

- the LMES ID;

- the LES ID;

on the test data sheet.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item 5-C.

6 TEST PROCEDURE

See Test Rem 5-C.

7 PASS/FAIL CRITERIA

Refer to Test Item 5-C.

Recommended Test Procedures (RTPs), Page: 27


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM L6-A/1 LAND MOBILE ALERT ACCESS CONTROL TEST

1 PURPOSE

The test shall verify that the Land Mobile Alert protocol implemented in the LMES under test are
compliant with the requirements stated in Volume 1, Chapter 8, Volume 4, Chapter 11 and Volume 3,
Part 2, Chapter 6, Section 8.

2 APPLICABILITY

All classes of LMESs with Land Mobile Alert function.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

See Test Item 6-A.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item 6-A.

6 TEST PROCEDURE

LES with Demand Assigned TDM

Simulate a scenario in which the destination LES is operating with a Demand Assigned TDM (LES
TDM channel number FFFFH in network update or log-in acknowledgement packet) and initiate a
Land Mobile Alert.

Monitor and record the behaviour of the LMES (responses to the operator, signalling channel no. etc)
throughout the following tests.

a) Set the land Mobile alert not available and the maritime distress alert available in service field
of NCS bulletin board, and then attempt the transmission of the land Mobile alert.

Expected result: The transmission shall not occur and a prompt such as"Land Mobile Alerting
not available on current NCS" should be printed out or appear on disply.

b) Set the land Mobile alert available and the maritime distress alert not available in service field
and make the transmission of the Land Mobile Alert packet successful. Wait R+N1 frames
and send an Acknowledgement Packet.

LMES/NSIG/F0/LAND MOBILE ALERT - OK

NCS/NCC/F0+R+N1/LAND MOBILE ALERT ACK

Expected result: Alert OK

c) Repeat as in b), but send the Acknowledgement Packet R+N2 frames later.

LMES/NSIG/F0/LAND MOBILE ALERT - OK

Recommended Test Procedures (RTPs), Page: 28


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

NCS/NCC/F0+R+N2/LAND MOBILE ALERT ACK

Expected result: LMES should repeat the Land Mobile Alert automatically after the timeout
on the NCS Signalling channel:

LMES/NSIG/F1/LAND MOBILE ALERT - OK

NCS/NCC/F1+R+N1/LAND MOBILE ALERT ACK

d) Repeat as in b) and make the transmission of the Land Mobile Alert packet fail.

LMES/NSIG/F0/LAND MOBILE ALERT - FAIL

Expected result: LMES should repeat the Land Mobile Alert MaxC times on the NCS
Signalling channel.

LES Operating with a Permanent TDM

a) Set the land Mobile alert not available and the maritime distress alert available in service field
of LES bulletin board, and then attempt the transmission of the land Mobile alert.

Expected result: The transmission shall not occur and a prompt such as"Land Mobile Alerting
not available on current LES" should be printed out or appear on disply, and then LMES
should try NCS.

(b) Set the land Mobile alert available and the maritime distress alert not available in service field
and make the transmission of the Land Mobile Alert packet successful. Wait R+N1 frames
and send an Acknowledgement Packet.

LMES/CSIG/F0/LAND MOBILE ALERT - OK

LES/TDM/F0+R+N1/LAND MOBILE ALERT ACK

Expected result: Alert OK

(c) Repeat as in b), but send the Acknowledgement Packet R+N2 frames later.

LMES/CSIG/F0/LAND MOBILE ALERT - OK

LES/TDM/F0+R+N2/LAND MOBILE ALERT ACK

LMES/CSIG/F1/LAND MOBILE ALERT - OK

LES/TDM/F1+R+N2/DILAND MOBILE ALERT ACK

---

LMES/CSIG/Fn/LAND MOBILE ALERT - OK

LES/TDM/Fn+R+N2/LAND MOBILE ALERT ACK

Expected result: LMES should repeat the Land Mobile Alert MaxCD times automatically after
each timeout on the LES Signaling Channel. Then the LMES should send the Land Mobile
Alert on the NCS Signaling Channel.

Recommended Test Procedures (RTPs), Page: 29


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

LMES/NSIG/Fn1/LAND MOBILE ALERT - OK

NCS/NCC/Fn1+R+1/LAND MOBILE ALERT ACK

(d) Repeat as in c), but set the Land Mobile Alert not available and the maritime distress alert
available in service field of NCS bulletin board. Send the Acknowledgement Packet from the
LES after R+N2 frames. make the next Land Mobile Alert Packet successful again and send
the Acknowledgement Packet after a further R+N2 frames.

LMES/CSIG/F1/LAND MOBILE ALERT - OK

LES/TDM/F1+R+N2/LAND MOBILE ALERT ACK

LMES/CSIG/F2/LAND MOBILE - OK

LES/TDM/F2+R+N2/LAND MOBILE ALERT ACK

---

LMES/CSIG/Fn/LAND MOBILE ALERT - OK

LES/TDM/Fn+R+N2/LAND MOBILE ALERT ACK

Expected result: LMES should repeat the Land Mobile Alert MaxCD times automatically after
each timeout on the LES Signalling Channel. Then the LMES should not send the Land
Mobile Alert on the NCS Signalling channel.

(e) Repeat as in b). but make the transmission of the Land Mobile Alert Packet fail.

LMES/CSIG/F0/LAND MOBILE ALERT - FAIL

Expected result: LMES should repeat the Land Mobile Alert MaxC times on the LES
Signaling Channel and then retune to the NCS and send the Land Mobile Alert on the NCS
Signalling channel:

LMES/NSIG/F1/LAND MOBILE ALERT - OK

NCS/NCC/F1+R+N1/LAND MOBILE ALERT ACK

(f) Repeat as in e) and send the Acknowledgement Packet from the NCS after R+N2 frames.

LMES/CSIG/F0/LAND MOBILE ALERT - FAIL

Expected result: LMES should repeat the Land Mobile Alert MaxC times on the LES
signalling channel and then retune to the NCS and resend the Land Mobile Alert on the NCS
Signalling channel:

LMES/NSIG/F1/LAND MOBILE ALERT - OK

NCS/NCC/F1+R+N2/LAND MOBILE ALERT ACK

Expected result: LMES should repeat the Land Mobile Alert on the NCS signalling channel.
Note any further action of the LMES (ie, operator prompts).

Recommended Test Procedures (RTPs), Page: 30


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(g) Make 2 LES Signalling Channels available, Set the land Mobile alert available in service field
of the bulletin board and set SCDs to show that one is a general signalling channel ( i.e. Land
Mobile Alerting flag set in addition to other flags) and the other is a dedicated Land Mobile
channel (i.e. only Land Mobile Alert flag set). Make the transmission of the Land Mobile
Alert packet successful. Wait R+N1 frames and send an Acknowledgement Packet.

LMES/CSIG/F0/LAND MOBILE ALERT - OK

LES/TDM/F0+R+N1/LAND MOBILE ALERT ACK

Expected result: Alert should be received on the dedicated Land Mobile channel and OK.

(h) Make 2 LES Signalling Channels available, Set the land Mobile alert available in service field
of the bulletin board and set SCDs to show that one is a general signalling channel ( i.e. Land
Mobile Alerting flag set in addition to other flags) and the other is set to show that Land
Mobile Alerting is not available (i.e. no Land Mobile Alert flag set). Make the transmission of
the Land Mobile Alert packet successful. Wait R+N1 frames and send an Acknowledgement
Packet.

LMES/CSIG/F0/LAND MOBILE ALERT - OK

LES/TDM/F0+R+N1/LAND MOBILE ALERT ACK

Expected result: Alert should be received on the general signalling channel and OK.

(i) Repeat as in e), but set the NCS to have a dedicated land Mobile channel and a general
signalling channel . Make LMES land Mobile alert fail, and then LMES transmits the Land
Mobile Alert automatically to NCS .

LMES/CSIG/F0/LAND MOBILE ALERT - FAIL

.........

LMES/NSIG/F0/LAND MOBILE ALERT - OK

NCS/NCC/F0+R+N1/LAND MOBILE ALERT ACK

Expected result: Alert should be received on the dedicated Land Mobile channel and OK.

(j) Repeat as in g), but set the LES to have a dedicated maritime distress channel and a general
signalling channel , also, both land Mobile and maritime distress alerts available in service
field of the bulletin board

LMES/CSIG/F0/LAND MOBILE ALERT - OK

LES/TDM/F0+R+N1/LAND MOBILE ALERT ACK

Expected result: Alert should be received on the general signalling channel and OK.

Recommended Test Procedures (RTPs), Page: 31


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM L6-A/2 PVT ACCESS CONTROL TEST

1 PURPOSE

The test shall verify that PVT protocols implemented in the LMES under test are compliant with the
requirements stated in Volume 1, Chapter 8, Volume 4, Chapter 11 and Volume 3, Part 2, Chapter 6,
Section 9.

2 APPLICABILITY

All classes of LMESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

See Test Item 6-A.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item 6-A.

6 TEST PROCEDURE

See Test Item 6-A, Part 2, Section 6. However, the alert packet contents should be as defined for the
Land Mobile Alert and the Land Mobile Alert flag in the service field of a LES bulletin board and in
the signalling channel descriptor shall be set unavailable.

7 PASS/FAIL CRITERIA

Refer to Test Item 6-A, Part 2, Section 6.

Recommended Test Procedures (RTPs), Page: 32


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM L6-D COMMON CHANNEL SELECTION

1 PURPOSE

The test shall verify the LMES's memory capability in respect of the NCS common channels and their
selection under different network scenarios as indicated in Volume 3, Part 2, Chapter 2, Section 6.3.

2 APPLICABILITY

All classes of LMESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

See Test Item 6-D.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item 6-D.

6 TEST PROCEDURE

See Test Item 6-D. However, the NCS only transmit FleetNet EGC in Test Item 6-D, Part B.

For LMESs, the alternative test procedure in Part C is as follows:

(a) Enter the 76 NCS channels in the LPES memory. Set configuration LESs in the simulator.

(b) Set the preferred and the current NCS to 144 (12580) and the simulator to 144(12580).

(c) Transmit two NCS common channels, one of which is set to a global beam NCS common
channel with NCS ID 144 and power level [X dBw], and the other is set to a spot beam
common channel with NCS ID 150, and the power level [X+5dBw].

(d) Connect the simulator and the LPES.

(e) Power on the LPES.

(f) Check the NCS ID which the LPES tuned to.

(g) Transmit two NCS common channels, one of which is set to a global beam NCS common
channel with NCS ID 244 and power level [X dBw], and the other is set to a spot beam
common channel with NCS ID 250, and the power level [X-5dBw].

(h) After the LPES could not synchronise to the NCS 144, check that a prompt to tune to other
NCS channels was sent to the operator via the DTE.

(i) Start tuning to the NCS 250 manully.

(j) Check that the LPES tuned to the spot beam NCS 250 and Log-in request was sent.

Recommended Test Procedures (RTPs), Page: 33


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

7 PASS/FAIL CRITERIA

Refer to Test Item 6-D.

For the LMES,the criteria of the alternative test procedure in Part C shall be as follows:

step f The LMES tunes to NCS 144.

step h The prompt is sent to the operator.

step j The LMES tunes to NCS 250.

Recommended Test Procedures (RTPs), Page: 34


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM L6-E OCEAN REGION REGISTRATION

1 PURPOSE

The test shall verify the LMES function in respect of the Ocean Region registration as indicated in
Volume 3, Part 2, Chapter 6, Section 6.5.

2 APPLICABILITY

All classes of LMESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

See Test Item 6-E.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item 6-E.

6 TEST PROCEDURE

(a) Enter the 76 NCS IDs and channel numbers into the LMES.

(b) Set the LMES preferred ocean region to AOR-E,144, and the simulator NCS ID to 144 with
the simulator disconnected.

(c) Turn the LMES off and connect the simulators and the LMES.

(d) Turn the LMES on.

(e) Initiate a log-in command.

(f) Repeat steps (c) to (d) with the simulator NCS ID 150 (1100010).

(g) Initiate a scanning command.

(h) Repeat steps (c) to (d) with the simulator NCS ID 244 (1258010).

(i) Initiate a scanning command.

(j) Set the preferred ocean region off and repeat steps (c) to (d) with the simulator NCS ID 244.

(k) Keep the preferred ocean region off and repeat steps (c) to (d) with the simulator NCS ID 344.

(l) Set the LMES preferred NCS to 150 and the simulator NCS ID to 150. Repeat steps (c) to (d).

(m) Repeat step (l) with the simulator NCS ID 244.

(n) Repeat step (l) with the simulator NCS ID 151.

(o) Repeat step (l) with the simulator NCS ID 144.

Recommended Test Procedures (RTPs), Page: 35


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(p) Repear step (l), after synchronisation, send a network update packet with new information and
a new version number.

(q) Send manually a request for log-out from the LMES and inspect via the DTE the packet
received by the simulator.

7 PASS/FAIL CRITERIA

The following responses and status of the LMES shall be observed:

step d, j, l The MES should tune to the NCS common channel but not send a log-in packet
automatically;

step e A valid log-in packet is transmitted;

step f, h, k, m, n,o

A prompt sent to the operator via the DTE for manually initiating NCS scanning or
tuning to another NCS common channel;

step g The MES should tuen to NCS 150 and send a valid log-in packet automatically;

step i The MES should tuen to NCS 244 and send a valid log-in packet automatically;

step p. The MES should accept the new network update packet and overwrite the old one.

step q A valid log-out transmitted.

Recommended Test Procedures (RTPs), Page: 36


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM L8-A ALERT GENERATOR

1 PURPOSE

The test shall demonstrate that the Land Mobile Alert message is assembled and transmitted by the
LMES according to the format specified in Volume 3, Part 2, Chapter 6, Section 8.3.

2 APPLICABILITY

All classes of LMESs intending to include the Land Mobile Alert function.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

See Test Item S8-A, Figure S8-A

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item S8-A.

6 TEST PROCEDURE

See Test Item S8-A. However, the packet contents should be as defined for Land Mobile.

Also, one more test, step c/1), will be added. When step c) is completed, repeat this test 10 minutes
later without updating the position.

7 PASS/FAIL CRITERIA

Refer to Test Item S8-A. However,the packets received should correspond to the format specified in
Volume 3, Part 2, Chapter 2, Volume 1, Chapter 8 and Volume 4, Chapter 11.

Recommended Test Procedures (RTPs), Page: 37


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM L8-B ALERT ACTIVATION

1 PURPOSE

The test will demonstrate that the land Mobile alert activation function of the LMES complies with the
requirements given in Volume 3, Part 2, Chapter 6, Section 8.4 under different environmental
conditions. The fail-safe operation of a remote distress button facility (when provided) will be also
checked.

2 APPLICABILITY

All classes of LMESs intending to have Land Mobile Alert function.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

Temperature

Humidity

Power supply

Vibration

4 TEST SET-UP

See Test Item S8-B, Figure S8-B.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item S8-B.

6 TEST PROCEDURE

See Test Item S8-B. However, the packet contents should be as defined for Land Mobile.

7 PASS/FAIL CRITERIA

Refer to Test Item S8-B and the packet contents shall be as defined for Land Mobile.

Recommended Test Procedures (RTPs), Page: 38


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM L9-B PERFORMANCE VERIFICATION AND COMMISSIONING


TESTS

1 PURPOSE OF THE TEST

This test shall verify that the LMES correctly perform the Performance Verification and
Commissioning Tests as described in Volume 3, Part 2, Chapter 6, Section 9.3 (and Volume 1, Chapter
4, Section 10).

2 APPLICABILITY

All classes of LMESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

4 TEST SET-UP

See Test Item 9-B, Figure 9-B.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item 9-B.

6 TEST PROCEDURE

(a) Send a Performance Verification test request from the LMES to the NCS/CES simulator.
Verify that the request transmitted is correct.

(b) Send a test announcement from the NCS/LES simulator to the LMES on the NCS common
channel.

(c) Verify that the LMES transmits a valid assignment response to the simulator on the signalling
channel.

(d) Send the "test pattern" message from the simulator to the LMES on the LES TDM channel,
with one or more errors in the test message.

The test pattern below may be used.

FF83 DF17 3209 4ED1 E7CD 8A91 C6D5 C4C4

4021 184E 5586 F4DC 8A15 A7EC 92DF 9353

3018 CA34 BFA2 C759 678F BA0D 6DD8 2D7D

540A 5797 7039 D27A EA24 3385 ED9A 1DE0

Following the message, send a request for acknowledgement. Verify that the LMES requests the LES
to re-transmit the message.

(e) Transmit the test pattern from the LES without errors, followed by a request for
acknowledgement.

Recommended Test Procedures (RTPs), Page: 39


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(f) Verify that the LMES sends an acknowledgement to the LES on the signalling channel.

(g) Transmit a logical channel clear from the simulator to the LMES.

(h) Verify that the LMES immediately transmits an assignment request to the LES on the
signalling channel.

(i) Send a logical Channel Assignment from the NCS/LES simulator on the LES TDM.

(j) Verify that the LMES automatically transmits the message received from the LES (in (d)
above). The information field should be set to one byte and contain an eight bit representation
of the (current) bulletin board error rate.

(k) Transmit a re-transmission request (negative acknowledgement) from the NCS/LES simulator
on the LES-TDM.

(l) Verify that the LMES retransmits the errored packets.

(m) Transmit a positive acknowledgement from the NCS/LES simulator on the LES TDM,
followed by a distress test request.

(n) For the LMES, a prompt, indicating a Land Mobile alert test shall be activated automatically
and immediately after receiving the alert test request packet from the LES, shall appear on the
display

(o) Transmit a Land Mobile alert from the LMES and verify that a Land Mobile alert test is sent
to the LES.

(p) Send a test result packet from the LES (Volume 1, Chapter 4, Section 10.2.5). Verify that the
LMES sends a test result acknowledgement packet and stores and displays the test results.

(q) Clear the call from the LES.

(r) Initiate a PVT at the NCS using a different test message (the test message should be 4 kbytes)
to that shown in d. Verify that the message transferred in the From-Mobile direction is
identical to that sent in the To-Mobile direction and that the test is completed successfully.

(This test is also covered in detail in Test Item 6-A).

7 PASS/FAIL CRITERIA

The LMES must operate according to the protocols defined in Volume 3, Part 2, Chapter 6, Section 9.3.
The test results shall be made available for the operator.

Recommended Test Procedures (RTPs), Page: 40


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM L11-A VIBRATION TEST

1 PURPOSE

The test will check the performance of the LMES under vibration conditions: its main purpose is to
demonstrate that the mechanical design of the LMES is suitable for use under conditions of vibration
up to those specified in the technical requirements document (refer to Volume 3, Part 2, Chapter 6,
Section 11.2).

2 APPLICABILITY

All classes of LMESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient conditions and vibration as specified.

4 TEST SET - UP

See Test Item 11-A,Figure 11-A.

5 REQUIRED TEST EQUIPMENT

-Vibration Table capable of transmitting to the equipment under test vibration conditions as specified
below.

- NCS/LES simulator.

6 TEST PROCEDURE

Three mutually perpendicular major axes shall be defined for the equipment under test: for clarity, in
the following they will be called as X, Y, and Z-axis.

a) Install the LMES on the vibration table to vibrate along the X-axis.

b)* The equipment shall be turned on and vibrated for 2 hours under the following
conditions(survival):

5 to 20 Hz : 0.05 g2/ Hz

20 to 150 Hz : -3dB/oct.

(1.7 g rms)

c) At the end of the vibration, check the integrity of the equipment and inspect for any
mechanical damages; it shall remain operational and capable to meet the performance
specifications as set forth in the Technical Requirements Document. For this purpose, some
simple functional checks will suffice (eg a From-Mobile and a To-Mobile message
transfer with the NCS/LES simulator; having the message printed if the Printer is the
equipment under test).

d) Repeat steps b) through c) for the Y-axis.

e) Repeat steps b) through c) for the Z-axis.

Recommended Test Procedures (RTPs), Page: 41


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

f)* The LMES shall be turned on and vibrated under the following conditions ( operational):

5 to 20 Hz : 0.005 g2/ Hz

20 to 150 Hz : -3dB/oct.

(0.5 g rms)

g) During the vibration, check the performance of the LMES; it shall remain operational and
capable to meet the performance specifications as set forth in the Technical Requirements
Document. For this purpose, some simple functional checks will suffice (eg a To-Mobile
message transfer with the NCS/LES simulator; having the message printed if the Printer is the
equipment under test).

h) Repeat steps f) through g) for the Y-axis.

i) Repeat steps f) through g) for the Z-axis.

Note:

The random vibration testing is strongly recommended. However,consideration will be given


to changing these vibration conditions if the manufactures have no random vibrating tables.
An acceptable condition is given below:

(for performance tests)

Frequency Range Level

5 - 20 Hz [0.8 mm] peak amplitude

20 - 150 Hz [1.3 g] peak acceleration

(for survival tests)

Frequency Range Level

5 - 20 Hz [2.7 mm] peak amplitude

20 - 150 Hz [4.3 g] peak acceleration

7 PASS/FAIL CRITERIA

a) The LMES under vibration (survival)testing shall not reveal any mechanical alterations and
should be capable to complete successfully the functional checks in step c).

b) The LMES under vibration (operational) testing should be capable to complete successfully
the functional checks in step g).

Recommended Test Procedures (RTPs), Page: 42


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM L11-B SHOCK TEST

1 PURPOSE

The test will check the performance of the LMES under shock conditions: its main purpose is to
demonstrate that the mechanical design of the LMES is suitable for use under conditions of shock up to
those specified in the technical requirements document (refer to Volume 3, Part 2, Chapter 6, Section
11.2).

2 APPLICABILITY

All classes of LMESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient conditions and shock as specified.

4 TEST SET - UP

See Test Item 9-B, Figure 9-B.

5 REQUIRED TEST EQUIPMENT

-The table suitable for shock testing

- NCS/LES simulator.

6 TEST PROCEDURE

Three mutually perpendicular major axes shall be defined for the equipment under test: for clarity, in
the following they will be called as X, Y, and Z-axis.

a) Install the LMES on the table along the X-axis.

b) 3 shocks shall be performed on each side (a total of 6 shocks on both sides) under the
following conditions:

-Half sinewave shock with a peak of 20g and a duration of 11 ms.

c) At the end of the shock testing, check the integrity of the equipment and inspect for any
mechanical damages; it shall remain operational and capable to meet the performance
specifications as set forth in the technical requirements document. For this purpose, some
simple functional checks will suffice (eg a From-Mobile and a To-Mobile message transfer
with the NCS/LES simulator; having the message printed if the Printer is the equipment under
test).

d) Repeat steps b) through c) for the Y-axis.

e) Repeat steps b) through c) for the Z-axis.

7 PASS/FAIL CRITERIA

The LMES under shock testing shall not reveal any mechanical alterations and should be capable to
complete successfully the functional checks in step c).

Recommended Test Procedures (RTPs), Page: 43


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM L11-C RAIN TEST

1 PURPOSE

The test shall demonstrate that the mechanical design of the Externally Mounted Equipment (EME) is
suitable for use under rain conditions. Refer to Volume 3, Part 2, Chapter 6, Section 11.2 and Chapter
7, Section 11.2.

2 APPLICABILITY

All classes of LMESs.

3 ENVIRONMENTAL CONDITIONS

See Test Item 11-B.

4 TEST SET-UP

See Test Item 11-B.

5 REQUIRED TEST EQUIPMENT

- Water supply capable of creating precipitation up to 5 cm/hour.

- Nozzle capable of spraying with droplet size 0.5 to 4.5 mm.

- NCS/CES simulator.

6 TEST PROCEDURE

The procedure for conducting this test is also described in section 2.1.7, Environmental Condition
Tests, (D).

The test shall be carried out by spraying the equipment from all directions with a stream of water from
a nozzle; throughout the test the equipment shall be operating normally.

a) Install the LMES equipment under test in a suitable location for the test.

b) The water pressure at the nozzle should be adjusted to achieve the specified delivery rate. The
water should rise freely for a vertical distance of approximately 8 metres above the nozzle.

c) Turn on the equipment and spray the EME from all practicable directions keeping the distance
from the nozzle to the EME at approximately 3 metres; keep on spraying for at least (30)
minutes.

d) Stop spraying and inspect the EME for ingress of water; remove the antenna and connect the
NCS/CES simulator to the LMES under test.

e) Perform simple functional tests (eg To-Mobile and From-Mobile message transfers) and
record the results.

Recommended Test Procedures (RTPs), Page: 44


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

7 PASS/FAIL CRITERIA

Step d): the EME shall not reveal any water leaks which might affect the performance of the
equipment.

Step e): the functional test shall be successfully completed.

Recommended Test Procedures (RTPs), Page: 45


Section 4: Phase 1 Tests for Land Mobile Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

5. PHASE 1 TESTS FOR LAND PORTABLE EARTH STATIONS

5.1 INTRODUCTION AND REQUIRED TESTS

5.1.1 GENERAL

The purpose of these tests is to demonstrate that all the relevant INMARSAT performance requirements in
Volume 3, Part 2, Chapter 7 of the SDM are satisfied by Land-Based Portable Earth Stations, over the full range
of environmental conditions in which they are designed to operate. This Section outlines the minimum
requirements of a test plan for both Phase I and Phase II tests. The test procedures and test data sheets presented
herein can be used by manufacturers in developing their detailed test plans.

5.1.2 REQUIRED TESTS

As a minimum, the functions and characteristics listed in Table 1 for Land-Based Portable Earth Stations, shall
be tested with the indicated variations in environmental conditions. Each test procedure for the tests listed in
Table 1 makes reference to the relevant requirements in Volume 3, Part 2, Chapter 7 of the SDM.

5.1.3 FUNCTIONAL CHECKS

The manufacturer shall use a test simulator (NCS/LES simulator) and an RF simulator to verify the correct
operation of the LPES. The LPES shall simulate the RF environment in which the LPES will be used.

5.1.4 TESTS FOR EGC RECEPTION

When the LPES models for which type approval are sought, are capable of receiving EGC messages (Class 2 or
Class 3), the applicable tests for EGC receivers shall be made and checks that the EGC reception does not
interfere with the normal INMARSAT-C operation (according to the Class definition) shall also be made.

EGC function tests are limited to FleetNETTM only, " General Call" and "INMARSAT System message"
receptions according to the requirements in Volume 3, Part 2, Chapter 7 of the SDM. The basic test
requirements for LPES EGC receivers are presented in Section 6 of this document. The relevant tests shall be
conducted under the environmental conditions for the LPES.

5.1.5 TESTS BY ORIGINAL EQUIPMENT MANUFACTURERS

For some subsystems, the LPES manufacturer may not be the original manufacturer (OEM). In such cases, the
manufacturer may elect to submit the test procedures and results of the OEM, rather than repeat all tests. Use of
OEM test procedures and results to satisfy the LPES test requirements may suffice if the procedures and results
are clearly adequate. The test procedures presented here are suggested as a suitable basis for the relevant tests
to be conducted by the OEM.

5.1.6 ENVIRONMENTAL CONDITIONS TESTS

Each test item is to be performed under the relevant limits of the environmental conditions variations, specified
by the manufacturers. In principle it is desirable to test the LPES as a whole system under environmental

Recommended Test Procedures (RTPs), Page: 1


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

condition variations. However, since the environmental test facilities available to the manufacturers are often
limited, it is acceptable to perform the tests which require environmental conditions to be applied to both
Externally Mounted Equipment (EME) and the IME in two phases. Where in each phase, the EME and IME
shall be separately checked in turn with the appropriate conditions. A demonstration that the performance will
still remain within the specified limits, when the whole LPES system is subject to the environmental conditions
variations, shall be provided.

In order to keep the duration of a test within reasonable limits, when more than one type of environmental
variations are required, the tests may be combined. Therefore it will be acceptable to perform a particular
performance test under two different types of environmental conditions at the same time (eg under high voltage
and high temperature together).

The test procedures outlined in this document indicate the acceptable combinations of environmental conditions.

5.1.6.1 TEST PROCEDURES FOR LAND-BASED PORTABLE EARTH STATIONS

The procedures presented below assume the environmental conditions limits as stated in Volume 3, Part 2,
Chapter 7, Section 11 of the SDM.

A Procedures for Tests under Temperature and Humidity Variations.

A.0 Start of procedure (ambient conditions).

A.1 Place the equipment under test in the environmental test chamber(s) (temperature and
humidity).

A.2 Power-up the equipment at ambient.

A.3 Define the next Test Environment (TE) as TE1 (T=35°C for LPES mounted indoors, T=55°C
for LPES permanently mounted outdoors) with a tr = x *.

A.4 Change the environmental conditions from ambient TE0 to TE1 and leave the equipment at
these conditions for at least 3 hours or until thermal equilibrium has been attained.

A.5 Carry out the relevant test and record the results.

A.6 Bring the equipment to ambient TE0 in not less than one hour and leave it for at least 3 hours
or until thermal equilibrium has been attained.

A.7 Perform steps A.4 through A.6 with the next test environment as TE1 (T=40°C,RH=95%) and
tr = 3 hours.

A.8 Perform steps A.4 through A.6 with TE1 (T=0°C for LPES used indoors or -35°C for LPES
permanently mounted outdoors) and tr = x *.

A.9 Perform steps A.4 and A.6 with TE1 ( T= - 40°C ) and tr = x *, and then step A.5.

A.10 Perform steps A.4 and A.6 with TE1 ( T= + 80°C ) and tr = x *, and then step A.5.

A.11 End of procedure.

The diagrams in fig.1B show schematically the test cycle.

Recommended Test Procedures (RTPs), Page: 2


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

TE0 is defined as the ambient conditions, i.e. T=20°-27°C and RH=45-75%.

tr is time it shall take to reach a specified condition (next test environment) from ambient.

* tr = x means at discretion of test engineer.

x >3 hr >1 hr

+55ÞC +55ÞC >3 hr >3 hr >1 hr

+40ÞC95% RH +35ÞC >3 hr


+35ÞC +40ÞC9
5% RH >3 hr
Ambient
0ÞC
0ÞC IME
EME
-35ÞC
-35ÞC Test
x >3 hr >1 hr
Figure 1B Temperature and Humidity Cycles

B Procedures for Tests Under Power Supply Variations.

B.0 Start of procedure.

B.1 Turn on the equipment at nominal power supply conditions.

B.2 Choose as new conditions P1 (V=1.1Vo, f= 1.06 fo)

B.3 Vary the power supply conditions from P0 to P1 and leave the equipment in these conditions
for at least 5 mins.

B.4 Carry out the relevant test and record the results.

B.5 Return to the nominal power supply conditions P0.

B.6 Perform steps B.3 through B.5 with P1 (V=0.9Vo, f= 0.94 fo)

B.7 Perform steps B.3 through B.5 with P1 (V=1.3Vdc, battery powered).

B.8 Perform steps B.3 through B.5 with P1 (V=0.9Vdc battery powered).

B.9 End of procedure.

P0 is defined as the nominal power supply conditions.

Vo and fo are the nominal values of mains voltage and frequency respectively and Vdc is the nominal value of
the voltage of the battery .

C Procedure for Rain Tests (for EME only)

Recommended Test Procedures (RTPs), Page: 3


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The test shall be carried out by spraying the equipment from all practicable directions with a stream of water
from a nozzle; throughout the test the equipment shall be operating normally.

The test conditions should be the following:

5 cm/hour, droplet size 0.5 to 4.5 mm.

Procedure

C.0 Start of procedure.

C.1 Install the LPES equipment under test in a suitable location for the test.

C.2 Turn on the equipment and spray the EME from all practicable directions keeping the distance
from the nozzle to the EME at approximately 3 metres; carry out the relevant tests as required
(for at least 30 mins).

C.3 Stop spraying and inspect the EME for ingress of water.

C.4 End of procedure.

5.1.7 TEST SET-UP WITH NCS/LES SIMULATOR

For further information regarding NCS/LES simulator functions and facilities reference should be made to
Section 7 of this document; Test Simulators.

5.1.7.1 Initialisation

For each test item requiring an NCS/LES simulator, the following suggested procedure may be performed prior
to testing and it will be referred to in all applicable test procedures as the "Test set-up initialisation".

The parameters to be used for set-up purposes, unless otherwise stated in the procedure, may be as follows:

Notes: - all dimensionless figures in Hex notation unless otherwise indicated;

- xxxx indicates the frame counter;

- chks indicates the checksum (two bytes);

NCS

- at ch. 11080 (f = 1537.700 MHz received by the LMES or LPES);

- BULLETIN BOARD as (whole packet)

7DFFxxxx5020206CFFFFFF03chks

- SIGNALLING CHANNEL DESCRIPTOR as (whole packet):

6CF036AE00000000000000chks

LPES

- NCS Common Channels = ch. 11080 as a minimum;

Recommended Test Procedures (RTPs), Page: 4


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

- Preferred Ocean Region = 1;

- Destination LES = 10710;

- Transmit Service = as required (10 = Telex SFU);

After having entered these data in the simulator (NCS) and LPES, transmit NCS TDM frames on the Common
Channel, incrementing the frame number. After synchronisation, the LPES should respond with a LOG-IN
REQUEST if in its non-volatile memory there is no data pertaining to the current Ocean Region; if this Normal
Initialisation has already been performed in another test, the log-in phase will be skipped.

Upon reception of the LOG-IN-REQUEST from the LMES or LPES, the simulator (NCS) shall set the
SIGNALLING CHANNEL DESCRIPTOR to reflect a successful reception of the packet from the LPES and
transmit within 3 frames a LOG-IN ACKNOWLEDGEMENT.

SIGNALLING CHANNEL DESCRIPTOR:

Will depend on the slot chosen (in this particular case the Signalling Channel available is only one, at ch. 36AE,
corresponding to f = 1646.495 MHz transmitted by the LPES); eg. if the LOG-IN REQUEST was in slot 5 then
the Descriptor is

6CF036AE00800000000000chks.

LOGIN ACKNOWLEDGEMENT:

At this point the test is ready to commence, as the LPES has received all the required information about the
(simulated) network.

The network, as seen by the LPES, may comprises for example 15 LESs in addition to the NCS, with different
operating characteristics:

LES 1 to LES 6

- IDs = 00110 to 00610;

- operating with a permanent TDM at chs.

1F40, 1F42, 232E, 27A4, 2AF8 and 2F14 (f =

1530.000, 1530.005, 1532.515, 1535.370, 1537.500 and

1540.130 MHz) on an operational satellite;

- 600 sym/s RTN link operation;

- in service and clear;

- all Services offered;

LES 7 to LES 10:

- IDs = 00710 to 01010;

- operating with a permanent TDM at chs.

Recommended Test Procedures (RTPs), Page: 5


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

32F2, 35AE, 36AE and 36B0 (f = 1542.605, 1544.355, 1544.995 and

1545.000 MHz) on an operational satellite

- 1200 sym/s RTN link operation;

- in service and clear;

- all Services offered;

LES 11:

- ID = 01110;

- operating with a demand-assigned TDM on an operational satellite;

- 600 sym/s RTN link operation;

- in service and clear;

- all Services offered;

LES 12:

- ID = 01210;

- operating with a demand-assigned TDM on an operational satellite;

- 1200 sym/s RTN link operation;

- in service and clear;

- all Services offered;

LES 13:

- ID = 01310;

- operating with a demand-assigned TDM on a spare satellite;

- out of service;

- in service and clear;

- all Services offered;

LES 14:

- ID = 01410;

- operating with a permanent TDM at ch. 232E (f = 1532.515 MHz) on a spare satellite;

- 600 sym/s RTN link operation;

- in service and congested;

- Distress alerting, Safetynet, Std. C traffic, Telex SF and Fleetnet only;

Recommended Test Procedures (RTPs), Page: 6


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

LES 15:

- ID = 01510;

- operating with a permanent TDM at ch. 27A4 (f = 1535.370 MHz) on a spare satellite;

- out of service

5.1.7.2 Set-up of calls using NCS/LES simulator

a. For checking purposes, whenever a To-Mobile message transfer has to be initiated, the simulator will
send (in an NCS frame) an ANNOUNCEMENT related to a message of one line of QBF (56
characters) to be transferred from LES 7.

b. From-Mobile message transfers

The LPES will initiate the call by sending an ASSIGNMENT REQUEST to LES 7. Upon reception of
the ASSIGNMENT REQUEST from the LPES, the simulator (LES) shall set the SIGNALLING
CHANNEL DESCRIPTOR to reflect a successful reception of the packet from the LPES(eg. if the
ASSIGNMENT REQUEST was received in slot 10 then the Descriptor is
6CF036AE00002000000000chks ) and transmit within 7 frames a LOGICAL CHANNEL
ASSIGNMENT.

This LOGICAL CHANNEL ASSIGNMENT is for an LPES Message at ch. 11110, with a frame offset
of 2 frames and slot no. 1; the test message from the MES is based on one frame (10368 symbols,
interleaver size N = 4) transmission.

5.1.7.3 Other functions

a. Land Mobile Alerting

The relevant bits in the "LES services" field of the bulletin board and Signalling Channel
Descriptors,of the LES and NCS simulators should be alterable for testing this function. It should be
possible to confirm that Land Mobile Alert packets are sent from the LPESs in the correct format.

The NCS/LES simulator should be able to respond with a Land Mobile Alert Acknowledgement set up
for the LPES ID. The acknowledgement is the same as the distress alert acknowledgement.

b. Performance Verification Testing

For conducting PVTs the LES simulator should be set up with a suitable test message, ie the 512 bit
test pattern suggested in Volume 3, Part 1, Chapter 2, section 6.3.3.1 of the SDM. It should also be
possible to change this to a longer message of approximately 4 kbytes.

Also, LES simulator should send a Test Distress Alert Acknowledgement to the LPES during PVT.

c. EGC Messages

For testing the EGC functions of EGC receivers and Class 2 and 3 INMARSAT-C LPESs, the
simulator should be set up to allow the assembly and insertion of single and double header EGC
packets into frames.

Recommended Test Procedures (RTPs), Page: 7


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

d. Continuation Packets

It should be possible to fill TDM frames with dummy packets and/or EGC packets and force relevant
signalling and data packets to be spilt across frames as continuation packets A and B in order to verify
that the LPES will detect and respond to such packets.

Recommended Test Procedures (RTPs), Page: 8


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

TABLE 1: PHASE 1 TEST PLAN FOR LPES

In this table tests prefixed with P are new or modified tests described in this section. All other tests are exactly
as described in section 2.

ITEM TEST DESIGNATION A T H P V SDM REF

1 ANTENNA TESTS

P1-A Gain Profile X 3.2*, 3.3.1*, 3.4.1*

1-B Polarisation and Axial Ratio X 3.2.2, 3.2.3

2 RECEIVING SYSTEM TESTS

2-A Noise Temperature X 3.3.1*

P2-B G/T Calculations 3.3.1*

2-C Tuning X X 3.3.4, 6.3.1

2-D Selectivity X X X 4.3

3 TRANSMITTING SYSTEM TESTS

3-A Output Power and Frequency Response X X X X 3.4.1*, 3.4.9

P3-B EIRP Calculations 3.4.1*

3-C Transmitted Spectrum X 3.4.2

3-D Transmitter Off Power Level X X X X 3.4.3

P3-E Spurious Outputs X X X 3.4.4*

3-F Harmonics Outputs X X 3.4.5

3-G Phase Noise X X 3.4.6*

3-H Tuning X X 3.4.7

3-I Frequency Accuracy and Stability X X X X 3.4.8

4 RECEIVER PERFORMANCE TESTS

P4-A Packet Error Rate X X X X 3.3.3*, 4.4, 4.5

P4-B Carrier and Frame Acquisition X X X X 4.4*, 4.6*

Recommended Test Procedures (RTPs), Page: 9


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM TEST DESIGNATION A T H P V SDM REF

5 TRANSMITTER PERFORMANCE TESTS

5-A Modulation Characteristics X X X 5.1

5-B First Generation Operation X 5.2

5-C Signalling Channel Characteristics X 5.3

5-D Message Channel Characteristics X 5.4

6 ACCESS CONTROL TESTS

6-A General Access Control X 6.1

P6-A/1 Land Mobile Alert Access Control X 8*

P6-A/2 PVT Access Control X 8*

6-B TDMA Synchronization X X 6.2.1

6-C Random Access X 6.2.2

P6-D Common Channel Selection X 6.3, 6.3.4*

P6-E Ocean Region Registration X 6.5*

6-F Idle and Busy Conditions X 6.6

7 MESSAGE PROCESSING

7-A Character Codes X 7.2

7-B Display Devices X X X X 7.3

7-C Keyboard X X X X 7.4

7-D SES Memory Capacity X X X 7.5

7-E DCE/DTE Interface Characteristics X X X 7.6.1 and Chap. 4 Sect.3

7-F Control Codes X 7.6.3 and Chap. 4

8 ALERTING FUNCTIONS

P8-A Alert Generator X 8.2*

P8-B Alert Activation X X X X 8.3*

Recommended Test Procedures (RTPs), Page: 10


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM TEST DESIGNATION A T H P V SDM REF

9 TESTING FUNCTIONS

9-A Fail-Safe and Monitoring X X 9.1, 9.2

P9-B Performance Verification and Commissioning X 9.3, 9.3.2*

10 ELECTROMAGNETIC COMPATIBILITY

10-A Mains Conducted Spurious Emissions X 10.2

Notes: A: ambient temperature

T: temperature

H: humidity

P: power

V: vibration

SDM REF: SDM Volume 3, Part 2 Chapter 2 section

* SDM Volume 3, Part 2, Chapter 7 section

Recommended Test Procedures (RTPs), Page: 11


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

5.2 TEST PROCEDURES

ITEM P1-A ANTENNA GAIN PROFILE

1 PURPOSE

The purpose of the test is to measure the antenna gain profile in elevation and azimuth over the
required frequency ranges. The results are to be used in Test Item P2-B and P3-B to show that the G/T
and EIRP requirements are met. Refer to Volume 3, Part 2, Chapter 7, Section 3.3.1 and 3.4.1 of the
SDM.

2 APPLICABILITY

All classes of LPESs

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

See Test Item 1-A.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item 1-A.

6 TEST PROCEDURE

See Test Item 1-A.

7 PASS/FAIL CRITERIA

The results will be used together with the test results from Test Item 2-A in the G/T calculations (Test
Item P2-B) and Test Item 3-A in the EIRP calculations (refer to Test Item P3-B) to demonstrate that
the G/T and EIRP will stay within the specified limits for LPES.

Recommended Test Procedures (RTPs), Page: 12


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM P2-B G/T CALCULATIONS

1 PURPOSE

The calculations shall demonstrate that the G/T of the LPES complies with the requirements stated in
Volume 3, Part 2, Chapter 7, Section 3.3.1.

2 APPLICABILITY

All classes of LPESs.

3 PROCEDURE

See Test Item 2-B, where the results of Test Items P1-A and 2-A are used in the calculations.

4 PASS/FAIL CRITERIA

For the LPES with a omnidirectional antenna, the antenna G/T shall be greater than the superimposed
mask for any elevation angle between 5o and 90o and any azimuth direction.

For the LPES with a directional antenna, the antenna G/T shall be greater than -23dB/K, in the
direction of the satellite, for any elevation angle between 5o and 90o.

Models of LPES found to exhibit marginal G/T performance may still be acceptable if the
manufacturer is able to demonstrate that the demodulator/decoder performance is such that the
equipment is able to meet the output performance (Packet Error Rate) of Volume 3, Part 2, Chapter 2,
Section 4.5 with all relevant signal impairments.

Recommended Test Procedures (RTPs), Page: 13


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM P3-B EIRP CALCULATIONS

1 PURPOSE

The calculations shall demonstrate that the maximum and minimum EIRP, calculated from results of
Test Items P1-A and 3-A, complies with the requirements of Volume 3, Part 2, Chapter 7, Section
3.4.1.

2 APPLICABILITY

All classes of LPESs.

3 PROCEDURE

See Test Item 3-B.

4 PASS/FAIL CRITERIA

The EIRP of LPESs shall not be less than +12 dBW in the direction of the satellite. The maximum
EIRP radiated in any direction shall not exceed +16 dBW.

Recommended Test Procedures (RTPs), Page: 14


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM P3-E SPURIOUS OUTPUTS

1 PURPOSE

The test shall verify that the spurious outputs of the transmitter comply with the requirements of
Volume 3, Part 2, Chapter 7, Section 3.4.4.

2 APPLICABILITY

All classes of LPESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

Temperature.

Humidity.

4 TEST SET-UP

See Test Item 3-E.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item 3-E.

6 TEST PROCEDURE

See Test Item 3-E.

In addition, the total power of all spurious outputs falling within each of the bands specified below
should be calculated, and the calculation should be submitted together with the results.

7. PASS/FAIL CRITERIA

All spurious and noise outputs (excluding harmonics) in the direction of maximum antenna gain must
be below the spectrum envelope defined by the following data points:

Frequency (MHz) EIRP / 3kHz (dBW)

< 1545.0 -85.0

1590.0 -70.0

1626.5 -48.0

1646.5 -48.0

> 1690.0 -70.0

In addition that the total radiated power (excluding harmonics) in the following bands should not
exceed the levels specified below:

Frequency Band Total Radiated Power

100 kHz-1000MHz -66 dBW

Recommended Test Procedures (RTPs), Page: 15


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

1000 MHz-1626.5 MHz -60 dBW

1646.5 MHz-4000 MHz -60 dBW

Recommended Test Procedures (RTPs), Page: 16


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM P4-A PACKET ERROR RATE

1 PURPOSE

The test shall verify that the performance of the receiver in terms of packet error rate (PER) is within
the limits specified in Volume 3, Part 2, Chapter 2, Section 4.5 with all the impairments* therein
specified in Volume 3, Part 2, Chapter 2, section 4.4.

Moreover, the degradation of receiver performance in the presence of out-of-band interfering signals
will be checked according to Volume 3, Part 2, Chapter 7, Section 3.3.3.

*Note: The short term doppler frequency variations need not be included. Furthermore, the C/M ratio
may be relaxed to 10 dB if the LPES has a directional antenna with an effective gain of not less than 6
dBi.

2 APPLICABILITY

All classes of LPESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

Temperature.

humidity.

Main power supply.

4 TEST SET-UP

See Test Item 4-A.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item 4-A.

6 TEST PROCEDURE

See Test Item 4-A except for step (i) where the out of band interference should be at the level of +100
dBc and cover the bands specified in Volume 3, Part 2, Chapter 7.

If any spurious response (PER degradation) is observed at this level due to the receiver's image
response, then the level of interference at which PER degradation occurs should be measured and
noted.

In addition, for the case of image response described above, the frequency band in which the image
response lies should be stated and information on potential sources of interference in that band should
be supplied.

7 PASS/FAIL CRITERIA

The packet error rate shall not exceed the following values:

Recommended Test Procedures (RTPs), Page: 17


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

PFD (dBW/M2) [C/No (dBHz)]* PER% (48) PER% (128)

-145.5 [35] 0.7 2.0

-146.5 [34] 2.7 8.0

Recommended Test Procedures (RTPs), Page: 18


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM P4-B CARRIER AND FRAME ACQUISITION

1 PURPOSE

The test shall verify that the performance of the receiver in terms of carrier/symbol/frame acquisition is
within the limits specified in Volume 3, Part 2, Chapter 2, Section 4.6 with all the impairments* stated
in Volume 3, Part 2, Chapter 2, Section 4.4.

*Note: The short term Doppler frequency variations need not be included. Furthermore, the C/M ratio
may be relaxed to 10 dB if the LPES has a directional antenna with an effective gain of not less than
6dBi.

2 APPLICABILITY

All classes of LPESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

Temperature

humidity

Main power supply

4 TEST SET-UP

See Test Item 4-B.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item 4-B.

6 TEST PROCEDURE

See Test Item 4-B.

7 PASS/FAIL CRITERIA

Refer to Test Item 4-B.

Recommended Test Procedures (RTPs), Page: 19


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM P6-A/1 LAND MOBILE ALERT ACCESS CONTROL TEST

1 PURPOSE

The test shall verify that the Land Mobile Alert protocol implemented in the LPES under test is
compliant with the requirements stated in Volume 1, Chapter 8, Volume 4, Chapter 11 and Volume 3,
Part 2, Chapter 7, Section 8.

2 APPLICABILITY

All classes of LPESs with Land Mobile Alert function.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

See Test Item 6-A.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item 6-A.

6 TEST PROCEDURE

LES with Demand Assigned TDM

Simulate a scenario in which the destination LES is operating with a Demand Assigned TDM (LES
TDM channel number FFFFH in network update or log-in acknowledgement packet) and initiate a
Land Mobile Alert.

Monitor and record the behaviour of the LPES (responses to the operator, signalling channel no. etc)
throughout the following tests.

a) Set the land Mobile alert not available and the maritime distress alert available in service field
of NCS bulletin board, and then attempt the transmission of the land Mobile alert.

Expected result: The transmission shall not occur and a prompt such as "Land Mobile Alerting
not available on current NCS" should be printed out or appear on disply.

b) Set the land Mobile alert available and the maritime distress alert not available in service field
and make the transmission of the Land Mobile Alert packet successful. Wait R+N1 frames
and send an Acknowledgement Packet.

LPES/NSIG/F0/LAND MOBILE ALERT - OK

NCS/NCC/F0+R+N1/LAND MOBILE ALERT ACK

Expected result: Alert OK

c) Repeat as in b), but send the Acknowledgement Packet R+N2 frames later.

LPES/NSIG/F0/LAND MOBILE ALERT - OK

Recommended Test Procedures (RTPs), Page: 20


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

NCS/NCC/F0+R+N2/LAND MOBILE ALERT ACK

Expected result: LPES should repeat the Land Mobile Alert automatically after the timeout on
the NCS Signalling channel:

LPES/NSIG/F1/LAND MOBILE ALERT - OK

NCS/NCC/F1+R+N1/LAND MOBILE ALERT ACK

d) Repeat as in b) and make the transmission of the Land Mobile Alert packet fail.

LPES/NSIG/F0/LAND MOBILE ALERT - FAIL

Expected result: LPES should repeat the Land Mobile Alert MaxC times on the NCS
Signalling channel.

LES Operating with a Permanent TDM

a) Set the land Mobile alert not available and the maritime distress alert available in service field
of LES bulletin board, and then attempt the transmission of the land Mobile alert.

Expected result: The transmission shall not occur and a prompt such as "Land Mobile Alerting
not available on current LES" should be printed out or appear on disply, and then LPES
should try NCS.

(b) Set the land Mobile alert available and the maritime distress alert not available in service field
and make the transmission of the Land Mobile Alert packet successful. Wait R+N1 frames
and send an Acknowledgement Packet.

LPES/CSIG/F0/LAND MOBILE ALERT - OK

LES/TDM/F0+R+N1/LAND MOBILE ALERT ACK

Expected result: Alert OK

(c) Repeat as in b), but send the Acknowledgement Packet R+N2 frames later.

LPES/CSIG/F0/LAND MOBILE ALERT - OK

LES/TDM/F0+R+N2/LAND MOBILE ALERT ACK

LPES/CSIG/F1/LAND MOBILE ALERT - OK

LES/TDM/F1+R+N2/DILAND MOBILE ALERT ACK

---

LPES/CSIG/Fn/LAND MOBILE ALERT - OK

LES/TDM/Fn+R+N2/LAND MOBILE ALERT ACK

Expected result: LPES should repeat the Land Mobile Alert MaxCD times automatically after
each timeout on the LES Signaling Channel. Then the LPES should send the Land Mobile
Alert on the NCS Signaling Channel.

Recommended Test Procedures (RTPs), Page: 21


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

LPES/NSIG/Fn1/LAND MOBILE ALERT - OK

NCS/NCC/Fn1+R+1/LAND MOBILE ALERT ACK

(d) Repeat as in c), but set the Land Mobile Alert not available and the maritime distress alert
available in service field of NCS bulletin board. Send the Acknowledgement Packet from the
LES after R+N2 frames. make the next Land Mobile Alert Packet successful again and send
the Acknowledgement Packet after a further R+N2 frames.

LPES/CSIG/F1/LAND MOBILE ALERT - OK

LES/TDM/F1+R+N2/LAND MOBILE ALERT ACK

LPES/CSIG/F2/LAND MOBILE - OK

LES/TDM/F2+R+N2/LAND MOBILE ALERT ACK

---

LPES/CSIG/Fn/LAND MOBILE ALERT - OK

LES/TDM/Fn+R+N2/LAND MOBILE ALERT ACK

Expected result: LPES should repeat the Land Mobile Alert MaxCD times automatically after
each timeout on the LES Signalling Channel. Then the LPES should not send the Land Mobile
Alert on the NCS Signalling channel.

(e) Repeat as in b). but make the transmission of the Land Mobile Alert Packet fail.

LPES/CSIG/F0/LAND MOBILE ALERT - FAIL

Expected result: LPES should repeat the Land Mobile Alert MaxC times on the LES Signaling
Channel and then retune to the NCS and send the Land Mobile Alert on the NCS Signalling
channel:

LPES/NSIG/F1/LAND MOBILE ALERT - OK

NCS/NCC/F1+R+N1/LAND MOBILE ALERT ACK

(f) Repeat as in e) and send the Acknowledgement Packet from the NCS after R+N2 frames.

LPES/CSIG/F0/LAND MOBILE ALERT - FAIL

Expected result: LPES should repeat the Land Mobile Alert MaxC times on the LES
signalling channel and then retune to the NCS and resend the Land Mobile Alert on the NCS
Signalling channel:

LPES/NSIG/F1/LAND MOBILE ALERT - OK

NCS/NCC/F1+R+N2/LAND MOBILE ALERT ACK

Expected result: LPES should repeat the Land Mobile Alert on the NCS signalling channel.
Note any further action of the LPES (e.g. operator prompts).

Recommended Test Procedures (RTPs), Page: 22


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(g) Make 2 LES Signalling Channels available, set the land Mobile alert available in service field
of the bulletin board and set SCDs to show that one is a general signalling channel ( i.e. Land
Mobile Alerting flag set in addition to other flags) and the other is a dedicated Land Mobile
channel (i.e. only Land Mobile Alert flag set). Make the transmission of the Land Mobile
Alert packet successful. Wait R+N1 frames and send an Acknowledgement Packet.

LPES/CSIG/F0/LAND MOBILE ALERT - OK

LES/TDM/F0+R+N1/LAND MOBILE ALERT ACK

Expected result: Alert should be received on the dedicated Land Mobile channel and OK.

(h) Make 2 LES Signalling Channels available, Set the land Mobile alert available in service field
of the bulletin board and set SCDs to show that one is a general signalling channel ( i.e. Land
Mobile Alerting flag set in addition to other flags) and the other is set to show that Land
Mobile Alerting is not available (i.e. no Land Mobile Alert flag set). Make the transmission of
the Land Mobile Alert packet successful. Wait R+N1 frames and send an Acknowledgement
Packet.

LPES/CSIG/F0/LAND MOBILE ALERT - OK

LES/TDM/F0+R+N1/LAND MOBILE ALERT ACK

Expected result: Alert should be received on the general signalling channel and OK.

(i) Repeat as in e), but set the NCS to have a dedicated land Mobile channel and a general
signalling channel . Make LPES land Mobile alert fail, and then LPES transmits the Land
Mobile Alert automatically to NCS .

LPES/CSIG/F0/LAND MOBILE ALERT - FAIL

.........

LPES/NSIG/F0/LAND MOBILE ALERT - OK

NCS/NCC/F0+R+N1/LAND MOBILE ALERT ACK

Expected result: Alert should be received on the dedicated Land Mobile channel and OK.

(j) Repeat as in g), but set the LES to have a dedicated maritime distress channel and a general
signalling channel , also, both land Mobile and maritime distress alerts available in service
field of the bulletin board

LPES/CSIG/F0/LAND MOBILE ALERT - OK

LES/TDM/F0+R+N1/LAND MOBILE ALERT ACK

Expected result: Alert should be received on the general signalling channel and OK.

Recommended Test Procedures (RTPs), Page: 23


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM P6-A/2 PVT ACCESS CONTROL TEST

1 PURPOSE

The test shall verify that PVT protocols implemented in the LPES under test are compliant with the
requirements stated in Volume 1, Chapter 8, Volume 4, Chapter 11 and Volume 3, Part 2, Chapter 7,
Section 9.

2 APPLICABILITY

All classes of LPESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

See Test Item 6-A.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item 6-A.

6 TEST PROCEDURE

See Test Item 6-A, Part 2, Section 6. However, the alert packet contents should be as defined for the
Land Mobile Alert and the Land Mobile Alert flag in the service field of a LES bulletin board and in
the signalling channel descriptor shall be set unavailable.

7 PASS/FAIL CRITERIA

Refer to Test Item 6-A, Part 2, Section 6.

Recommended Test Procedures (RTPs), Page: 24


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM P6-D COMMON CHANNEL SELECTION

1 PURPOSE

The test shall verify the LPES's memory capability in respect of the NCS common channels and their
selection under different network scenarios as indicated in Volume 3, Part 2, Chapter 2, Section 6.3
and Volume 3, Part 2, Chapter 7, Section 6.3.4.

2 APPLICABILITY

All classes of LPESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

See Test Item 6-D.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item 6-D.

6 TEST PROCEDURE

See Test Item 6-D. However, the NCS only transmit FleetNet EGC in Test Item 6-D, Part B.

For LPESs, the alternative test procedure in Part C may be as follows:

(a) Enter the 76 NCS channels in the LPES memory. Set configuration LESs in the simulator.

(b) Set the preferred and the current NCS to 144 (12580) and the simulator to 144(12580).

(c) Transmit two NCS common channels, one of which is set to a global beam NCS common
channel with NCS ID 144 and power level [X dBw], and the other is set to a spot beam
common channel with NCS ID 150, and the power level [X+5dBw].

(d) Connect the simulator and the LPES.

(e) Power on the LPES.

(f) Check the NCS ID which the LPES tuned to.

(g) Transmit two NCS common channels, one of which is set to a global beam NCS common
channel with NCS ID 244 and power level [X dBw], and the other is set to a spot beam
common channel with NCS ID 250, and the power level [X-5dBw].

(h) After the LPES could not synchronise to the NCS 144, check that a prompt to tune to other
NCS channels was sent to the operator via the DTE.

(i) Start tuning to the NCS 250 manully.

(j) Check that the LPES tuned to the spot beam NCS 250 and Log-in request was sent.

Recommended Test Procedures (RTPs), Page: 25


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

7 PASS/FAIL CRITERIA

Refer to Test Item 6-D.

For the LPES,the criteria of the alternative test procedure in Part C shall be as follows:

step f The LPES tunes to NCS 144.

step h The prompt is sent to the operator.

step j The LPES tunes to NCS 250.

Recommended Test Procedures (RTPs), Page: 26


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM P6-E OCEAN REGION REGISTRATION

1 PURPOSE

The test shall verify the LPES function in respect of the Ocean Region registration as indicated in
Volume 3, Part 2, Chapter 7, Section 6.5.

2 APPLICABILITY

All classes of LPESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

See Test Item 6-E.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item 6-E.

6 TEST PROCEDURE

(a) Enter the 76 NCS IDs and channel numbers into the LMES.

(b) Set the LMES preferred ocean region to AOR-E,144, and the simulator NCS ID to 144 with
the simulator disconnected.

(c) Turn the LMES off and connect the simulators and the LMES.

(d) Turn the LMES on.

(e) Initiate a log-in command.

(f) Repeat steps (c) to (d) with the simulator NCS ID 150 (1100010).

(g) Initiate a scanning command.

(h) Repeat steps (c) to (d) with the simulator NCS ID 244 (1258010).

(i) Initiate a scanning command.

(j) Set the preferred ocean region off and repeat steps (c) to (d) with the simulator NCS ID 244.

(k) Keep the preferred ocean region off and repeat steps (c) to (d) with the simulator NCS ID 344.

(l) Set the LMES preferred NCS to 150 and the simulator NCS ID to 150. Repeat steps (c) to (d).

(m) Repeat step (l) with the simulator NCS ID 244.

(n) Repeat step (l) with the simulator NCS ID 151.

(o) Repeat step (l) with the simulator NCS ID 144.

Recommended Test Procedures (RTPs), Page: 27


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(p) Repear step (l), after synchronisation, send a network update packet with new information and
a new version number.

(q) Send manually a request for log-out from the LMES and inspect via the DTE the packet
received by the simulator.

7 PASS/FAIL CRITERIA

The following responses and status of the LMES shall be observed:

step d, j, l The MES should tune to the NCS common channel but not send a log-in packet
automatically;

step e A valid log-in packet is transmitted;

step f, h, k, m, n,o

A prompt sent to the operator via the DTE for manually initiating NCS scanning or
tuning to another NCS common channel;

step g The MES should tuen to NCS 150 and send a valid log-in packet automatically;

step i The MES should tuen to NCS 244 and send a valid log-in packet automatically;

step p. The MES should accept the new network update packet and overwrite the old one.

step q A valid log-out transmitted.

Recommended Test Procedures (RTPs), Page: 28


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM P8-A ALERT GENERATOR

1 PURPOSE

The test shall demonstrate that the Land Mobile Alert message is assembled and transmitted by the
LPES according to the format specified in Volume 3, Part 2, Chapter 7, Section 8.3.

2 APPLICABILITY

All classes of LPESs intending to include the Land Mobile Alert function.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

4 TEST SET-UP

See Test Item S8-A, Figure S8-A

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item S8-A.

6 TEST PROCEDURE

See Test Item S8-A. However, the packet contents should be as defined for Land Mobile.

Also, one more test, step c/1), will be added. When step c) is completed, repeat this test 10 minutes
later without updating the position.

7 PASS/FAIL CRITERIA

Refer to Test Item S8-A. However,the packets received should correspond to the format specified in
Volume 3, Part 2, Chapter 2, Volume 1, Chapter 8 and Volume 4, Chapter 11.

Recommended Test Procedures (RTPs), Page: 29


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM P8-B ALERT ACTIVATION

1 PURPOSE

The test will demonstrate that the land Mobile alert activation function of the LPES complies with the
requirements given in Volume 3, Part 2, Chapter 7, Section 8.4 under different environmental
conditions. The fail-safe operation of a remote distress button facility (when provided) will be also
checked.

2 APPLICABILITY

All classes of LPESs intending to include the Land Mobile Alert function.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

Temperature

Humidity

Power supply

4 TEST SET-UP

See Test Item S8-B, Figure S8-B.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item S8-B.

6 TEST PROCEDURE

See Test Item S8-B. However, the packet contents should be as defined for Land Mobile.

7 PASS/FAIL CRITERIA

Refer to Test Item S8-B and the packet contents shall be as defined for Land Mobile.

Recommended Test Procedures (RTPs), Page: 30


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM P9-B PERFORMANCE VERIFICATION AND COMMISSIONING


TESTS

1 PURPOSE OF THE TEST

This test shall verify that the LPES correctly perform the Performance Verification and Commissioning
Tests as described in Volume 3, Part 2, Chapter 7, Section 9.3 (and Volume 1, Chapter 4, Section 10).

2 APPLICABILITY

All classes of LPESs.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

4 TEST SET-UP

See Test Item 9-B, Figure 9-B.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item 9-B.

6 TEST PROCEDURE

(a) Send a Performance Verification test request from the LPES to the NCS/CES simulator.
Verify that the request transmitted is correct.

(b) Send a test announcement from the NCS/LES simulator to the LMES (or LPES) on the NCS
common channel.

(c) Verify that the LPES transmits a valid assignment response to the simulator on the signalling
channel.

(d) Send the "test pattern" message from the simulator to the LPES on the LES TDM channel,
with one or more errors in the test message.

The test pattern below may be used.

FF83 DF17 3209 4ED1 E7CD 8A91 C6D5 C4C4

4021 184E 5586 F4DC 8A15 A7EC 92DF 9353

3018 CA34 BFA2 C759 678F BA0D 6DD8 2D7D

540A 5797 7039 D27A EA24 3385 ED9A 1DE0

Following the message, send a request for acknowledgement. Verify that the LPES requests the LES to
re-transmit the message.

(e) Transmit the test pattern from the LES without errors, followed by a request for
acknowledgement.

(f) Verify that the LPES sends an acknowledgement to the LES on the signalling channel.

Recommended Test Procedures (RTPs), Page: 31


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(g) Transmit a logical channel clear from the simulator to the LPES.

(h) Verify that the LPES immediately transmits an assignment request to the LES on the
signalling channel.

(i) Send a logical Channel Assignment from the NCS/LES simulator on the LES TDM.

(j) Verify that the LPES automatically transmits the message received from the LES (in (d)
above). The information field should be set to one byte and contain an eight bit representation
of the (current) bulletin board error rate.

(k) Transmit a re-transmission request (negative acknowledgement) from the NCS/LES simulator
on the LES-TDM.

(l) Verify that the LPES resends the errorred packets.

(m) Transmit a positive acknowledgement from the NCS/LES simulator on the LES TDM,
followed by a distress test request.

(n) For the LPES, a prompt ,indicating a Land Mobile alert test shall be activated automatically
and immediately after receiving the alert test request packet from the LES, shall appear on the
display

(o) Transmit a Land Mobile alert from the LPES and verify that a Land Mobile alert test is sent to
the LES.

(p) Send a test result packet from the LES (Volume 1, Chapter 4, Section 10.2.5). Verify that the
LPES sends a test result acknowledgement packet and stores and displays the test results.

(q) Clear the call from the LES.

(r) Initiate a PVT at the NCS using a different test message (the test message should be 4 kbytes)
to that shown in d. Verify that the message transferred in the From-Mobile direction is
identical to that sent in the To-Mobile direction and that the test is completed successfully.

(This test is also covered in detail in Test Item L6-A).

7 PASS/FAIL CRITERIA

The LPES must operate according to the protocols defined in Volume 3, Part 2, Chapter 7, Section 9.3 .
The test results shall be made available for the operator.

Recommended Test Procedures (RTPs), Page: 32


Section 5: Phase 1 Tests for Land Portable Earth Stations
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6. PHASE 1 TESTS FOR EGC RECEIVER EQUIPMENT

6.1 INTRODUCTION AND REQUIRED TESTS

6.1.1 GENERAL

The purpose of these tests is to demonstrate that all the relevant INMARSAT performance requirements are
satisfied by EGC receiver equipment over the full range of environmental conditions in which it is designed to
operate. This Section outlines the minimum requirements of a test plan for in-factory testing of such equipment
(equivalent to the Phase I tests for Inmarsat-C MESs). The test procedures and test data sheets presented herein
can be used by manufacturers in developing their detailed test plans.

No formal tests are described for verifying the correct operation of EGC receivers with live satellite signals.
However, INMARSAT recommends that manufacturers plan and conduct suitable tests in collaboration with
LES operators and copy the results to INMARSAT. In particular, these tests should verify and demonstrate the
SAFETYNET capabilities of the receiver.

6.1.2 REQUIRED TESTS

As a minimum, the functions and characteristics listed in Table 1 shall be tested with the indicated variations in
environmental conditions. Each test procedure for the tests listed in Table 1 makes reference to the relevant
requirements in SDM Volume 3, Part 2, Chapter 2.

Tests E4-A, E4-D, E4-E, E4-F and E5-A are mandatory for all EGC receivers irrespective of equipment
configuration. The remaining tests are necessary for certain equipment configuration only.

Four basic equipment variants are envisaged as described in SDM Volume 3, Part 2, Chapter 6, Section 1.2
which offer an EGC reception capability:

- Class 2 Inmarsat-C terminal;

- Class 3 Inmarsat-C terminal;

- Class 0-Option 1 (standalone EGC receiver);

- Class 0-Option 2 (EGC receiver to complement a Inmarsat-A terminal).

The type approval tests required for each of these basic types are summarised in Table 2. Note that Class 2,
Class 3 and Class 0-Option 2 equipment may be exempt from certain tests under the conditions stated in Table 2
and in the corresponding test procedures.

Equipment which does not readily fall into any of the four basic categories or which is implemented in a
different manner to that assumed in the test procedures will be dealt with on a case by case basis. If equipment
is to be designed to complement a type approved Inmarsat-A terminal (Class 0-Option 2) a clear indication shall
be given of its impact on the Inmarsat-A terminal design and the resultant type approval implications for that
equipment.

The test procedures assume that all EGC receivers to be tested provide both FLEETNET and SAFETYNET
capabilities. Some of the checks contained in each test procedure are not applicable if a manufacturer should

Recommended Test Procedures (RTPs), Page: 1


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

elect to implement either a FLEETNET-only or a SAFETYNET-only receiver (see SDM Volume 3, Part 2,
Chapter 6, Section 9).

6.1.3 FUNCTIONAL CHECKS

The manufacturer shall use a test simulator (NCS/LES simulator) and an RF simulator to verify the correct
operation of EGC receiver equipment. The former shall be capable of simulating EGC message transmissions
and the latter shall simulate the RF environment in which the EGC equipment will be used.

6.1.4 TESTS PERFORMED BY ORIGINAL EQUIPMENT MANUFACTURERS

For some subsystems, the MES manufacturer may not be the original manufacturer (OEM). In such cases, the
MES manufacturer may elect to submit the test procedures and results of the OEM, rather than repeat all tests.
Use of OEM test procedures and results to satisfy the EGC receiver test requirements may suffice if the
procedures and results are clearly adequate. The test procedures presented here are suggested as a suitable basis
for the relevant tests to be conducted by the OEM.

6.1.5 ENVIRONMENTAL CONDITIONS TEST

Procedures for these tests are as stated in the section 2.1 of this document.

Recommended Test Procedures (RTPs), Page: 2


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

TABLE 1: EGC RECEIVER TEST SUMMARY

In this table tests prefixed with E are new or modified tests described in this section. All other tests are exactly
as described in section 2.

ITEM TEST DESIGNATION A T H P V SDM REF

1 ANTENNA TESTS

1-A Antenna Gain Profile X 3.2

1-B Polarisation and Axial Ratio X 3.2

2 RECEIVING SYSTEM TESTS

2-A Receiving System Noise Temperature X 3.3.1

2-B G/T Calculations 3.3.1

E2-C Receiver Tuning X X 3.3.4, 6.3.1

2-D Receiver Selectivity X X X 4.3

3 RECEIVER PERFORMANCE TESTS

3-A* Packet Error Rate X X X X X 4.5

4 MESSAGE PROCESSING

4-A* Character Codes X 7.2

4-B* Output Devices X X X X X 7.3

4-C* Keyboard X X X X X 7.4

E4-D Memory Capacity X 7.7.3, 7.5

E4-E Receiver Addressing X 7.7

E4-F Error Detection X 7.7.5

E4-G Sequence Number Handling X 7.7.4

E5 DISTRESS ALERTING FUNCTIONS

E5-A Distress Messages X 7.7.6

Recommended Test Procedures (RTPs), Page: 3


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6 ELECTROMAGNETIC COMPATIBILITY

6-A* Mains Conducted Spurious Emissions X 10

7 PHYSICAL CHARACTERISTICS TESTS

7-A* Vibration Frequency Response X 11

7-B* Rain Test X 11

Notes: A: ambient temperature

T: temperature

H: humidity

P: power

V: vibration

SDM REF SDM Volume 3, Part 2, Chapter 8 reference item

*: 3-A* - 4-A

4-A* - 7-A

4-B* - 7-B

4-C* - 7-C

6-A* - 10-A

7-A* - 11-A

7-B* - 11-B

Recommended Test Procedures (RTPs), Page: 4


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

TABLE 2: TESTS REQUIRED FOR VARIOUS EGC RECEIVER CONFIGURATIONS

Class 2 Class 3 Option 1 Option 2

1-A Antenna Gain Profile X

1-B Polarisation and Axial Ratio X

2-A Receiving System Noise Temperature X1 X X2

2-B G/T Calculations X1 X X2

E2-C Receiver Tuning X1 X X

2-D Receiver Selectivity X1 X X

3-A Packet Error Rate X1 X X

E4-A Character Codes X X X X

E4-B Output Devices X3 X3 X X4

4-C Keyboard X3 X3 X X4

E4-D Memory Capacity X X X X

E4-E Receiver Addressing X X X X

E4-F Error Detection X X X X

E4-F Sequence Number Handling X X X X

E5-A Distress Messages X X X X

6-A Mains Conducted Spurious Emissions X5 X X

7-A Vibration Frequency Response X5 X X

7-B Rain Test X

X = test required

Notes:

1. These tests are unnecessary if the EGC receiver is an exact duplicate of the Inmarsat-C receiver and the latter has
been type approved by INMARSAT.

2. Manufacturers may elect to trade-off excess G/T against demodulator performance (e.g. hard decision Viterbi
decoding instead of soft decision decoding).

3. These tests are unnecessary for EGC receivers which share the peripheral devices used by the Inmarsat-C
transceiver.

4. It is assumed that dedicated peripheral devices are required for the EGC receiver equipment.

5. It is assumed that the EGC receiver is integrated with the Inmarsat-C transceiver and shares a common power
supply.

Recommended Test Procedures (RTPs), Page: 5


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

6.2 TEST PROCEDURES

ITEM E2-C RECEIVER TUNING

1 PURPOSE

The test shall verify that the EGC receiver complies with the requirements of SDM Volume 3, Part 2,
Chapter 8, Section 3.2 and 6.3.1. This will ensure that the receiver will tune to any channel in the band
1530.0 to 1545.0 MHz, in increments of 5 kHz, and that the frequency to which the receiver tunes
corresponds to the correct channel number.

2 APPLICABILITY

This Test is mandatory for standalone EGC receivers and EGC equipment designed to operate with
Inmarsat-A terminals (Options 1 and 2). The test is not required for Class 2 Inmarsat-C transceivers
and is only required for Class 3 transceivers if the EGC receiver is not an exact duplicate of the type-
approved Inmarsat-C receiver.

3 ENVIRONMENTAL CONDITIONS

Normal ambient.

Temperature.

4 TEST SET-UP

See Test Item 2-C, where the MES is replaced by the EGC receiver in the block diagram.

5 REQUIRED TEST EQUIPMENT AND FACILITIES

See Test Item 2-C.

6 TEST PROCEDURE

(a) Connect the NCS/LES simulator to the EGC receiver antenna port and adjust the level to
nominal. (For EGC receivers designed to interface with an existing INMARSAT mobile earth
station, the NCS/LES simulator IF output shall be used).

(b) Input the following information into the receiver:

NCS Channels: 1 = 11080, 1537.7 MHz

2 = 12580, 1541.45 MHz

3 = 10840, 1537.1 MHz

4 = 13900, 1544.75 MHz

5 = ch 8000, 1530.000 MHz

6 = ch 8002, 1530.005 MHz

7 = ch 8006, 1530. 015 MHz

Recommended Test Procedures (RTPs), Page: 6


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

` 18 = ch 13994, 1544.985 MHz

19 = ch 13998, 1544.995 MHz

20 = ch 14000, 1545.000 MHz

(c) Tune the EGC receiver to ch. no. 11080 and wait for synchronisation to be achieved.

(d) Transmit a valid EGC test message and check that the message is received and displayed
and/or printed error-free.

(e) Repeat step (d) for each of the remaining NCS channels [2..7, 18..20].

(f) Repeat steps (d) and (e) under high and low temperature conditions (+45oC and 0oC
respectively).

7 PASS/FAIL CRITERIA

All EGC messages shall be received error-free at all frequencies.

Recommended Test Procedures (RTPs), Page: 7


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM E4-A CHARACTER CODES

1 PURPOSE OF THE TEST

The test shall verify that the receiver is able to display at least all the characters of the International
Reference Version of International Alphabet 5 (IA 5) as defined in CCITT Rec. T.50.

Refer to SDM Volume 3, Part 2, Chapter 8, Section 7.2.

2 APPLICABILITY

All types of EGC receivers; some steps in the procedure are applicable only if additional/optional
character sets are available for display (for example, the ITA 2 character set as defined in CCITT Rec.
S.1).

3 ENVIRONMENT CONDITIONS

Normal ambient only.

4 TEST SET-UP

Refer to figure 6-C

5 REQUIRED TEST EQUIPMENT

(a) NCS/LES simulator.

6 TEST PROCEDURE

(a) Connect the NCS/LES simulator to the EGC receiver antenna port. (For EGC receivers
designed to interface with an existing INMARSAT mobile earth station, the NCS/LES
simulator IF output shall be used).

(b) Tune the simulator to channel no. 11080 1537.7 MHz, AOR-W).

(c) Start sending in every frame a valid EGC message (with a service code and address which will
be recognized by the EGC receiver) containing a sequence comprising all IA5 characters.

(d) Tune the EGC receiver to ch. no. 11080 (AOR-W) and after the synchronization has been
achieved examine the output and record the result. The test results should include a printout
of the received message text and a hexadecimal listing of the corresponding EGC packets.

(e) If different character sets are available for the display unit, repeat steps (c) and (d) for each
additional character set using the appropriate Presentation Code in EGC packet header.

7 PASS/FAIL CRITERIA

The receiver shall produce an error-free received EGC message with all the characters in the test packet
correctly displayed, for all character sets available. Where applicable, character set options should be
stated (e.g. national options for ITA2 as defined in CCITT Rec. S.1, Section 4.2).

Recommended Test Procedures (RTPs), Page: 8


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM E4-B OUTPUT DEVICE(S)

1 PURPOSE OF THE TEST

The test shall demonstrate that the receiver's output device(s) comply with the requirements as stated in
SDM Volume 3, Part 2, Chapter 8, Section 7.3.

2 APPLICABILITY

The test is applicable to all type of EGC receivers. Steps (e)-(h) inclusive of the test procedure
(environmental testing) may be skipped when the EGC receiver is a functional unit of a Inmarsat-C
MES (Class 2 or 3) which has been successfully tested for type approval and the output device is
shared by both subsystems.

3 ENVIRONMENTAL CONDITIONS

Normal ambient

Temperature

Humidity

Main power supply

Vibration

4 TEST SET-UP

See figure 7-B.

5 REQUIRED TEST EQUIPMENT

(a) NCS/LES simulator.

(b) Power supplies with variable voltage and/or frequency, one for each power interface provided
for the EGC receiver (i.e. a.c. mains, d.c. mains, battery).

(c) Temperature chamber

(d) Vibration table

Items (b), (c) and (d) are required if the conditions stated in Section 2 are not satisfied.

6 TEST PROCEDURE

(a) Connect the NCS/LES simulator to the EGC receiver antenna port and adjust the level to
nominal. (For EGC receivers designed to interface with an existing INMARSAT mobile earth
station, the NCS/LES simulator IF output shall be used).

(b) Tune the simulator to channel no.11080 (1537.7 MHz, AOR-W).

(c) Tune the EGC receiver to ch. no.11080 and wait for synchronisation to be achieved.

Recommended Test Procedures (RTPs), Page: 9


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(d) Transmit a valid EGC message containing 30 lines of QBF* and 40 lines of RY* and check
that the message is displayed and/or printed error-free with at least 40 characters per line.

(e) Repeat step (d) at +45°C and 0°C.

(f) Repeat step (d) with vibration in each of the three mutually orthogonal directions.

(g) Repeat step (d) with the relevant power supply variations.

(h) Repeat step (d) at +40°C with +95% relative humidity.

(i) Transmit a valid message containing no carriage return or line feed characters which is at least
two printed lines long (normal, ambient conditions). Check that any word which cannot be
displayed in full on one line is transferred to the next.

(j) Transmit a valid SAFETYNET message (e.g. code 04H). Check that the message is annotated
and displayed or printed with the time (UTC) and date of reception.

(k) If a printer is fitted, simulate a "paper-low" condition and check that an audible alarm is
activated.

(l) Send an EGC message with Distress Priority and check that the (distress) audible alarm is
activated and is clearly distinguishable from the "paper-low" audible alarm.

(m) Reset the "paper-low" alarm and check that the distress alarm is still activated.

(n) Reset the distress alarm.

*Notes:

QBF = THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG 1234567890

RY = RYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRY

7 PASS/FAIL CRITERIA

All of the indicated tests shall produce a positive result.

Recommended Test Procedures (RTPs), Page: 10


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM E4-D MEMORY CAPACITY

1 PURPOSE OF THE TEST

The test shall demonstrate that the memory capacity and characteristics comply with the requirements
indicated in SDM Volume 3, Part 2, Chapter 8, Sections 7.7.3 and 7.5.

2 APPLICABILITY

In general the test is applicable to all type of EGC receivers. However, some steps in the test procedure
need not be performed if the receiver is of the FLEETNET only or SAFETYNET only type (i.e. steps
(i), (j), (k), (l), (p), (q), (r) and (s) for FLEETNET only receivers and steps (m), (n) and (o) for
SAFETYNET only receivers).

3 ENVIRONMENTAL CONDITIONS

Normal ambient

4 TEST SET-UP

See figure 7-D.

5 REQUIRED TEST EQUIPMENT

(a) NCS/LES simulator.

6 TEST PROCEDURE

(a) Connect the NCS/LES simulator to the EGC receiver antenna port and adjust the level to
nominal. (For EGC receivers designed to interface with an existing INMARSAT mobile earth
station, the NCS/LES simulator IF output shall be used).

(b) Load the following information into the receiver memory:

NCS Channels

1 = ch. 11080, 1537.7 MHz (AOR-W); 2 = ch. 12580, 1541.45 MHz (POR);

3 = ch. 10840, 1537.1 MHz (IOR); 4 = ch.13900, 1544.75 MHz (spare);

5 = ch. 8000, 1530.0 MHz; 6 = ch. 8002, 1530.005 MHz;

7 = ch. 8004, 1530.01 MHz; 8 = 8006, 1530.015 MHz;

9 = ch. 8008, 1530.02 MHz; 10 = ch. 8010, 1530.025 MHz;

11 = ch. 8012, 1530.03 MHz; 12 = ch. 80014, 1530.035 MHz;

13 = ch. 12000, 1540.0 MHz; 14 = ch. 12100, 1540.25 MHz;

15 = ch. 12200, 1540.5 MHz; 16 = ch. 12300, 1540.75 MHz;

17 = ch. 13994, 1544.985 MHz; 18 = ch. 13996, 1544.99 MHz;

19 = ch. 13998, 1544.995 MHz; 20 = 14000, 1545.0 MHz;

Recommended Test Procedures (RTPs), Page: 11


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Closed Network IDs (unnecessary for SAFETYNET only receivers)

1 = 11111; 2 = 22222;

3 = 33333; 4 = 44444;

5 = 55555; 6 = 6666;

7 = 7777; 8 = 8888;

9 = 9999; 10 = 10000;

Message Addressing Information

Mobile position: 45° 12'S, 120° 39'E;

Navarea: 10;

Navtex code: UD;

Fixed Area Code: 8641235

(c) Tune the EGC receiver to channel number 11080 and wait for synchronisation to be achieved.

(d) Transmit eight different, valid EGC test messages each with a length of at least 4096 bytes.
Check that all messages are displayed and/or printed error-free.

(e) Repeat step (d). Check that all messages are displayed and/or printed error-free.

(f) Repeat step (d) with a single, valid EGC message 32768 bytes long. Check that the message
is displayed and/or printed error-free.

(g) Turn off the power to the EGC receiver and leave the receiver off for at least six hours.

(h) Turn on the power to the EGC receiver. Examine the receiver memory and verify that the
NCS common channel frequencies, the Closed Network IDs and the message addressing
information remain as specified in step (b).

(i) Tune the EGC receiver and the NCS/LES simulator to channel number 12580 and wait for
synchronisation to be achieved. Send the following EGC packet (routine priority) and record
the response of the receiver:

[24H] [45° S, 120° E, 60 nmi]

(j) Tune the EGC receiver and the NCS/LES simulator to channel number 8000 and wait for
synchronisation to be achieved. Send the following EGC packet (routine priority) and record
the response of the receiver:

[13H] [10,UD]

(k) Tune the EGC receiver and the NCS/LES simulator to channel number 8002 and wait for
synchronisation to be achieved. Send the following EGC packet (routine priority) and record
the response of the receiver:

Recommended Test Procedures (RTPs), Page: 12


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

[73H] [8641235]

(l) Tune the EGC receiver and the NCS/LES simulator to channel number 8010 and wait for
synchronization to be achieved. Send the following EGC packet (routine priority) and record
the response of the receiver:

[31H] [10]

(m) Tune the EGC receiver and the NCS/LES simulator to channel number 12200 and wait for
synchronisation to be achieved. Send the following EGC packet and record the response of
the receiver:

[group call] [11111]

(n) Tune the EGC receiver and the NCS/LES simulator to channel number 13998 and wait for
synchronisation to be achieved. Send the following EGC packet and record the response of
the receiver:

[group call] [55555]

(o) Tune the EGC receiver and the NCS/LES simulator to channel number 14000 and wait for
synchronisation to be achieved. Send the following EGC packet and record the response of
the receiver:

[group call] [10000]

(p) Tune the EGC receiver and the NCS/LES simulator to channel number 11080 and wait for
synchronisation to be achieved. Send the following EGC packets with the indicated priority
and record the response of the receiver:

p.1 [04H] [35° S, 130° E, 5°, 5°] [safety]

p.2 [04H] [35° S, 130° E, 5°, 5°] [routine]

p.3 [13H] [11,WD] [urgent]

p.4 [13H] [11,WD] [routine]

p.5 [14H] [35° S, 130° E, 10 nmi] [distress]

p.6 [31H] [11] [urgent]

(q) Download new ENIDs until the memory for ENIDs is full.

q.1 Download one more ENID.

q.2 Inhibit an ENID previously downloaded.

q.3 Download a new NID

(r) Allow at least twelve hours to elapse from the last update of the message addressing
information.

(s) Repeat step (p).

Recommended Test Procedures (RTPs), Page: 13


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

7 PASS/FAIL CRITERIA

The EGC receiver shall respond as follows:

(d) All messages are displayed and/or printed error-free.

(e) All messages are displayed and/or printed error-free. Messages received in step (d) may be
overwritten and lost.

(f) The message is displayed and/or printed error-free. Messages received in step (e) may be
overwritten and lost.

(g) All Closed Network IDs and NCS common channel frequencies shall be as specified in step
(b). It is preferable that the message addressing information is also the same as that defined in
step (b), however, this is not a mandatory requirement.

(i)-(o) All messages are displayed and/or printed error-free (message addressing information retained
in non-volatile memory) or all messages are ignored (message addressing information not
retained in non-volatile memory).

(p) All messages are ignored (message addressing information retained in non-volatile memory),
or messages p.1, p.3, p.5 and p.6 are displayed and/or printed error-free and the remainder are
ignored (message addressing information not retained in non-volatile memory).

(q) The new download command should be not accepted in step q.1. The new ENID should be
stored and the inhibited ENID should be overwritten.

(s) Messages r.2 and r.4 are ignored by the receiver. The remainder are displayed and/or printed
error-free.

Recommended Test Procedures (RTPs), Page: 14


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM E4-E RECEIVER ADDRESSING

1 PURPOSE OF THE TEST

The test shall demonstrate that the receiver will successfully accept EGC messages with different
service/address codes as selected by the operator, and reject the others as stated in SDM Volume 3,
Part 2, Chapter 8, Section 7.7.

2 APPLICABILITY

In general the test is applicable to all types of EGC receivers. However some steps in the test
procedure need not be performed if the receiver is of the FLEETNET only or SAFETYNET only type
(i.e. steps e.1 to e.14 for FLEETNET only receivers and steps f.1 to f.28 for SAFETYNET only
receivers).

Steps g.1 to g.30 need only be performed for those EGC receivers with SAFETYNET capability which
allow the current NAVAREA to be estimated from the mobile's position.

3 ENVIRONMENTAL CONDITIONS

Normal ambient only.

4 TEST SET-UP

See figure 6-C.

5 REQUIRED TEST EQUIPMENT

(a) NCS/LES simulator.

6 TEST PROCEDURE

(a) Connect the NCS/LES simulator to the EGC receiver antenna port and adjust the level to
nominal. (For EGC receivers designed to interface with an existing INMARSAT mobile earth
station, the NCS/LES simulator IF output shall be used).

(b) Tune the simulator to channel no. 11080 (1537.7 MHz, AOR East).

(c) Tune the EGC receiver to ch. no. 11080 and wait for synchronization to be achieved. Input
the following information into the receiver:

Mobile position: 45°30'N 13°40'E;

Navarea: 01, 03, 05; (manual input, i.e. override any


automatic calculation of the NAVAREA)

Fixed Area Code: 2354167;

Coastal Warning Area: A, B, C;

Navtex Code: E, F, G;

Recommended Test Procedures (RTPs), Page: 15


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(d) Send EGC packets (test messages) with the following Service and Address fields in the
header. Record the results:

d.1 [General Call]

d.2 [INMARSAT system][00]

d.3 [INMARSAT system][05]

d.4 [INMARSAT system][06]

d.5 [INMARSAT system][03]

d.6 [INMARSAT system][02]

d.7 [INMARSAT system][01]

d.8 [INMARSAT system][04]

d.9 [INMARSAT system][07]

d.10 [INMARSAT system][08]

d.11 [General Call]

(e) If the receiver has SAFETYNET capability send EGC packets (test messages) with the
following Service and Address fields in the header. Record the results:

e.1 [14H][44°N 12°E 140nmi]

e.2 [14H][44°S 12°E 140nmi]

e.3 [24H][44°30'N 12°40'E 90nmi]

e.4 [24H][44°N 12°W 300nmi]

e.5 [44H][44°N 12°E 100nmi]

e.6 [44H][40°N 9°E 450nmi]

e.7 [04H][12°S 1°W 60° 15°]

e.8 [04H][15°S 1°W 60° 15°]

e.9 [34H][42°N 12°E 3° 1°]

e.10 [34H][30°S 20°W 16° 34°]

e.11 [13H][01, AA]

e.12 [13H][01, AB]

e.13 [13H][01, AC]

e.14 [13H][01, AD]

Recommended Test Procedures (RTPs), Page: 16


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

e.15 [13H][01, AE]

e.16 [13H][01, AF]

e.17 [13H][01, AG]

e.18 [13H][01, AH]

e.19 [13H][02, BA]

e.20 [13H][02, BE]

e.21 [13H][02, BG]

e.22 [13H][03, CA]

e.23 [13H][03, CB]

e.24 [13H][03, CE]

e.25 [13H][03, CH]

e.26 [13H][03, DA]

e.27 [13H][03, DB]

e.28 [13H][03, DC]

e.29 [13H][05, DE]

e.30 [13H][05, DF]

e.31 [13H][05, DD]

e.32 [31H][01]

e.33 [31H][12]

e.34 [31H][03]

e.35 [31H][04]

e.36 [31H][05]

e.37 [31H][11]

e.38 [73H][2354167]

e.39 [73H][1357426]

e.40 [73H][8965412]

(f) If the EGC receiver has FleetNet capability, send EGC packets with the following Service and
Address fields in the header (ID means the unique identification code of the EGC receiver
under test). Record the results:

Recommended Test Procedures (RTPs), Page: 17


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

f.1 [23H][wrong ID]

f.2 [23H][ID]

f.3 [33H][wrong ID]

[new 11111, 9999, 54321]

[text:11111=abcdefg,9999=hijklmn,54321=opqrstu]

f.4 [33H][ID]

[new 11111, 9999, 54321]

[text: 11111=abcdefg,9999=hijklmn,54321=opqrstu]

f.5 [33H][ID]

[new 11111]

[text: 11111=abcdefg]

f.6 [33H][ID]

[delete 11101]

[text: 11101=abcdefg]

f.7 [33H][wrong ID]

[delete 11111, 9999, 54321]

[text: 11111=abcdefg,9999=hijklmn,54321=opqrstu]

f.8 [33H][ID]

[new 22222]

[text: 22222=vwxjzz]

f.9 [02H][11111][Text: msg1]

f.10 [02H][22222][Text: msg2]

f.11 [02H][9999][Text: msg9]

f.12 [02H][54321][Text: msg7]

f.13 [33H][ID]

[delete 22222]

[Text: 22222 deleted]

f.14 [02H][22222][Text: msg2]

f.15 [02H][01111][Text: msg0]

Recommended Test Procedures (RTPs), Page: 18


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

f.16 [23H][ID][Text: System w/ID]

f.17 [23H][9999][Text: System w/G9]

f.18 [33H][ID]

[delete 11111 and 54321]

[Text: 11111 and 54321 deleted]

f.19 [02H][11111][Text: msg1]

f.20 [02H][54321][Text: msg7]

f.21 [02H][00000][Text: Group w/G0]

f.22 [33H][ID]

[new 00000]

[Text: 00000=qyqyqyry]

f.23 [02H][00000][Text: Group w/G0]

f.24 [33H][wrong ID]

[delete 00000]

Text: 00000 deleted w/wrong ID]

f.25 [02H][00000][Text: Group w/G0]

f.26 [33H][ID]

[delete 00000]

[Text: 00000 deleted]

f.27 [33H][Invalid ID]

[New 65535]

[Text: 65535]

f.28 [02H][65535] [Text: Group w/Invalid ID]

f.29 [33H][ID]

[New 65535]

[Text: 65535]

f.30 [72H][65535] [Text: Chart Correction Service message]

Recommended Test Procedures (RTPs), Page: 19


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(g) If the EGC receiver is capable of automatically determining the current NAVAREA from the
mobile's position cause the receiver to enter the automatic mode and perform the following
steps:

g.1 Manually update the mobile's position to 50oN, 20oW. Send the following EGC message and
record the result:

[31H][1]

g.2 Manually update the mobile's position to 8oN, 34oW. Send the following EGC message and
record the result:

[31H][2]

g.3 Manually update the mobile's position to 5oS, 0oW. Send the following EGC message and
record the result:

[31H][2]

g.4 Manually update the mobile's position to 35oN, 15oE. Send the following EGC message and
record the result:

[31H][3]

g.5 Manually update the mobile's position to 25oN, 90oW. Send the following EGC message and
record the result:

[31H][4]

g.6 Manually update the mobile's position to 6oN, 21oW. Send the following EGC message and
record the result:

[31H][5]

g.7 Manually update the mobile's position to 89oS, 21oW. Send the following EGC message and
record the result:

[31H][6]

g.8 Manually update the mobile's position to 11oS, 54oE. Send the following EGC message and
record the result:

[31H][7]

g.9 Manually update the mobile's position to 88oS, 19oW. Send the following EGC message and
record the result:

[31H][7]

g.10 Manually update the mobile's position to 7oS, 14oE. Send the following message and record
the result:

[31H][7]

Recommended Test Procedures (RTPs), Page: 20


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

g.11 Manually update the mobile's position to 13oN, 65oE. Send the following EGC message and
record the result:

[31H][8]

g.12 Manually update the mobile's position to 29oS, 61oE. Send the following EGC message and
record the result:

[31H][8]

g.13 Manually update the mobile's position to 29oS, 94oE. Send the following EGC message and
record the result:

[31H][8]

g.14 Manually update the mobile's position to 22oN, 63oE. Send the following EGC message and
record the result:

[31H][9]

g.15 Manually update the mobile's position to 45oN, 13oE. Send the following EGC message and
record the result:

[31H][9]

g.16 Manually update the mobile's position to 70oS, 159oE. Send the following EGC message and
record the result:

[31H][10]

g.17 Manually update the mobile's position to 13oS, 96oE. Send the following EGC message and
record the result:

[31H][10]

g.18 Manually update the mobile's position to 11oS, 130oE. Send the following EGC message and
record the result:

[31H][10]

g.19 Manually update the mobile's position to 1oS, 169oE. Send the following EGC message and
record the result:

[31H][10]

g.20 Manually update the mobile's position to 44oN, 140oE. Send the following EGC message and
record the result:

[31H][11]

g.21 Manually update the mobile's position to 9oS, 140oE. Send the following EGC message and
record the result:

[31H][11]

Recommended Test Procedures (RTPs), Page: 21


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

g.22 Manually update the mobile's position to 44oN, 142oE. Send the following EGC message and
record the result:

[31H][11]

g.23 Manually update the mobile's position to 53oN, 175oW. Send the following EGC message
and record the result:

[31H][12]

g.24 Manually update the mobile's position to 5oN, 100oW. Send the following EGC message and
record the result:

[31H][12]

g.25 Manually update the mobile's position to 2oS, 110oW. Send the following EGC message and
record the result:

[31H][12]

g.26 Manually update the mobile's position to 46oN, 180oE. Send the following EGC message and
record the result:

[31H][13]

g.27 Manually update the mobile's position to 45oS, 165oE. Send the following EGC message and
record the result:

[31H][14]

g.28 Manually update the mobile's position to 1oS, 170oW. Send the following EGC message and
record the result:

[31H][14]

g.29 Manually update the mobile's position to 19oS, 110oW. Send the following EGC message
and record the result:

[31H][15]

g.30 Manually update the mobile's position to 60oS, 68oW. Send the following EGC message and
record the result:

[31H][15]

g.31 Manually update the mobile's position to 4oS, 80oW. Send the following EGC message and
record the result:

[31H][16]

g.32 Manually update the mobile's position to 18oS, 120oW. Send the following EGC message
and record the result:

[31H][16]

Recommended Test Procedures (RTPs), Page: 22


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

h Set the current position to 31o S, 110oW and allow this position to become invalid (ie, after
12 hours).

Send EGC packets (test messages) with the following priorities, services and address fields in
the header (double header packets).

h.1 [routine][00H]

h.2 [routine][31H][15]

h.3 [routine][31H][2]

h.4 [safety][31H][15]

h.5 [urgent][31H][15]

h.6 [distress][31H][15]

h.7 [safety][31H][4]

h.8 [urgent][31H][7]

h.9 [distress][31H][12]

h.10 [routine][13H][01,CA]

h.11 safety][13H[03,BA]

h.12 [urgent][13H][03,GD]

h.13 [distress][13H][09,GX]

h.14 [routine][31H][12]

h.15 [safety][73H][9754123]

h.16 distress][14H][44oN, 12oE 140 nmi]

h.17 [safety][24H][50oN, 20oE 30 nmi]

h.18 [urgent][24H][50oN, 20oE 30 nmi]

h.19 [distress][24H][44oN, 12oE 140 nmi]

h.20 [routine][04H][42oN, 12oE 3o 1o]

h.21 [safety][04H][42oN, 12oE 3o 1o]

h.22 [distress][04H][42oN, 12oE 3o 1o]

7 PASS/FAIL CRITERIA

All receiver types:

The receiver shall process and output the EGC messages transmitted during the following steps. All
output shall be error free:

d.1, d.2, d.4, d.6, d.11.

Recommended Test Procedures (RTPs), Page: 23


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The receiver shall disregard the messages transmitted during the following steps:

d.3, d.5, d.7, d.8, d.9, d.10.

Receivers with SAFETYNET capability:

The receiver shall process and output the EGC messages transmitted during the following steps. All
output shall be error-free:

e.1, e.5, e.6, e.7, e.10, e.11, e.12, e.14, e.15, e.16, e.17, e.22, e.23, e.32, e.34, e.36, e.38.

h.1, h.3, h.4, h.5, h.6, h.7, h.8, h.9, h.11, h.12, h.13, h.15, h.16, h.17, h.18, h.19, h.21, h.22,
h.23, h.24.

The receiver shall disregard the messages transmitted during the following steps:

e.2, e.3, e.4, e.8, e.9, e.13, e.18, e.19, e.20, e.21, e.24, e.25, e.26, e.27, e.28, e.29, e.30,
e.31, e.33, e.35, e.37, e.39. e.40.

h.2, h.3, h.10, h.14, h.20.

The algorithm employed to determine whether or not the mobile is within a circular area shall be
stated.

Receivers with FLEETNET capability:

The receiver shall process and output the EGC messages transmitted during the following steps. All
output shall be error-free:

f.2, f.9, f.10, f.11, f.12, f.16, f.23, f.25, f.30.

The receiver shall disregard the messages transmitted during the following steps:

f.1, f.14, f.15, f.17, f.19, f.20, f.21, f.28.

The receiver shall register new Closed Network ID's at the following steps:

f.4, f.8, f.22, f.29.

and disregard the commands to add new Closed Network ID's issued during steps:

f.3, f.5, f.27.

The receiver shall delete existing Closed Network ID's at the following steps:

f.13, f.18, f.26.

and disregard the commands to delete Closed Network IDs issued during steps:

f.6, f.7, f.24.

Receivers capable of automatically estimating the NAVAREA from the mobile's position:

The receiver shall process and output, error-free, the EGC messages transmitted during steps g.1 to
g.32 inclusive.

Recommended Test Procedures (RTPs), Page: 24


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The area definitions assumed for this facility shall be stated.

Recommended Test Procedures (RTPs), Page: 25


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM E4-F ERROR DETECTION

1 PURPOSE OF THE TEST

The test shall demonstrate that the receiver will correctly perform the error detection algorithms as stated in
SDM Volume 3, Part 2, Chapter 8, Section 7.7.5.

2 APPLICABILITY

All types of EGC receives.

3 ENVIRONMENTAL CONDITIONS

Normal ambient only.

4 TEST SET-UP

See figure 6-C.

5 REQUIRED TEST EQUIPMENT

(a) NCS/LES simulator.

6 TEST PROCEDURE

(a) Connect the NCS/LES simulator to the EGC receiver antenna port and adjust the level to
nominal. (For EGC receivers designed to interface with an existing INMARSAT mobile earth
station, the NCS/LES simulator IF output shall be used).

(b) Tune the simulator to channel no. 11080 (1537.7 MHz, AOR).

(c) Tune the EGC receiver to ch. no. 11080 and wait for synchronisation to be achieved.

(d) Send the following EGC packets (Single Header), one in each frame, and record the results:

d.1 [ERRH-HDR][MSG]

d.2 [HDR][ERRD-MSG]

d.3 [ERRH-HDR][ERRD-MSG]

d.4 [HDR][MSG]

where ERRH and ERRD indicate, respectively, that the packet header and message data are
corrupted with an arbitrary error pattern. Each error pattern should be different and clearly
indicated in the test results. Error patterns affecting message data should include both
detectable and undetectable errored characters.

(e) e.1 Send a multi-packet EGC message (single header) with at least one packet corrupted
as follows and record the results:

[HDR][ERRD-MSG]

where ERRD is an arbitrary error pattern.

Recommended Test Procedures (RTPs), Page: 26


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

e.2 Send a repetition of the same message with some but not all of the errors assumed in
step e.1 corrected. Record the results.

e.3 Send a repetition of the same message with no errors and record the results.

e.4 Send a multi-packet EGC message (single header) with one packet corrupted as
follows and record the results:

[ERRH-HDR][MSG]

where ERRH is an arbitrary error pattern.

e.5 Send an error-free repetition of the same message and record the results.

e.6 Repeat the step e.5.

(f) Send the following EGC packets (Double Header), one in each frame, and record the results:

f.1 [ERRH1-HDR1][MSG1][ERRH2-HDR2][MSG2]

f.2 [ERRH1-HDR1][ERRD1-MSG1][HDR2][ERRD2-MSG2]

f.3 [HDR1][MSG1][ERRH2-HDR2][ERRD2-MSG2]

f.4 [HDR1][ERRD1-MSG1][ERRH2-HDR2][MSG2]

f.5 [ERRH2-HDR1][MSG1][HDR2][MSG2]

f.6 [HDR1][MSG1][HDR2][MSG2]

f.7 [HDR1][MSG1][HDR2][MSG2]

where ERRH1 and ERRH2 are different, arbitrary error patterns affecting the first and second
headers of a double-header packet respectively. Similarly, ERRD1 and ERRD2 are different,
arbitrary error patterns affecting the message content of the double-header packet. Error
patterns should be clearly indicated in the test results and should be different for each of the
steps f.1 to f.7. Error patterns affecting message data should include both detectable and
undetectable errored characters.

(g) Send the following EGC packet (double header) and record the results:

g.1 [HDR1][MSG1][ERRH2-HDR2][MSG2]

where ERRH2 denotes an error in the length field of the second double-header packet.

(h) h.1 Send a multi-packet EGC message (double header) with at least one packet corrupted
as follows and record the results:

[HDR1][ERRD1-MSG1][HDR2][ERRD2-MSG2]

where ERRD1 and ERRD2 are arbitrary error patterns.

h.2 Send a repetition of the same message with some but not all of the errors assumed in
Step h.1 corrected. Record the results.

Recommended Test Procedures (RTPs), Page: 27


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

h.3 Send a repetition of the same message with no errors and record the results.

h.4 Send a multi-packet EGC message (double header) with one packet corrupted as
follows and record the results:

[ERRH1-HDR1][MSG1][ERRH2-HDR2][MSG2]

where ERRH1 and ERRH2 are arbitrary error patterns.

h.5 Send an error-free repetition of the same message and record the results.

(i) Disconnect the simulator from the EGC receiver to simulate loss of synchronisation. Check
that an indication is provided for this condition. Restore the connection and check that the
indicator returns to normal.

7 PASS/FAIL CRITERIA

Single Packet Messages

The receiver shall:

- disregard the packets transmitted in steps d.1, d.3 and f.1;

- display the messages received in steps d.4, f.5, f.6 and f.7 without error;

- display the messages received in steps d.2, f.2, f.3 and f.4, showing errored characters with
incorrect parity as " ";

- display the message received in step g.1 without loss of message text;

- Ignore the message in step e.6;

Multi-packet messages

The receiver shall:

- display the messages transmitted in steps e.1 and h.1, showing errored characters with
incorrect parity as " ";

- demonstrate that the messages transmitted in steps e.2 and h.2 update those received in steps
e.1 and h.1 respectively. Errored characters with incorrect parity shall be displayed as " ";

- demonstrate that the messages transmitted in steps e.3 and h.3 update those received in steps
e.2 and h.2 respectively. The messages shall be displayed with no errors;

- display the message received in steps e.4 and h.4 with an indication that one packet of
message text has been lost:

- demonstrate that the messages transmitted in steps e.5 and h.5 update those received in steps
e.4 and h.4 respectively. The messages shall be displayed with no errors;

General

A positive result shall be recorded for step (i).

Recommended Test Procedures (RTPs), Page: 28


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM E4-G SEQUENCE NUMBER HANDLING

1 PURPOSE OF THE TEST

The test shall demonstrate that the receiver complies with the requirements indicated in SDM Volume
3, Part 2, Chapter 8, Section 7.7.4.

2 APPLICABILITY

All types of EGC receivers.

3 ENVIRONMENTAL CONDITIONS

Normal ambient only.

4 TEST SET-UP

(a) Connect the NCS/LES simulator to the EGC receiver antenna port and adjust the level to
nominal.

(b) Tune the simulator to channel no. 11080.

(c) Tune the EGC receiver to ch. no. 11080 and wait for the synchronisation to be achieved.

(d) Send an EGC message with LES ID 012 and Sequence number 111, and a few characters
crashed in text field.

(e) Repeat step d with the error free contents in text field and the sequence number ramains
unchanged.

(f) Repeat step e.

(g) Repeat step e but the LES ID is changed to 001.

(h) Tune the simulator to channel no. 12580.

(i) Tune the EGC receiver to ch. no. 12580 and wait for the synchronisation to be achieved.

(j) Send an EGC message with LES ID 131 and Sequence number 111.

(k) Repeat step j.

(l) Repeat step k after betweem 60 and 72 hours.

5 PASS/FAIL CRITERIA

The receiver shall process and output the EGC messages transmitted in steps d, e, g, j and l

and disregard the EGC messages transmitted in steps f and k.

Recommended Test Procedures (RTPs), Page: 29


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM E5-A DISTRESS MESSAGES

1 PURPOSE OF THE TEST

The test shall demonstrate that the receiver will provide an audible alarm upon reception of a valid
distress/urgent message as indicated in SDM Volume 3, Part 2, Chapter 8, Section 7.7.6.

2 APPLICABILITY

All types of EGC receiver.

3 ENVIRONMENTAL CONDITIONS

Normal ambient only.

4 TEST SET-UP

See figure 6-C.

5 REQUIRED TEST EQUIPMENT

(a) NCS/LES simulator.

6 TEST PROCEDURE

(a) Connect the NCS/LES simulator to the EGC receiver antenna port and adjust the level to
nominal. (For EGC receivers designed to interface with an existing INMARSAT mobile earth
station, the NCS/LES simulator IF output shall be used).

(b) Tune the simulator to channel no. 11080 (1537.7 MHz, AOR).

(c) Tune the EGC receiver to ch. no. 11080 and wait for the synchronisation to be achieved.

(d) Send an EGC message with Distress Priority and check that the message is displayed on the
output device and that an audible alarm is initiated; if a remote distress indicator is provided,
check that the alarm indication is also present there.

(e) Send a different EGC message with Distress Priority and a further EGC message with Routine
Priority. Check that both the local audible alarm and the remote distress indicator (if
provided) remain active. Check that the distress message is displayed on the output device.

(f) Manually tune the receiver to channel 12580 (POR). Check that the alarm indication(s)
remain active.

(g) Disconnect the NCS/LES simulator from the receiver input. Check that the alarm
indication(s) remain active.

(h) Reset the alarm and check that the audible alarm and the remote alarm (if provided) are
deactivated.

(i) Repeat steps (c) through (h) substituting messages with Urgent Priority for those with Distress
Priority.

(j) Send four interleaved multi-packet EGC messages with the following priorities and orders:

Recommended Test Procedures (RTPs), Page: 30


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

EGC Message 1 - Routine, 8 packets in Frame 1, 2, 3, 4, 5, 6, 7, 8;

EGC Message 2 - Safety, 6 packets in Frame 1, 2, 3, 4, 5, 6;

EGC Message 3 - Urgent, 4 packets in Frame 1, 4, 6, 8;

EGC Message 4 - Distress, 3 packets in Frame 1, 3, 5.

7 PASS/FAIL CRITERIA

Each of the tests indicated shall produce a positive result. For test (j), at least EGC message 4 should be
received with no errors.

Recommended Test Procedures (RTPs), Page: 31


Section 6: Phase 1 Tests for EGC Receiver Equipment
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

7. TEST SIMULATORS

7.1 RECOMMENDED TECHNICAL CHARACTERISTICS

7.1.1 INTRODUCTION

This section presents the recommended Technical characteristics for Inmarsat-C Test Simulators to be used in
Type-Approval Testing of Inmarsat-C Mobile Earth Station models.

The basic functions of the Test Simulators are:

(a) Land earth station/network coordination station simulator:

- to simulate network coordination station and land earth station operation as far as possible;

- to conduct a protocol dialogue with a mobile earth station under test in various modes (as applicable);

It is preferable that the simulator should be designed to interface with the mobile earth station at RF (via the
antenna port) thereby enabling the mobile earth station to be tested as a system (except for the antenna sub-
system).

Figures 4.1 and 4.2 show the possible interconnections between the simulator and the mobile earth station under
test.

(b) Channel Simulator:

The purpose of the channel simulator is to simulate the effects of signal impairments introduced in the mobile
satellite communications channel. Specifically this shall include the following;

- propagation characteristics in respect of multipath fading;

- additive white gaussian noise on the wanted signal;

- the presence of adjacent channel interference; and

- the presence of out of band interferers;

7.1.2 SIGNAL CHARACTERISTICS

(i) Land Earth Station/Network Coordination Station Simulator

(a) Signal Characteristics - RF

Received from the mobile earth station:

- Band: 1626.5 to 1646.5 MHz

- Level: +42 dBm (typical) on 50 ohm.

Transmitted to the mobile earth station:

- Band: 1530 to 1545 MHz

Recommended Test Procedures (RTPs), Section 7: Test Simulators Page: 1


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

- Level: variable in 1 dB steps in the range -115 to -145 dBW (50 Ohms).

The transmitter(s) and receiver(s) must be independently tunable in the ranges shown above in 5 kHz steps.

(b) Signal Characteristics - IF

Receive IF

- Signalling Channel: refer to SDM Volume 3, Part 2, Chapter 2, sections 5.1 and 5.3; the information
about the time of arrival of the burst (referred to a predetermined time-reference, e.g. transmitted UW)
shall be made available.

- Message Channel: refer to SDM Volume 3, Part 2, Chapter 2, sections 5.1 and 5.4.

Transmit IF

- For the modulation and coding specifications, refer to SDM Volume 3, Part 2, Chapter 2, section 4.2.
It shall be possible to vary the carrier frequency within the range ±1 kHz from nominal and the data
rate ±1 part in 106.

(ii) Channel Simulators

These simulators may be implemented either in the IF transmit chain of the land earth station/network
coordination station simulator or in the RF transmit chain. A practical implementation might use a combination
of commercially available test equipment and purposely designed sub-systems to realize the desired functions.

Simulation of satellite link propagation delay (in the range approximately 237 to 278 ms) shall be included, for
example by simulation in the land earth station/network coordination station software.

(a) Fading Simulator

Its technical characteristics are shown in Figure 4.3; it is recommended that it should be possible to vary the
C/M in the range 0 to 15 dB and the -3 dB bandwidth of the filters between 0.5 and 3 Hz.

(b) Channel Noise Simulator

The Channel Noise Simulator shall include a capability to superimpose on the wanted signal the following
impairments:

- Gaussian noise: the resulting C/No shall be adjustable in the range of less than 28 to greater than 40
dB-Hz;

- Multiplicative phase noise with a power density spectrum within ± 2 dB of the curve shown in fig. 4-6,
SDM Volume 3, Part 2, Chapter 2; and

- Short-term doppler shift effect of -50 to +50 Hz in 3 seconds.

Note: In order to obtain the correct C/No at the receiver without overdriving the input it may be necessary to
inject the signal and noise at a point in the receive chain other than the input to the LNA, unless a low
temperature noise source is available (Te = Ta or approximately 100 K). A 50 Ohm source at room temperature
(290 K) would require a carrier level approximately 5 dB higher than that required when operating with an
antenna, under normal conditions and assuming Ta = 100 K. Providing the increased signal and noise levels at
the receiver input are well within the operating range of the receiver, it may be acceptable to connect the source
to the receiver antenna terminal.

Recommended Test Procedures (RTPs), Section 7: Test Simulators Page: 2


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(c) Adjacent Channel Interference Simulator

The Adjacent Channel Interference Simulator shall combine the wanted signal with an interfering carrier having
the following characteristics:

Frequency offset: adjustable between -50 and +50 kHz in 1 kHz steps;

Level difference: adjustable between -5 and +10 dBc;

Modulation: BPSK unfiltered at 1200 symbols/s;

Mod. signal: Pseudo Random Data (e.g. PN 511 in CCITT V.52).

7.1.3 PACKET FORMATS

(i) Receive

The land earth station/network coordination station simulator shall be arranged so that packets transmitted by a
mobile earth station (as listed in SDM Volume 4, Chapters 4 and 5) shall be displayed and means of providing
responses in accordance with section 6 (Access and Control Requirements) of SDM Volume 3, Part 2, Chapter
2 shall be included.

(ii) Transmit

The simulator shall include a capability for generating each of the packets (as defined in SDM Volume 4,
Chapters 2 and 3) necessary for conducting the tests listed in section 2 of this Document.

7.1.4 ACCESS & SIGNALLING PROTOCOL/MESSAGE TRANSFER

[This section will contain specifications for the functions of the General Processor in terms of a (simplified)
Inmarsat-C signalling protocol].

7.1.5 INTERFACES AND INPUT/OUTPUT FACILITIES

Figure 4.2 shows a typical configuration of a land earth station/network coordination station simulator. It is
possible to identify two major sub-systems of the land earth station/network coordination station simulator;
these are:

(i) Transmitter/Receiver

The Transmitter/Receiver provides signal generation, coding and modulation, and signal reception, down-
conversion and demodulation to and from the mobile earth station under test.

(ii) Controller

The Controller acts as an interface between the General Processor and the Transmitter/Receiver. Its main
functions are summarized below.

In the transmit mode, depending on the commands received from the General Processor, it:

- controls the selection and assignment of land earth station/network coordination station and mobile
earth station transmit channel respectively;

Recommended Test Procedures (RTPs), Section 7: Test Simulators Page: 3


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

- generates the transmitted frames with UWs and inserts data packets (Bulletin Boards, signalling
packets and data packets) into the appropriate positions within the frames.

In the receive mode, it provides the General Processor with information derived from the channel being
received, including received data packet and timing information.

(iii) General Processor

The General Processor controls the signalling protocol and message processing of the simulator. It should
include an input device (e.g. keyboard) by which the appropriate parameters can be manually entered and an
output device (e.g. VDU) in order to display parameter settings and the data received from the Controller.

The provision of additional peripheral equipment, for example a hard copy printer, disk-drive, etc., is desirable.

7.2 NCS/LES SIMULATOR FUNCTIONAL TEST REQUIREMENTS

7.2.1 GENERAL

The NCS/LES shall be capable to transmit at least one NCS common channel TDM and one LES TDM and
receive an MES signalling channel and an MES Message channel.

In consideration of the fact that the MES normally is able to receive only one TDM channel at a given time, it is
possible to have only one TDM transmission from the simulator which will be dynamically switched between
NCS common channel and LES TDM as required by the tests. The time it takes to switch shall be considerably
shorter than the corresponding switching (tuning and re-acquisition) time of the MES under test.

7.2.2 TRANSMISSION

The simulator shall transmit valid TDM frames (with UWs) in sequence and means shall be provided to transmit
all the packets shown in SDM Volume 4, Chapters 2 and 3, in any selected frame and with any offset (in bytes)
from the start of frame.

It shall be possible to alter the various sub-fields in each packet as required by the test procedure. Means to
introduce errors in the checksum fields and bit slips in the TDM frame, shall be included.

It should also be possible to transmit:

i) Pre-formatted sequences for testing purposes as described in test item 6-A, General Access Control of
the Phase I test procedures.

ii) Single and double header EGC packets on the NCS TDM (for testing EGC receivers and Class 2 and 3
MESs) of all service codes.

iii) Continuation packets A and B split across frames (NCS and LES TDMs).

iv) Network updates; to verify that the MES is able to respond to network changes.

Recommended Test Procedures (RTPs), Section 7: Test Simulators Page: 4


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

7.2.3 RECEPTION

The simulator shall continuously receive at least one MES signalling channel (synchronised to the
corresponding transmitted TDM) and one MES message channel in both 300 bits/s and 600 bits/s (1st and future
generation operation). For each signalling packet received the following information shall be provided.

- Signalling Channel

- Frame number/Slot number

- Packet Error/OK

- Packet type

Note: A relatively simple demodulator implementation should suffice for this purpose, since no impairments
need be introduced and the demodulator may be operated at a very high C/No.

7.2.4 OPERATORS FACILITIES

The packets to be transmitted on the TDM channels can be entered via a keyboard and displayed for
confirmation on a VDU, or pre-assembled as a file stored in a disk and read at execution time.

It is recommended that an interpreting program is available to allow the operator to enter packet fields in a
mnemonic (symbolic) form in addition to a binary/hexadecimal format.

Signalling packets and message packets should be displayed and printed or stored in a disk for later analysis.

7.3 CHANNEL SIMULATORS FUNCTIONAL TEST REQUIREMENTS

(a) Fading Simulator

The channel simulator shall generate Rician fading channel as it is described in SDM Volume 3, Part 2, Chapter
2, Section 4.4 and it shall be tested in the following recommended test procedures in order to ensure that it
meets the Rician fading model with Rice factor of 7 dB and the power spectrum band width of 0.7 Hz.

Test Procedures

(i) Make the TDM carrier (x(t) in Figure 3.3) unmodulated and connect it to the channel
simulator.

(ii) Record the direct path power (C) without adding multipath at the output (y(t) in Figure 3.3) of
the simulator by the power meter.

(iii) Turn the direct path off and the multipath on. Adjust the multipath power so that the C/M=7
dB can be obtained.

(iv) Turn the direct path on.

(v) Set the spectrum analyser as follows:

Frequency span zero span

Resolution band width 100 Hz

Recommended Test Procedures (RTPs), Section 7: Test Simulators Page: 5


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Centre frequency same as the TDM carrier

Sweep time 30 secs

Sweep mode single sweep

Vertical scale 2 dB/div

(vi) Connect the faded carrier to the spectrum analyser and record the signal variation on the
spectrum analyser screen and dump it to the plotter.

(vii) Draw the line at the C level on the plot and count the number (N) crossing the C level
upwards and calculate the average (T) of the time during which the signal level is below the C
level.

(viii) Repeat steps (vi) and (vii) 9 times.

(iv) Calculate the sum of N and the average of T to get Count_0 (reciprocal of Interfade Interval)
and Time_0 (Fading Duration) as follows:

sum of N
Count_0 = 300

Time_0 = T

(v) Draw the line at (C-2) dB for 10 data obtained. Calculate the sum of the number (N2) crossing
the (C-2) level upwards and the average (T) of the time during which the signal level is below
the (C-2) dB.

sum of N2
Count_2 = 300

Time_2 = T2

(vi) Draw the line at (C-4) dB for 10 data obtained and calculate N4 and T4 in the same way as in
step (v).

(vii) Repeat step (vi) at (C-6) dB.

(viii) Repeat step (vi) at (C-8) dB.

Pass/Fail Criteria

The reciprocal of Interfade Interval and the Fading Duration at each level are:

Count_0 = 0.72 ± 0.02 (/sec) Time_0 = 0.7 ± 0.1 (sec)

Count_2 = 0.56 ± 0.05 (/sec) Time_2 = 0.43 ± 0.03 (sec)

Count_4 = 0.32 ± 0.05 (/sec) Time_4 = 0.32 ± 0.03 (sec)

Count_6 = 0.16 ± 0.05 (/sec) Time_6 = 0.25 ± 0.03 (sec)

Count_8 = 0.09 ± 0.01 (/sec) Time_8 = 0.22 ± 0.03 (sec)

(b) Channel Noise Simulator

Recommended Test Procedures (RTPs), Section 7: Test Simulators Page: 6


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The Gaussian noise shall be measured by a power meter or a spectrum analyser. If it is measured by a
spectrum analyser, the correction factor must be taken into account.

The additive phase noise shall be checked by a spectrum analyser and the noise spectrum shall be
identical with that showed in figure 4-6 of SDM Volume 3, Part 2, Chapter 2.

The short-term doppler shift shall be checked by a frequency counter or a spectrum analyser to ensure
that it meet the requirements (± 50 Hz in 3 seconds).

(c) Adjacent Channel Interference Simulator

The adjacent channel interference carrier shall be generated by an ideal unfiltered BPSK modulator.
The spectrum and the level shall be tested by a spectrum analyser.

Recommended Test Procedures (RTPs), Section 7: Test Simulators Page: 7


DCE DTE

SCRAMBLER, DTE
B1 1200 SPS CONVOLUTIONAL
BPSK
Inmarsat Confidential

HPA ENCODER MESSAGE


MODUL' AND AND
R INTERLEAVER ACCESS USER
DATA I/O,
CONTROL USER I/O
A
AND INTERFACE,
LO SYNTH'R MESSAGE MESSAGE
HANDLING STORAGE
PROCESSOR AND
DEINTERLEAVER, PREPARATION
B2 1200 SPS DECODER
LNA BPSK FUNCTIONS
AND
DEMOD'R OTHER
DESCRAMBLER
I/O
PORTS

A - RF interconnection point
B1 - B2 IF interconnection points

Recommended Test Procedures (RTPs), Section 7: Test Simulators


Figure 4.1 SES BLOCK DIAGRAM

Page: 8
(Version Release CD004, CN000)
C SDM
Signal
Gen'r
Mod'r Coder
Inmarsat Confidential

1
B1'

C
Mod'r Coder O
A' 2 N GENERAL
B T PROC
R
O (PC)
Demod 1 L
Decod
L
er
B2' E
R

Demod 2 Decod
er
Spectrum
Analyzer

Recommended Test Procedures (RTPs), Section 7: Test Simulators


A' - RF interconnection
pointB1' - B2' IF
interconnection points

Figure 4.2 NCS/CES SIMULATOR BLOCK DIAGRAM

Page: 9
(Version Release CD004, CN000)
C SDM
C/M set
x(t)

y(t)
Inmarsat Confidential

LF Low pass
š/2 noise filter

LF Low pass
noise filter

x(t): RF or IF Input signal from NCS/CES simulator

Recommended Test Procedures (RTPs), Section 7: Test Simulators


y(t): RF or IF faded signal(to the SES under test..

Figure 4.3 RICIAN FADING SIMULATOR

Page: 10
(Version Release CD004, CN000)
C SDM
Inmarsat Confidential C SDM
(Version Release CD004, CN000)

8. PHASE II TESTS

8.1 INTRODUCTION AND REQUIRED TESTS

8.1.1 Introduction

This Section of the Recommended Test Procedures provides detailed procedures which will be used for type
approval Phase II tests (with an NCS and LES via an INMARSAT satellite). For further information, please
refer to Part 1 of the Type Approval Procedures for INMARSAT-C MESs, Section 7.

If this test plan cannot be exactly followed due to the particular design and features of the MES model, the
manufacturer shall propose to INMARSAT the use of an alternative test plan which will be reviewed by
INMARSAT and, if found suitable, approved and adopted for the tests.

The purpose of the Phase II test of Polling and Data Reporting is to demonstrate that the Inmarsat requirements
are satisfied and the function of the MES under test is fully consistent with the Inmarsat Network (NCSs,LESs
and Inmarsat satellites).

8.1.2 Test arrangements

Before Phase II testing can begin, two copies of the approved test plan and a preferred test schedule must be
sent to the INMARSAT Directorate by the manufacturer. The manufacturer should provide the following
additional information together with the test schedule:

a. Location and Geographical coordinates of the MES during the tests;

b. Preferred LES which will be conducting the tests;

c. Name of the person who will be responsible for the tests at the site;

d. Numbers of telephone, telex, FAX by which the person above can be contacted during the tests;

The Directorate will forward copies of the test plan to the LES, and will decide on a final test schedule after
consultation with the OCC, NCS, LES and the manufacturer. At least ten days before the start of testing, a
coordination message will be sent by INMARSAT (usually by telex or Fax) to the OCC, NCS, LES and the
manufacturer. The message will include the following information:

- a.,c. and d. as above;

- IDs (FWD and RTN MES IDs and Mobile Number) which shall be used for test purposes;

- MES model and its main characteristics (eg Class, Optional Capabilities, Distress Alert);

- Time period allotted for testing;

- Contact name(s) and telephone, telex and FAX nos. at the LES;

- INMARSAT MES Engineer responsible for the type approval of the MES model;

- LES, NCS, Preferred OR, Destination ID, Service codes which will entered the MES memory;

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 1


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

- Reference to the test plan which will be adopted;

8.1.2.1 Test arrangements for Data Reporting and Polling

In order to reliably verify the test results and check the protocols, the manufacturers should provide the testing
software. The requirements for the testing software are listed below:

i) Give a prompt when a poll is received;

ii) Display the contents of polls at operator's request;

iii) Retrieve all information associated with polling and data reporting, stored in the memory of the DCE;

iv) Edit the text in the text field of data reports, put DNID and LES ID pair into the header of data reports;

v) Indicate the result of transmission (failure or success) when data reports have been initiated by
operators;

Note: The above are general requirements. If those requirements can not be met due to the particular design
and features of the MESs, for instance SCADA, the manufacturers should submit their alternative
application software and give the detailed explanation to Inmarsat.

The use of testing software which shows detailed information on the protocol is strongly recommended. The
general requirements for the software are as follows:

i) Show the Bulletin Board and Signalling Channel Descriptor in the frame containing the poll addressed
to the MES under test;

ii) Show the whole original contents of the polls;

iii) Indicate the frame and the slot numbers in which the MES actually sent out the bursts;

iv) Show the whole original contents of the data reports;

v) Show the slot state markers in Signalling Channel Descriptor packet in the expected frame.

The following (printout at MES)are examples:

i) Download DNID

7D0111110404206C78B20008XXXX BB

69F0300C00000000XXXX SCD

A30D0030394C0108AE008A0101XXXX POLL

The Ack is sent out in slot 2 of Frame 1117 H

7D0111190404204C78B20008XXXX BB

69F0300D20000000XXXX SCD

0408AE4C01808A010000000000XXXX DATA REPORT

ii) Initiating Unreserved Data Reporting

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 2


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

7D0111200404206C78B20008XXXX BB

69F0300C00000000XXXX SCD

A20F08AE4C2328000240050311310AXXXX POLL

The first data report is sent out in slot 3 of Frame 1132 H

7D0111340404204C78B20008XXXX BB

69F0300D08000000XXXX SCD

0408AE4C01FFFFFFFFFFFFFFXXXX DATA REPORT

The second data report is sent out in slot 4 of frame 1141 H

7D0111430404204C78B20008XXXX BB

69F0300D02000000XXXX SCD

0408AE4C01FFFFFFFFFFFFFFXXXX DATA REPORT

iii) Downloading DNID and programming Reserved Data Reporting

7D0115450404206C78B20008XXXX BB

69F0300C00000000XXXX SCD

A3130030904C0008AF000105020E1575054303XXXX POLL

iv) Initiating Reserved Data Reporting

7D0115480404204C78B20008XXXX BB

69F0300D08000000XXXX SCD

E2000C08AF4C23280000400206XXXX POLL

The data report is sent out in slot 5 of frame 1575 H

7D0115770404204C78B20008XXXX BB

69F0300D00C00000XXXX SCD

0408AF4C02FFFFFFFFFFFFFFXXXX DATA REPORT

8.1.3 Required Tests

The tests which will normally be performed are listed below. The coordination message sent by INMARSAT
will inform of any variations from the standard test plan.

LIST OF REQUIRED TESTS

BASIC ACCESS TESTS

Test Item 21-A Ocean Region Registration

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 3


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Test Item 21-B Performance Verification

MESSAGE TRANSFER TESTS

Test Item 22-A To-Mobile Message Transfer

Test Item 22-B From-Mobile Message Transfer

Test Item 22-C Off-Line Operation

Test Item 22-D Forced Clearing

DISTRESS ALERTING TESTS (FOR SES ONLY)

Test Item 23-A Distress Alert Transmission

Test Item 23-B Distress Priority Message Transfer

LOG-IN AND LOG-OUT

Test Item 24-A Log-out and Log-in

OPTIONAL CAPABILITIES TESTS

Test Item 25-A Alternative Network Service: From-Mobile Message Transfer

Test Item 25-B Alternative Network Service - X.400: From-Mobile Message Transfer

DATA REPORTING AND POLLING TESTS

Test Item 26-A Downloading and Deleting DNIDs

Test Item 26-B Data Transmission

Test Item 26-C Initiating Data Reports at MES

Test Item 26-D Initiating Unreserved Reports as Required in [Response] Field

Test Item 26-E Programming Unreserved Data Reporting

Test Item 26-F Initiating Unreserved Data Reporting

Test Item 26-G Stopping Unreserved Data Reporting

Test Item 26-H Interruptions to Unreserved Data Reporting

Test Item 26-I Programming Reserved Data Reporting

Test Item 26-J Initiating Reserved Data Reporting

Test Item 26-K Interruptions to Reserved Data Reporting

Test Item 26-L Stopping Reserved Data Reporting

Test Item 26-M Data Reporting in Demand Assigned Mode

COVERT/SECURITY ALERT TESTS (FOR SES ONLY)

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 4


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Test Item 27-A Covert/Security Alert Transmission

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 5


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

8.2 TEST PROCEDURES

Preparation for testing at the MES

a. Calculate the operating elevation angle (θel) and azimuth (θaz) from the site coordinates

Parameters are:

γ = latitude of the MES

φMES = longitude of the MES

φSat = longitude of the satellite

Assuming that:

∆φ = φMES - φSat

cosβ = cosγ·cos∆φ

l = {R2+(R+H)2-2R(R+H)cosβ}1/2

where R = 6373 km and H = 35786 km

Then the elevation and azimuth angles are given below:

⎧ (R+H) ⎫
cos θel = ⎨ ⎬
l sinβ ⎭

tan∆φ
tan θaz =
sinγ
Satellite ephemeris information for operational INMARSAT satellites may be obtained from
INMARSAT.

b. Install the EME in a convenient location from which an unobstructed view of the satellite is
obtained. The antenna unit shall be mounted with the major axis in perpendicular position.

c. Disable the transmitter first and turn on the MES. Connect a spectrum analyser to a
convenient RF/IF broadband RCV monitor point and check that the NCS TDM carrier for the
ocean region in which the tests will be conducted is received. Estimate the approximate
received C/No.

Note: Prior to each test the MES operator shall record the received TDM BBER (bulletin board error
rate) on the appropriate test data sheet.

d. If the DTE has a text editor and file storage capability, prepare in advance two test messages
consisting of:

Test Message no.1:

---------------------------------------------------------

"<Location><Date>

This is a test message from MES <ID> undergoing type approval phase 2 tests. Please record.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 6


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

<200 lines of QBF*>

End of test message"

---------------------------------------------------------

Note *:QBF is meant to be the sequence of characters (56 including "spaces", <CR> and <LF>
characters)

THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG 1234567890<CR><LF>

Test Message no.2:

---------------------------------------------------------

"<Location><Date>

This is a distress message for TEST PURPOSES from MES <ID> undergoing type approval phase 2
tests.

PLEASE RECORD AND TAKE NO ACTION.

<10 lines of QBF>

End of distress test message."

---------------------------------------------------------

Store the test messages in the DTE.

f. At this point, only if the authorization and schedule have already been obtained from
INMARSAT (ie by Telex), the manufacturer may proceed with the next steps.

g. Enter the following operating parameters in the MES:

NCS channels/Preferred Ocean Region/Destination LES/Destination ID/Service: as per Telex from


INMARSAT.

If the MES has Distress Alert capability, enter/update the Distress Message in the MES as:

LES ID: As above;

POSITION: Geographical coordinates of the site;

PROTOCOL: 3 (spare code);

NATURE: 0 (unspecified);

COURSE: 0;

SPEED: 0;

h. Turn off the MES and restore the transmitter's functions to normal.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 7


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

i. The MES is now ready to start Phase II testing. Wait for the scheduled start and proceed with
Test Item 1-A.

Preparation for testing at the NCS/LES

a. If the authorization and schedule have been previously obtained from INMARSAT (ie by
telex), the NCS shall enter the MES ID(s) in the database not earlier than [12] hours before the
scheduled start of the tests. The MES Status shall be "Pre-commissioned".

b. At the LES test position, prepare a test message consisting of:

---------------------------------------------------------

"<Location><Date>

This is a test message from LES <Name and ID> performing type approval phase 2 tests with MES
<ID>. Please record.

<300 lines of QBF>

End of test message."

---------------------------------------------------------

c. Store the test message at the LES test position: this message will be needed during Test Item
22-A.

d. Prepare and check the test facilities* which will be needed at the LES during Test Item 22-B
for measuring the EIRP, carrier frequency, and timing characteristics of the MES.

Note*: It is assumed that the LES is equipped with facilities capable of providing an estimation of the
transmit level of the MES signal (message) channel referred to another known signal (ie, the
L-to-C AFC Pilot). Accurate measurement of the received frequency is not required, however
an estimation of the received frequency deviation from nominal (referred to the L-to-C AFC
Pilot) should be provided where possible. Means for measuring the MES burst timing to +/- 1
TDM symbol should be available.

e. The LES/NCS are now ready to start Phase 2 testing: wait for the scheduled start and proceed with Test
Item 21-A.

IMPORTANT NOTES

1) INMARSAT NCC is the sole responsible entity for authorizing the Phase II test session* to
proceed, according to the test procedures given below.

* If the sequence of test items needs to be interrupted for any reason, the tests could resume at a
later stage (still within the scheduled period) after mutual agreement between the LES and the
MES manufacturer.

2) INMARSAT NCC must be kept informed by the LES about the beginning and the end of each
test session.

3) Any technical or operational problems which might affect the INMARSAT network must be
reported immediately to the NCC by the testing LES.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 8


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4) In the case of any problem arising that affects commercial traffic, the testing LES shall request
the MES manufacturer to cease immediately all transmissions and investigate the problem.

5) Throughout the tests, it is the manufacturer who shall establish communications with the LES
on the coordination link as required in the test procedures. The cost for the use of any
coordination circuit shall be borne by the manufacturer.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 9


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 21-A OCEAN REGION REGISTRATION

1 PURPOSE OF THE TEST

The test will demonstrate that the MES's access to the network complies with the procedures as set
forth in SDM Volume 3, Part 2, Chapter 2, section 6.5.1.

2 APPLICABILITY

All classes of MESs.

3 TEST PROCEDURE AT THE MES

a. Establish a coordination link (eg by telephone) with the test LES and inform about readiness
to start testing. Wait for the positive reply from the LES before proceeding to step b.

b. Turn on the MES and allow it to warm up for 30 minutes. Check the parameters stored in the
MES memory; which should correspond to the following:

NCS channels: at least the channel given in the Authorization Telex from INMARSAT should be
present;

Current NCS: the code given in the Authorization Telex.

c. After synchronization to the NCS common channel is established, the MES should
automatically transmit a LOG-IN REQUEST packet to the NCS and receive back a LOG-IN
ACKNOWLEDGEMENT packet containing the network information.

d. Interrogate the DCE from the DTE and record the following data stored in the DCE's memory:

Current NCS//Preferred OR/[LES DESCRIPTOR].

e. If the result is positive (see Pass/Fail Criteria below), advise the LES that the MES has
successfully completed the Log-in procedure.

f. Upon successful completion, the tests will automatically proceed to Test Item 21-B under the
control of the NCS.

4 TEST PROCEDURE AT THE LES

a. When the MES manufacturer declares himself ready to commence the tests, advise
INMARSAT OCC to obtain the authorization to proceed. After positive reply, inform the
MES manufacturer through the coordination link that the tests can commence.

b. Ensure that the Log-in procedure between the MES and NCS has been successfully
completed.

c. Proceed with Test Item 21-B.

5 PASS/FAIL CRITERIA

MES:

The MES shall log-in and update the internal network information from the network configuration packet received
from the NCS as:

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 10


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

Current NCS: ..........

Preferred OR: ..........

LES1 DESCRIPTOR: ..........

LES2 DESCRIPTOR: ..........

LESn DESCRIPTOR: ..........

No abnormal conditions should have been observed.

LES:

N/A, for record only.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 11


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 21-B PERFORMANCE VERIFICATION

1 PURPOSE OF THE TEST

The test will demonstrate that the MES is capable of carrying out the Performance Verification test as stated in
SDM Volume 3, Part 2, Chapter 2, section 9.3 and SDM Volume 1, Chapter 4, section 10.2.

2 APPLICABILITY

All classes of MESs.

3 TEST PROCEDURE AT THE MES

a. After completion of Test Item 21-A, the MES should remain idle and waiting for the
ANNOUNCEMENT(PVT) from the NCS; throughout the following steps record the
behaviour and indications from the MES/DTE.

b. The MES shall automatically start to perform the processes below:

b.1 To-Mobile message transfer;

b.2 From-Mobile message transfer;

c. After completion of step b. the MES operator shall receive a request to initiate a Distress
Alert. If the distress alert is not activated by the operator the MES shall automatically
transmit a distress alert test after 2 minutes.

d. The MES should now receive a TEST RESULT packet from the LES and transmit back a
TEST RESULT ACKNOWLEDGEMENT: the PVT is now completed.

e. Interrogate the DCE from the DTE about the results of the test and record the data. If the test
is passed, the MES is now commissioned. Advise the testing LES about completion of the
PVT and proceed with Test Item 22-A.

4 TEST PROCEDURE AT THE LES

a. After receiving confirmation from the MES manufacturer that the PVT has been successfully
completed, check* in the database the status of the MES under test and record.

Note*: The process of updating the status of MESs from the NCS to the LESs via the Interstation
Signalling Links does not normally take longer than two minutes, therefore make allowances
for this delay.

b. Proceed with Test Item 22-A.

5 PASS/FAIL CRITERIA

MES:

No abnormal conditions should have been observed and the PV Test Result information retrieved from
the DCE shall indicate the test as "PASSED".

LES:

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 12


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The Database should indicate that the status of the MES under test is now updated to
"COMMISSIONED".

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 13


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 22-A TO-MOBILE MESSAGE TRANSFER

1 PURPOSE OF THE TEST

The test will demonstrate that the MES is capable of successfully receiving a shore-originated message
and store it for later retrieval by the operator.

2 APPLICABILITY

All classes of MESs.

3 TEST PROCEDURE AT THE MES

a. Make sure that the MES is still synchronised to the NCS TDM and the Destination LES
selected is the testing LES: update the operating parameters via the DTE if necessary.

b. Advise the testing LES that the MES is now ready to receive a To-Mobile message, leaving
the MES in the idle state.

c. When a message has been received, request the DCE to transfer the message to the DTE for
display.

d. Record the message as received and notify the LES about the completion of the test; proceed
with Test Item 22-B.

4 TEST PROCEDURE AT THE LES

a. After being notified by the MES manufacturer of his readiness to receive a message, initiate a
To-Mobile message transfer to the MES under test using the previously prepared test message
(ref. PREPARATION FOR TESTING AT THE NCS/LES).

b. Throughout the transaction monitor and record all the packets received from the MES
including the ACKNOWLEDGEMENT(s) packets.

c. Estimate the Packet Error Rate from the total number Nt of message packets transmitted
(including retransmissions) and the number N0 of packets of the test message:

PER = 1 - N0/Nt

d. After successful completion of the To-Mobile message transfer, proceed to Test Item 22-B.

5 PASS/FAIL CRITERIA

MES:

The call shall be normally cleared by the LES (CLEAR) without any abnormal conditions being
observed and the message retrieved from the DCE shall be a replica of the test message given above
(PREPARATION FOR TESTING AT THE NCS/LES).

LES:

The estimated PER shall be consistent with the received C/No at the MES and preferably less than
0.01. The last ACKNOWLEDGEMENT packet received by the MES shall indicate no packets in error
to be retransmitted.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 14


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 22-B FROM-MOBILE MESSAGE TRANSFER

1 PURPOSE OF THE TEST

The test will demonstrate that the MES is capable of transferring a pre-formatted message to the LES.

2 APPLICABILITY

All classes of MESs.

3 TEST PROCEDURE AT THE MES

a. Make sure that the MES is still synchronised to the NCS TDM and the test message no.1
previously prepared is still available at the DTE.

b. Leaving the MES in the idle state, advise the testing LES that the MES is now ready to initiate
a From-Mobile message transfer. Throughout the following steps monitor and record the
behaviour of the MES.

c. After obtaining the authorization to proceed from the LES, transfer the test message no.1 from
the DTE to the DCE and initiate a From-Mobile message transfer.

d. Check that a normal CLEAR packet is received at the end of the transaction and report the
completion of the test to the LES.

e. Repeat steps b. to d. with a country code less than 3 digits.

4 TEST PROCEDURE AT THE LES

a. After being notified by the MES manufacturer of his readiness to transmit messages authorize
the start of the test.

b. Throughout the test, monitor and record all the packets received from the MES. If possible
record signal levels, frequency offsets and burst timing for all signalling channel transmissions
from the MES.

c. After the MES has begun to transmit the message on the assigned Message Channel, record
the level and frequency (if feasible) of the MES signal from the MES message channel
demodulator. Estimate (if possible) the frequency offset from nominal and the equivalent
EIRP and record.

d. Estimate the Packet Error Rate from the total number Nt of message packets received
(including retransmissions) and the number N0 of packets of the test message:

PER = 1 - N0/Nt

e. If any abnormal conditions are observed in measuring the MES EIRP and frequency offset,
request the MES to increase the size* of the test message no.1 and repeat the test. Otherwise,
proceed to Test Item 22-C.

Note *: Every 80 lines of QBF take approximately one minute to be transmitted, assuming a second
generation satellite (two minutes in the case of first generation satellites) excluding call set up
and clear down times.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 15


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

5 PASS/FAIL CRITERIA

MES:

The messages shall be successfully transferred to the LES without any abnormal conditions being
observed. A leading zero should be in assignment request packet in step e.

LES:

- The messages shall be received error-free and the estimated PER shall be consistent with the received
C/No at the LES as estimated from the measured signal strength (EIRP) and preferably no greater than
0.01.

- The estimated EIRP and frequency offset should be within the following limits:

EIRP: typically between +10 and +16 dBW +/- 4 dB to allow for multipath etc.

[Note: As a rough guide, 10 dBW corresponds to approximately 30.5 dBHz (I gen) or 33.5
dBHz (II gen) and 16 dBW corresponds to approximately 36.5 dBHz (I gen) and 39.5 dBHz
(II gen)];

Carrier frequency: typically well within +/- 1300 Hz from nominal;

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 16


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 22-C OFF-LINE OPERATION

1 PURPOSE OF THE TEST

The test shall demonstrate that off-line operations of the DTE or Printer will not prevent incoming calls
from being received and stored and the messages can be retrieved and displayed by the MES operator
when the peripheral equipment are restored on-line.

2 APPLICABILITY

All classes of MESs in which the output device(s) are able to be used off-line.

3 TEST PROCEDURE AT THE MES

a. If the test is not applicable to the MES model under test (refer to APPLICABILITY Section
above), skip to Test Item 22-D.

b. Make sure that the MES is still synchronised to the NCS TDM; set the DTE off-line and
disconnect the Printer from the MES.

c. Advise the testing LES that the MES is now ready to receive a To-Mobile message; leave the
MES in the idle state and operate the DTE and Printer in off-line for 10 minutes. Observe
during this period the behaviour of the MES and record.

d. Set the output devices back on-line and record their response. Interrogate the DCE by the
DTE about the received message(s) and request the DCE to transfer the message(s) to the
DTE and Printer.

e. Record the message(s) as displayed and printed and notify the LES about the completion of
the test; proceed with Test Item 22-D.

4 TEST PROCEDURE AT THE LES

a. If this test is not applicable to the MES model under test (refer to APPLICABILITY Section
above and Authorization Telex from INMARSAT), skip to Test Item 22-D.

b. After being notified by the MES manufacturer about his readiness of receiving a message,
initiate* a To-Mobile message transfer to the MES under test using the previously prepared
test message (ref. PREPARATION FOR TESTING AT THE NCS/LES).

Note *: Ensure that the message is transmitted within 10 minutes from the notification of "MES ready".

c. Throughout the transaction monitor and record all the packets received from the MES
including the ACKNOWLEDGEMENT(s) packets.

d. Estimate the Packet Error Rate from the total number Nt of message packets transmitted
(including retransmissions) and the number N0 of packets of the test message:

PER = 1 - N0/Nt

e. After successful completion of the To-Mobile message transfer, proceed to Test Item 22-D.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 17


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

5 PASS/FAIL CRITERIA

MES:

The call has been normally cleared by the LES (CLEAR) without any abnormal conditions being
observed and the message retrieved from the DCE shall be a replica of the test message given above
(PREPARATION FOR TESTING AT THE NCS/LES).

LES:

The estimated PER shall be consistent with the received C/No at the MES and preferably less than
0.01. The last ACKNOWLEDGEMENT packet received by the MES shall indicate no packets in error
to be retransmitted.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 18


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 22-D FORCED CLEARING

1 PURPOSE OF THE TEST

The test shall demonstrate that the MES can both initiate and respond to FORCED CLEAR packets.

2 APPLICABILITY

All classes of MESs.

3 TEST PROCEDURE AT THE MES

a. Make sure that the MES is still synchronised to the NCS TDM; check the operating
parameters in the DCE and update them if necessary through the DTE.

b. Advise the testing LES that the MES is now ready to receive a To-Mobile message; leave the
MES in the idle state and observe during the following steps the behaviour of the MES and
record.

c. When the indication that a message is being received appears, initiate a request for clear
(CLEAR REQUEST).

d. Wait for the MES to become idle and synchronised to the NCS; interrogate via the DTE the
MES status and received messages and report the result to the LES.

e. Initiate a From-Mobile message transfer with the test message no.1 and while the message is
being transmitted, initiate a CLEAR REQUEST.

f. Wait for the MES to become idle and synchronised to the NCS; interrogate via the DTE the
MES status and report the result to the LES.

g. Advise the testing LES that the MES is now ready to receive a second To-Mobile message;
leave the MES in the idle state and observe during the following steps the behaviour of the
MES and record.

h. If the MES has passed the test (see PASS/FAIL CRITERIA) proceed to Test Item 23-A.

4 TEST PROCEDURE AT THE LES

a. After being notified by the MES manufacturer about his readiness to receive a message,
initiate* a To-Mobile message transfer to the MES under test using the previously prepared
test message (ref. PREPARATION FOR TESTING AT THE NCS/LES).

b. Following completion of the To-Mobile and From-Mobile message transfers (both cleared by
the MES operator), initiate a To-Mobile message transfer to the MES under test and clear the
call during the transmission by issuing a forced clear to the MES.

5 PASS/FAIL CRITERIA

MES: The To-Mobile message transfers shall have been aborted and the To-Mobile messages or any
part of them should be neither available in memory nor should have been displayed.

LES: The MES aborted calls should be cleared correctly. The LES cleared call should have been
terminated with no further response from the MES.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 19


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 23-A DISTRESS ALERT TRANSMISSION

1 PURPOSE OF THE TEST

The test shall demonstrate that the MES is capable of generating at any time a Distress Alert as stated
in SDM, Volume 1, Chapter 4, Section 6.3 and SDM, Volume 3, Part 2, Chapter 5, Section 8.

2 APPLICABILITY

All classes of MESs for use in GMDSS and in general, MESs fitted with Distress Alerting capability.

3 TEST PROCEDURE AT THE MES

a. If the test is not applicable to the MES model under test (refer to APPLICABILITY Section
above), skip to Test Item 24-A.

b. Make sure that the MES is still synchronised to the NCS TDM; check the operating and the
Distress Message parameters via the DTE and update them if different from the standard
conditions for testing (see PREPARATION FOR TESTING).

c. Advise the testing LES about the MES geographical coordinates and that the MES is now
ready to transmit a Distress Alert; leave the MES in the idle state and wait for the
authorization from the LES.

d. After the authorization to proceed has been received from the LES (normally after few
minutes), initiate the Distress Alert and observe during this period the behaviour of the MES
and record.

e. Upon completion of step d. (ACKNOWLEDGMENT packet received from the LES), check
that the MES is back to the idle state and synchronised to the NCS TDM. Initiate a From-
Mobile message transfer using the test message no.1: while the message is being transmitted,
initiate a Distress Alert and record.

f. When the MES has returned to the idle state and synchronised to the NCS TDM, advise the
test LES that the MES is now ready to receive a To-Mobile message.

g. While the To-Mobile message is being received, initiate a Distress Alert and record.

h. Upon completion of step g. (ACKNOWLEDGMENT packet for the Distress Alert received
from the LES), check that the MES has returned to the idle state and synchronised to the NCS
TDM; proceed to Test Item 23-B.

4 TEST PROCEDURE AT THE LES

a. If this test is not applicable to the MES model under test (refer to APPLICABILITY Section
above and Authorization Telex from INMARSAT), skip to Test Item 24-A.

b. After being notified by the MES manufacturer about his being ready to transmit a Distress
Alert, contact the associated Rescue Coordination Centre (RCC), if applicable, and inform
them about the imminent Distress tests with the MES no. [XXX..XXXXX]: no action is
expected from them upon receipt of Distress messages originated by the MES no.
[4XXXX..XX] until further notice.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 20


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

c. Authorize the MES to proceed with the test and record the Distress Alert as received at the
LES.

d. After completion of the Distress Alert, the MES should initiate a From-Mobile message
transfer; while the message is being received at the LES, monitor all the packets received and
check that a DISTRESS ALERT has been received on the Signalling Channel from the MES
under test. Record the received DISTRESS ALERT packet.

e. After the MES manufacturer has informed about his readiness for receiving a To-Mobile
message, initiate a To-Mobile message transfer to the MES under test using the previously
prepared test message (ref. PREPARATION FOR TESTING AT THE NCS/LES).

f. Throughout the transaction monitor the packets received on the Signalling Channel and record
any DISTRESS ALERT packets received from the MES under test.

g. Proceed to Test Item 23-B.

5 PASS/FAIL CRITERIA

MES:

With reference to the above procedure, the Distress Alerts transmitted in steps d.,e. and g. shall have
been acknowledged by the LES.

LES:

A DISTRESS ALERT packet shall have been received during each of the steps c.,d. and f.; the content
shall be the same for all the packets as:

MES ID: 24-bit code (RTN) for the MES under test;

LES ID: Code of the LES;

POSITION: Geographical coordinates of the MES;

POSITION and COURSE/SPEED UPDATE: 1 or 0;

NATURE: 0 (unspecified);

COURSE: 0;

SPEED: 0;

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 21


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 23-B DISTRESS MESSAGE TRANSMISSION

1 PURPOSE OF THE TEST

The test shall demonstrate that the MES is capable of transmitting a message requesting a channel with
Distress Priority.

2 APPLICABILITY

All classes of MESs for use in GMDSS and in general, MESs fitted with Distress Alerting capability.

3 TEST PROCEDURE AT THE MES

a. Make sure that the MES is still synchronised to the NCS TDM; check the operating
parameters via the DTE and update them if different from the standard conditions for testing
(see PREPARATION FOR TESTING). Set the priority for the next message transfer as
Distress.

c. Advise the testing LES that the MES is now ready to initiate a From-Mobile message transfer
with Distress priority; leave the MES in the idle state and wait for the authorization from the
LES.

d. After the authorization to proceed has been received from the LES, initiate a From-Mobile
message transfer with the test message no.2 and observe during this period the behaviour of
the MES and record.

e. Upon normal completion of step d. (CLEAR packet received from the LES), check that the
MES is back to the idle state and synchronised to the NCS TDM. Query the status of the
transaction via the DTE and record the response.

f. Advise the LES about successful completion of the test and proceed to Test Item 24-A.

4 TEST PROCEDURE AT THE LES

a. After being notified by the MES manufacturer about his being ready to transmit a From-
Mobile message with Distress priority, authorize the MES to proceed with the test and record
the ASSIGNMENT REQUEST as received at the LES on the Signalling channel.

b. Record all the packets of the From-Mobile message as it is being received at the LES.

c. At completion of the transaction, after the CLEAR packet has been sent, advise the RCC that
the tests for Distress Alert with the MES no.[4XXX..XX] are over.

d. Proceed to Test Item 24-A.

5 PASS/FAIL CRITERIA

MES:

With reference to the above procedure, no abnormal responses shall have been observed and the
message successfully transferred.

LES:

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 22


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The ASSIGNMENT REQUEST packet shall have been received with the priority field set to Distress
and the message received shall be a replica of the test message no.2 (see PREPARATION FOR
TESTING AT THE MES).

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 23


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 24-A LOG-OUT AND LOG-IN

1 PURPOSE OF THE TEST

The test shall demonstrate that the MES is capable of manually logging-out the NCS network as set
forth in SDM Volume 3, Part 2, Chapter 2, section 6.5.1 and section 6.5.2.

2 APPLICABILITY

All classes of MESs.

3 TEST PROCEDURE AT THE MES

a. Initiate a Log-out request to the current NCS.

b. After completion of step a. (LOG-OUT ACK received) check the content of the non-volatile
memory via the DTE and record.

c. Initiate a log-in request to the current NCS.

d. Initiate a log-out request to the current NCS.

e. Initiate a log-in request to a new NCS.

f Turn off the MES, inform the LES about the completion of the tests and discuss any
discrepancies found. Record the results in the Test Data Sheets and forward them to the
responsible INMARSAT MES Engineer (refer to INMARSAT telex).

4 TEST PROCEDURE AT THE LES

a. After the MES has informed the LES of its imminent logging-out, check the MES status in the
LES database and record.

b. Refer to the MES manufacturer any discrepancies found during testing and record the results
of the tests in the Test Data Sheets.

c. Advise the INMARSAT OCC and the NCS that the tests have been completed and inform
about their outcome; forward the test report to the responsible INMARSAT MES Engineer
(refer to INMARSAT telex).

5 TEST PROCEDURE AT THE NCS

a. [Immediately after the LES has informed that the tests have been completed, erase the MES
IDs from the database and update the MES status via the Interstation Signalling Links].

6 PASS/FAIL CRITERIA

Log-out requests should be successful in step a. and step d.

Log-in requests should be successful in step c. and step e. And the version number in the request packet should
ramain unchanged in step c. and should be set to zero in step e.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 24


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 25-A ALTERNATIVE NETWORK SERVICES: FROM-MOBILE MESSAGE TRANSFER

1 PURPOSE OF THE TEST

The test will demonstrate that the MES is capable of transferring a pre-formatted data message to the
LES.

This test applies to MESs supporting any of the optional services of PSTN, PSDN, Closed Network or
Special Access Code.

2 APPLICABILITY

All classes of MESs.

3 TEST PROCEDURE AT THE MES

(a) Prepare a test data message, of 448 bytes in length, at the DTE. If the MES is designed to send
IA5 code to a data network, then test message No. 1 can be used.

(b) Make sure that the MES is still synchronised to the NCS TDM and the test message
previously prepared is still available at the DTE.

(c) Leaving the MES in the idle state, advise the testing LES that the MES is now ready to initiate
a From-Mobile data message transfer. Throughout the following steps monitor and record the
behaviour of the MES.

(d) After obtaining the authorization to proceed from the LES, transfer the test message from the
DTE to the DCE and initiate a From-Mobile message transfer.

(e) Check that a normal CLEAR packet is received at the end of the transaction and report the
completion of the test to the LES.

(f) Repeat steps b. to e. for each network service type supported by the MES.

3 TEST PROCEDURE AT THE LES

(a) After being notified by the MES manufacturer of his readiness to transmit a message, the LES
operators will authorize the start of the test.

(b) Throughout the test, monitor and record all the packets received from the MES.

7 PASS/FAIL CRITERIA

MES: The message shall be successfully transferred to the MES for each packet type without any
abnormal conditions being observed.

LES: The message shall be received error-free.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 25


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 25-B ALTERNATIVE NETWORK SERVICES - X.400: FROM-MOBILE MESSAGE


TRANSFER

1 PURPOSE OF THE TEST

The test will demonstrate that the MES is capable of transferring a pre-formatted data message to the
LES.

2 APPLICABILITY

This test applies to MESs supporting the optional X.400 network service.

3 TEST PROCEDURE AT THE MES

(a) Prepare a test data message, at the DTE.

The Data field is divided into a header and a body. The header contains the X.400 elements of
service and the body contains the user text or data. An example valid header is as follows:

TO: C=GB; A=ATTMAIL; P=INMARSAT; O=Land; S=Smith; G= John,

S=Janset; G=Jan; P=PTT Research; A=400NET; C=NL

FROM: 581492360025

OUR-REF: Recommended Test Procedure

BODY-TYPE: IA5

STX;

For alternative forms of the header see section 3.1.2 of the "Basic Inmarsat-C/X.400
interworking Technical note" available from Inmarsat. Note that the header is a text string in
IA5. The parity bit is ignored and it is recommended that it be set to zero. It may however be
set to odd parity. Leading spaces and newlines in the header have no significance. Note
especially that the body of the message follows the header immediately after the end of header
marker STX;

If the above example header is used, the body of the message should be in IA5. Alternative
body types may be used, but will require the above header to be changed so that BODY-
TYPE: is set to an appropriate type, such as ITA2 or EXT=.

If the body type is IA5, as in the above example header, the parity bit is ignored and it is
recommended that it be set to zero. In this case test message No. 1 may be used for the body
part of this X.400 test message. The body part should be sufficiently long that at least two
packets are required to convey the message.

Note that the body type is defined in the header. The header is always in IA5. Presentation
should be set 80H. Last Count must be set to the number of bytes in the [Data] field of the last
message packet, whatever body type is used.

(b) Make sure that the MES is still synchronised to the NCS TDM and the test message
previously prepared is still available at the DTE.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 26


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

(c) Leaving the MES in the idle state, advise the testing LES that the MES is now ready to initiate
a From-Mobile data message transfer. Throughout the following steps monitor and record the
behaviour of the MES.

(d) After obtaining the authorization to proceed from the LES, transfer the test message from the
DTE to the DCE and initiate a From-Mobile message transfer.

(e) Check that a normal CLEAR packet is received at the end of the transaction and report the
completion of the test to the LES.

3 TEST PROCEDURE AT THE LES

(a) After being notified by the MES manufacturer of his readiness to transmit a message, the LES
operators will authorize the start of the test.

(b) Throughout the test, monitor and record all the packets received from the MES.

7 PASS/FAIL CRITERIA

MES: The message shall be successfully transferred to the MES without any abnormal conditions
being observed.

LES: The message shall be received error-free.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 27


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 26-A DOWNLOADING AND DELETING DNIDs

1 PURPOSE OF THE TEST

The test will demonstrate that the MES complies with the specifications as set forth in SDM Volume 4,
Chapter 9, section 2.4.4.2.11 and 2.4.4.2.12, and SDM Volume 3, Part 2, Chapter 3, section 4.2.

2 APPLICABILITY

All classes of MESs which support Polling and Data Reporting Service.

3 TEST PROCEDURE

a. Establish a coordination link (eg by telephone) with the LESs and inform about readiness to
start testing.

b. Turn on the MES which has been commissioned. After synchronization to the NCS common
channel is established, send Download DNID polls with the following settings:

b.1 DNID-1 LES ID-X Sub-address - 1 Response - 00

Command-8A Member No.-1 Sequence No.-1 Text - 1

b.2 DNID-2 LES ID-X Sub-address - 1 Response - 00

Command-8A Member No.-1 Sequence No.-1 Text - 1

b.3 DNID-3 LES ID-X Sub-address - 1 Response - 00

Command-8A Member No.-1 Sequence No.-1 Text - 1

b.4 DNID-3 LES ID-Y Sub-address - 1 Response - 00

Command-0A Member No.-1 Sequence No.-1 Text - 1

b.5 DNID-3 LES ID-Z Sub-address - 1 Response - 00

Command-0A Member No.-1 Sequence No.-1 Text - 1

b.6 DNID-1 LES ID-X Sub-address - 1 Response - 00

Command-8A Member No.-2 Sequence No.-2 Text - 2

b.7 DNID-2 LES ID-X Sub-address - 1 Response - 00

Command-8A Member No.-3 Sequence No.-3 Text - 3

b.8 Repeat step b.7 with different DNIDs until the memory is full.

b.9 Download a new DNID to the MES.

b.10 Use an operator' command to inhibit one DNID stored in memory.

b.11 Download a new DNID to the MES.

c. Send the individual polls with the following settings:

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 28


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

c.1 Correct MES ID DNID-N LES ID-X

Member No.-1 Command-8B Sequence No.-D

c.2 Invalid MES ID DNID-1 LES ID-X

Member No.-1 Command-8B Sequence No.-D

c.3 Correct MES ID DNID-1 LES ID-N

Member No.-1 Command-0B Sequence No.-D

c.4 Correct MES ID DNID-1 LES ID-X

Member No.-1 Command-8B Sequence No.-S

d. Send the group polls with the following settings:

d.1 DNID-2 LES ID-N Command-0B Sequence No.-D

d.2 DNID-N LES ID-X Command-8B Sequence No.-D

d.3 DNID-0 LES ID-X Command-8B Sequence No.-D

d.4 DNID-2 LES ID-X Command-8B Sequence No.-S

d.5 Delete all the DNIDs.

e. Send the individual polls with the following settings:

e.1 DNID-12345 LES ID-X Sub-address - 1

Response - 00 Command-8A Member No. -1

e.2 DNID-12345 LES ID-Y Sub-address - 1

Response - 00 Command-8A Member No. -1

e.3 DNID-12346 LES ID-X Sub-address - 1

Response - 00 Command-8A Member No. -2

e.4 DNID-12347 LES ID-X Sub-address - 1

Response - 00 Command-8A Member No. -4

Note: X, Y, Z - LES ID.

N - Unknown LES ID or DNID.

D - Different sequence number from the previous one.

S - Same sequence number as the previous one.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 29


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

4 PASS/FAIL CRITERIA

The DNIDs downloaded from step b.1 to b.5 should be stored in non-volatile memory and the data
reports containing ACK in steps b.1, b.2 and b.3 should be sent to the LESs.

The DNIDs downloaded in steps b.6 and b.7 should be stored in non-volatile memory and the existing
member numbers and texts downloaded in steps b.1 and b.2 should be overwritten.

The poll in step b.9 should be ignored but an ACK should be sent to the LES.

The poll in step b.11 should be accepted and the DNID inhibited should be overwritten.

The DNID list should remain unchanged when the polls in steps c.1, c.2 and c.3 are sent out. However,
an ACK should be sent to the LES in setup c.1.

The DNID-1/LES ID-X pair should be deleted when the poll in step c.4 is received.

The MES should ignore the polls in steps d.1, d.2, and d.3, and not send ACKs.

The DNID-2/LES ID-X pair should be deleted and an ACK should be sent to the LES when the poll in
step d.4 is received.

All the DNIDs stored in non-volatile memory should be removed when the test step d.5 is completed.

The DNIDs downloaded from step e.1 to e.4 should be stored in non-volatile memory

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 30


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 26-B DATA TRANSMISSION

1 PURPOSE OF THE TEST

The test will demonstrate that the MES is capable of receiving the data as stated in SDM Volume 4,
Chapter 9, section 2.4.4.2.10.

2 APPLICABILITY

All classes of MESs which are designed to receive "Data Transmission" polls.

3 TEST PROCEDURE

a. Set up the MES's position and Navarea address.

Navarea =9

Position = 34o44'00" N, 35o21'00" E

b. Send the following Data Transmission polls to the MES:

b.1 Individual poll (ACK bit set) to DNID 12345 /LES ID-Y

b.2 Individual poll (ACK bit set) to DNID 12345 /LES ID-Z

b.3 Individual poll (ACK bit set) to DNID 22345 /LES ID-X

b.4 Individual poll (ACK bit set) to DNID 12345 /LES ID-X

b.5 Area poll (Navarea is set to 9) to DNID 12345/LES ID-X

b.6 Area poll (Navarea is set to 9) to DNID 22345/LES ID-X

b.7 Area poll (Navarea is set to 5) to DNID 12345/LES ID-X

b.8 Group poll (ACK bit set and Randomising Interval = 50) to DNID 12346/LES-X

b.9 Group poll (ACK bit set and Randomising Interval = 50) to DNID 12347/LES-Y

b.10 Group poll (ACK bit set and Randomising Interval = 50) to DNID 12347/LES-X

b.11 After 24 hours, repeat b.10 with the same sequence number.

b.12 After 12 hours, repeat b.10 with the same sequence number.

4 PASS/FAIL CRITERIA

The messages should be received in steps b.1, b.4, b.5, b.8, b.10, b.11.

The MES should randomize over the 50 frames before sending ACKs and may not tune to the LES
during randomising in steps b.8 and b.10.

The MES should ignore the polls and not send ACKs in steps b.2, b.3, b.6, b.7,b.9, b12.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 31


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 26-C INITIATING DATA REPORTS AT MES

1 PURPOSE OF THE TEST

The test will demonstrate that the MES is capable of sending data reports as specified in SDM Volume
4, Chapter 8.

2 APPLICABILITY

All classes of MESs which support Data Reporting Service.

3 TEST PROCEDURE

a. Create a three-packet data report.

b. Send the data report to the destinations: DNID-12345 / LES ID-X and DNID-12346 / LES
ID-X respectively.

c. Record the result of transmissions at DTE.

d. Try to insert a DNID/LES ID pair which is not stored in non-volatile memory.

4 PASS/FAIL CRITERIA

The data report should be successfully transmitted up to step c.

In step d., an attempt must fail.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 32


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 26-D INITIATING UNRESERVED REPORTS AS REQUIRED IN [RESPONSE] FIELD

1 PURPOSE OF THE TEST

The test will demonstrate that the MES is capable of transmitting the message or data reports as
required in [response] field.

2 APPLICABILITY

All classes of MESs which support this service.

3 TEST PROCEDURE

a. Prepare the message and the data report which will be initiated by the polls.

b. Send the Individual polls with the following settings:

b.1 Correct MES ID DNID-12345 LES ID-X

Response-01 Command-00 Member No.-1

b.2 Correct MES ID DNID-22355 LES ID-X

Response-01 Command-00 Member No.-1

b.3 Correct MES ID DNID-12347 LES ID-X

Response-10 Command-00 Member No.-4

b.4 Correct MES ID DNID-12347 LES ID-Y

Response-10 Command-00 Member No.-4

b.5 Wrong MES ID DNID-12347 LES ID-X

Response-10 Command-00 Member No.-4

b.6 Repeat step b.1 but Command is changed to 80.

c. Send the group polls with the following settings:

c.1 DNID-12346 LES ID-X Response-01 Command-00

c.2 DNID-12346 LES ID-Y Response-10 Command-00

c.3 Repeat step c.1 but Command is changed to 80.

4 PASS/FAIL CRITERIA

The data report and the message should be transmitted when the polls in steps b.1, b.3 and c.1 are
received.

The data reports should be transmitted and ACK requests may be ignored in steps b.6 and c.3.

The polls in steps b.2, b.4, b.5 and c.2 should be ignored by the MES.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 33


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 26-E PROGRAMMING UNRSERVED DATA REPORTING

1 PURPOSE OF THE TEST

The test will demonstrate that the MES is capable of storing all parameters as specified in SDM
Volume 4, Chapter 9, Section 2.4.4.2.5.

2 APPLICABILITY

All classes of MESs which support Unreserved Data Reporting Service.

3 TEST PROCEDURE

a. Send the Group polls with the following settings:

a.1 DNID-12345 LES ID-X LES TDM- 11111

Sub-address-1 Randomising-30 Response-00

Command-04 Start Frame- C+80 Interval-100

a.2 DNID-12347 LES ID-X LES TDM- 11111

Sub-address-1 Randomising-30 Response-00

Command-04 Start Frame- C+200 Interval-100

a.3 DNID-22355 LES ID-X LES TDM- 11111

Sub-address-1 Randomising-30 Response-00

Command-04 Start Frame- C+250 Interval-100

Note: C means current frame number.

b Monitor and record the behaviour of the MES after each poll arrives.

4 PASS/FAIL CRITERIA

The polls in steps a.1 and a.2 should be accepted and the parameters in the polls should be stored. The
poll in step a.3 should be ignored.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 34


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 26-F INITIATING UNRESERVED DATA REPORTING

1 PURPOSE OF THE TEST

The test will demonstrate that the MES is capable of transmitting the data reports as required by the
poll.

2 APPLICABILITY

All classes of MESs which support Unreserved Data Reporting service.

3 TEST PROCEDURE

a. Before frame C+80, send the area polls with the following settings:

a.1 DNID-12346 LES ID-X LES TDM- 10970

Sub-address-1 Randomising - 3 Response-01

Type-3 Length-4 Area-33N033E05005

Command-85

a.2 Repeat step a.1 but DNID is set to 12345 and Command is set to 05.

a.3 DNID-12347 LES ID-X LES TDM- 10970

Sub-address-1 Randomising - 3 Response-01

Type-4 Length-4 Area-32N034E100

Command-85

a.4 Repeat step a.3 but Area is set to 32N034E200, Command is set to 05 and a new sequence
number is used.

b After completion of othre tests, repeat the step a.4 but send the above poll just after frame
C+200.

c Monitor and record the behaviour of the MES.

4 PASS/FAIL CRITERIA

The MES should ignore the poll in step a.1, but should send an ACK.

The MES should ignore the poll in step a.3 and not send an ACK.

After receiving the polls in steps a.2 and a.4, the MES should transmit the data reports with
randomising over 3 frames at the specified times.

For step b, the MES should not transmit the data reports until next day.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 35


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 26-G STOPPING UNRESERVED DATA REPORTING

1 PURPOSE OF THE TEST

The test will demonstrate that the MES is capable of stopping unreserved data reports as required by
the polls.

2 APPLICABILITY

All classes of MESs which support Unreserved Data Reporting service.

3 TEST PROCEDURE

a. After frame C+300, send the area polls with the following settings:

a.1 DNID-12345 LES ID-X Randomising -1

Response-00 Type-3 Length-4

Area-20N033E05005 Command-86

a.2 DNID-12345 LES ID-Y Randomising -1

Response-00 Type-3 Length-4

Area-31N032E05005 Command-86

a.3 DNID-12345 LES ID-X Randomising -1

Response-00 Type-3 Length-4

Area-31N032E05005 Command-86

a.4 DNID-0 LES ID-X Randomising -1

Response-00 Type-4 Length-4

Area-32N034E200 Command-86

b. Repeat Test Item 26-F and 26-G without ACK requests.

c. After frame C+300, logout the MES.

d. Log the MES back into the Ocean Region.

e. Log the MES into another Ocean Region.

f. Log the MES back into the previous Ocean Region.

g. Repeat step a.4.

4 PASS/FAIL CRITERIA

The MES should ignore the polls in steps a.1 and a.2.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 36


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

The MES should send ACKs with no randomization and stop transmitting the data reports after
receiving the polls in steps a.3 and a.4.

The scheduled data reports should not be sent after step c.

Data reports start again after step d.

The scheduled data reports should not be sent after step e.

Data reports start again after step f.

The MES should stop sending data reports after step g.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 37


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 26-H INTERRUPTIONS TO UNRSERVED DATA REPORTING

1 PURPOSE OF THE TEST

The test will demonstrate that the MES complies with the specifications stated in SDM Volume 3, Part
2, Chapter 2, Section 2.1.1.

2 APPLICABILITY

All classes of MESs which support Reserved Data Reporting Service.

3 TEST PROCEDURE

a. Send two Group polls within the same frame (within different frames if the MES does not
support Multi-threading) with the following settings:

a.1 DNID-12345 LES ID-X LES TDM- 10970

Sub-address-1 Randomising-3 Response-00

Command-04 Start Frame- C+80 Interval-100

a.2 DNID-12345 LES ID-X LES TDM- 10970

Sub-address-1 Response-01 Command-05

Randomising -30

b. Prepare a long EGC message and send it to the MES when the second data report is due.

c. Send an Announcement packet when the MES is randomising and attempting to send the
fourth data report.

d. Initiate a distress alert or land mobile alert during randomising period.

4 PASS/FAIL CRITERIA

The MES should accept two polls in step a. and start unreserved data reporting.

The EGC message should be received in step b.

The To-Mobile message transfer should start and the scheduled data report should be abandoned in
step c.

The distress alert or land mobile alert should succeed and the data report should cease.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 38


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 26-I PROGRAMMING RESERVED DATA REPORTING

1 PURPOSE OF THE TEST

The test will demonstrate that the MES complies with the specifications stated in SDM Volume 1,
Chapter 7 and Volume 4, Chapter 10.

2 APPLICABILITY

All classes of MESs which support Reserved Data Reporting Service.

3 TEST PROCEDURE

a. Send the Individual polls with the following settings:

a.1 DNID-12345 LES ID-X Response-00

Command-81 Member No.-1 Start Frame- C+80

Packets per Report-1 Slot No-3 Interval-100

Duration-2

a.2 DNID-12346 LES ID-X Response-00

Command-01 Member No.-1 Start Frame- C+120

Packets per Report-3 Slot No-3 Interval-100

Duration-20

a.3 DNID-22355 LES ID-X Response-00

Command-81 Member No.-6 Start Frame- C+140

Packets per Report-2 Slot No.4 Interval-100

Duration-20

b. Send a group poll with a valid DNID/LES ID pair, a Command 86 and some data in the text
field to the MES.

c. Interrogate the DCE from the DTE and record all parameters stored in the memory.

4 PASS/FAIL CRITERIA

The MES should accept the polls and store all parameters required for Reserved Data Reporting in
steps a.1, a.2 and a.3 For the poll in step a.3, new DNID, LES ID and Member Number should be
stored in the memory as well.

The polls in step b. should be ignored, but an ACK should be sent to the LES.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 39


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 26-J INITIATING RESERVED DATA REPORTING

1 PURPOSE OF THE TEST

The test will demonstrate that the MES is capable of transmitting the data reports as required by the
poll.

2 APPLICABILITY

All classes of MESs which support Reserved Data Reporting service.

3 TEST PROCEDURE

a. Before frame C+80, send the group polls with the following settings:

a.1 DNID-12345 LES ID-X Randomising Interval-0

Response-01 Command-02

a.2 DNID-12346 LES ID-X Randomising Interval-0

Response-01 Command-02

a.3 DNID-22355 LES ID-X Randomising Interval-0

Response-01 Command-02

b Monitor and record the behaviour of the MES.

4 PASS/FAIL CRITERIA

After receiving the above polls, the MES should transmit the data reports in the slots and frames
assigned by the Reserved Data Reporting polls. Moreover, the MES should terminate transmission to
DNID 12345 after the second data report is sent out.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 40


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 26-K INTERRUPTIONS TO RESERVED DATA REPORTING

1 PURPOSE OF THE TEST

The test will demonstrate that the MES complies with the specifications stated in SDM Volume 1,
Chapter 7 and Volume 4, Chapter 10 and SDM Volume 3, Part 2, Chapter 5, Section 8.3.

2 APPLICABILITY

All classes of Inmarsat-C MESs which support Data Reporting service.

3 TEST PROCEDURE

a* Just before frame C+220, initiate a distress alert.

b* Just before frame C+ 240, initiate a mobile alert.

c. Just before frame C+420, initiate a From-Mobile message transfer.

d. Just before frame C+ 620, send an EGC message to the MESS.

e. Monitor and record the behaviour of the MES.

Note: The test a* is for the MES with distress alerting function and the test b* is for the MES with
mobile alerting function.

4 PASS/FAIL CRITERIA

The MES should handle the distress (or mobile) alert, the From-Mobile message transfer and the EGC
message. When each action is completed, the MES should continue the Reserved Data Reporting.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 41


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 26-L STOPPING RESERVED DATA REPORTING

1 PURPOSE OF THE TEST

The test will demonstrate that the MES is capable of stopping reserved data reports as required by the
polls.

2 APPLICABILITY

All classes of MESs which support Reserved Data Reporting service.

3 TEST PROCEDURE

a. After the Reserved Data Reporting resumed, send the area polls with the following settings:

a.1 DNID-22355 LES ID-X Randomising Interval-0

Response-00 Type-3 Length-4

Area-20N033E05005 Command-03

a.2 DNID-12346 LES ID-Z Randomising Interval-0

Response-00 Type-3 Length-4

Area-30N033E05005 Command-03

a.3 DNID-22346 LES ID-X Randomising Interval-0

Response-00 Type-3 Length-4

Area-30N033E05005 Command-03

a.4 DNID-12346 LES ID-X Randomising Interval-0

Response-00 Type-3 Length-4

Area-30N033E05005 Command-03

a.5 DNID-0 LES ID-X Randomising Interval-0

Response-00 Type-4 Length-4

Area-32N034E200 Command-03

b Monitor and record the behaviour of the MES.

4 PASS/FAIL CRITERIA

The MES should ignore the polls in steps a.1, a.2 and a.3, and stop transmitting the data reports after
receiving the polls in steps a.4 and a.5.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 42


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 26-M DATA REPORTING IN DEMAND ASSIGNED MODE

1 PURPOSE OF THE TEST

The test will demonstrate that the MES complies with the specifications stated in SDM Volume 1,
Chapter 7, Section 3.1.

2 APPLICABILITY

All classes of MESs which support Reserved Data Reporting service.

3 TEST PROCEDURE

a. Program and initiate a reserved data reporting in permanent mode. Then monitor and record
the behaviour of the MES.

b. When the first data report is completed, transmit the Network Update showing that the LES is
operating in Demand Assigned Mode. Then monitor and record the behaviour of the MES.

c After two intervals, re-program and initiate a reserved data report via the NCS Signalling
Channel. Then monitor and record the behaviour of the MES.

d. Program and initiate a unreserved data reporting in permanent mode, and then repeat steps b.
and c.

4 PASS/FAIL CRITERIA

The MES should start transmitting the data reports in the step a and terminate the data reports in the
step b. In step c., the MES should send out the data reports via the NCS signalling channel.

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 43


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

ITEM 27-A COVERT/SECURITY ALERT TRANSMISSION

1 PURPOSE OF THE TEST

The test shall demonstrate that the SES is capable of generating at any time a Covert/Security Alert as
stated in SDM, Volume 3, Part 2, Chapter 5, Annex A, Section 8.5.

2 APPLICABILITY

All classes of SESs fitted with Covert/Security Alert capability.

3 TEST PROCEDURE AT THE SES

Note: some of the following steps require a DTE. An SES with no DTE should provide an alternative
way for the purpose of this test e.g. an external DTE. If the capabilities requiring a DTE are not
supported, the corresponding steps might be waived.

a. Make sure that the SES is still synchronised to the NCS TDM; check the operating and the
Security/Covert Alert parameters via the DTE and update them as needed if different from the
standard conditions for testing (see PREPARATION FOR TESTING).

b. Inform the Inmarsat NOC and Maritime Safety Services Group and the testing LES about the
SES IMN, geographical location, Ocean Region, date and time of the test and that the SES is
now ready to transmit Covert/Security Alerts. Leave the SES in the idle state.

c. After the corresponding authorizations to proceed have been received (normally after few
minutes), initiate a Covert/Security Alert and observe and record the behaviour of the SES
during this period.

d. Upon completion of step c. (ACKNOWLEDGMENT packet for the Covert/Security Alert


received from the LES), check that the SES is back to the idle state and synchronised to the
NCS TDM. Initiate a From-Mobile message transfer using the test message no.1 and while the
message is being transmitted, initiate a Covert/Security Alert and record the SES behaviour.

e. When the SES has returned to the idle state and synchronised to the NCS TDM, advise the test
LES that the SES is now ready to receive a To-Mobile message.

f. While the To-Mobile message is being received, initiate a Covert/Security Alert and record
the SES behaviour.

g. Upon completion of step f. (ACKNOWLEDGMENT packet for the Covert/Security Alert


received from the LES), check that the SES has returned to the idle state and is synchronised
to the NCS TDM.

h. Inform the Inmarsat NOC and Maritime Safety Services Group and the testing LES about the
end of the tests so further Covert/Security Alerts from the SES should be considered as real
alerts.

4 TEST PROCEDURE AT THE LES

a. After being notified by the SES manufacturer about being ready to transmit a Covert/Security
Alert, contact the associated Rescue Coordination Centre (RCC) and inform them about the
imminent Covert/Security Alert tests with the SES no. [4XXXXXXXX]: no action is expected

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 44


Inmarsat Confidential C SDM
(Version Release CD004, CN000)

from them upon receipt of Covert/Security Alerts originated by the SES no. [4XXXXXXXX]
until further notice.

b. Authorize the SES to proceed with the test and record the Covert/Security Alert as received at
the LES.

c. After completion of the Covert/Security Alert, the SES should initiate a From-Mobile message
transfer; while the message is being received at the LES, monitor all the packets received on
the Signalling Channel and record any DISTRESS ALERT packets received from the SES
under test.

d. After the SES manufacturer has informed about being ready to receive a To-Mobile message,
initiate a To-Mobile message transfer to the SES under test using the previously prepared test
message (ref. PREPARATION FOR TESTING AT THE NCS/LES).

e. Throughout the transaction monitor the packets received on the Signalling Channel and record
any DISTRESS ALERT packets received from the SES under test.

f. After being notified by the SES manufacturer about the tests being finished, contact the
associated Rescue Coordination Centre (RCC) and inform them that further Covert/Security
Alerts from the SES no. [4XXXXXXXX] should be considered as real alerts.

5 PASS/FAIL CRITERIA

SES:

With reference to the above procedure, the Covert/Security Alerts transmitted in steps c., d. and f. shall
have been acknowledged by the LES.

LES:

A DISTRESS ALERT packet shall have been received during each of the steps b., c. and e.; the
content shall be the same for all the packets as:

MES ID: 24-bit code (RTN) for the SES under test;

LES ID: Code of the LES;

POSITION: Geographical coordinates of the SES;

NATURE: AH (“Piracy/armed attack”);

COURSE: 0 (or real value);

SPEED: 0 (or real value);

SECURITY/COVERT ALERT 1;

POSITION and COURSE/SPEED UPDATE: 1 or 0 (depending on the last update);

Recommended Test Procedures (RTPs), Section 8: Phase 2 Tests Page: 45

You might also like