Inmarsat C System Definition Manual - CD004 PDF
Inmarsat C System Definition Manual - CD004 PDF
Front Page
© 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.
Please be aware that the Inmarsat C SDM - Version Release CD004 is subject to a Change
Proposal / Change Notice procedure administered by Inmarsat Limited.
Hilary David
Design Authority
Product Management & Marketing
Inmarsat Limited
99 City Road
London, EC1Y1AX
United Kingdom
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:
97182509.2 (China, Peoples Republic of) Turbo Coding Delay Reduction (Pending)
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
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
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.
Chapter 1: Introduction
Contents
- distress calling (i.e distress alerts and distress priority messages) 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.
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.
More detailed information about the requirements for the component parts of the system can be found
in the associated volumes:
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:
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.
SIGNALLING
CHANNEL
TELEX
NETWORK LES MESSAGE CHANNEL MES
(DCE)
DATA TDM CHANNEL
NETWORKS EGC
TERRESTRIAL NETWORKS
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
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.
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.
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.
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.)
NCS NCS
LES-NCS ISL
NCS NCS-NCS ISL
NCS-NOC ISL
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.
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.
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.
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.
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.
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.
- unique individual ID
- group ID
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.
- FleetNETSM
- SafetyNETSM1
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.
- 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.
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.
- individual poll
- group poll
- area poll
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.
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.
Contents
1 Introduction ............................................................................ 3
7 Interfaces.............................................................................. 10
7.1 Mobile Earth Station Interface ......................................................................... 10
7.2 Land Earth Station Terrestrial Interfaces ........................................................ 10
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.
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.
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:
(b) managing the resources in the system (channels) either automatically or on the basis of
operator intervention
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.
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.
IF Interface
C band
Message Packets
Channel Processing
Inmarsat-C
Test Terminal TERRESTRIAL
LINKS
Figure 2 (on the following page) shows a block diagram of a typical Inmarsat-C MES.
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
(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.
The Performance Verification Test is a fully automatic test to check individual MESs with respect to
signal level and some access and control responses.
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:
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.
(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
(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
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.
An LES may operate more than one TDM channel and each channel may be demand assigned (see
Section 4 and Section 10).
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.
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.
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.
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.
7 Interfaces
8 Inmarsat-C Services
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.
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.
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.
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.
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.
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;
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.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:
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.
In this mode a polling command is transmitted to a group of mobiles using a pre-defined group
identity.
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.
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.
(b) between the MES and the LES (via the satellite);
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.
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.
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.
TDM
REQUEST
Signalling Channel
CONFIRMATION
ANNOUNCEMENT
NCS Common Channel
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
On request, the NCS allocates channels to those LESs participating in the demand assignment
operation.
The MES logs in at a particular spot, which enables the NCS or LES to route information to 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.
Contents
1 Introduction ............................................................................ 3
Table 9: Quality Objectives - C/M = 7 Db, C/No = 32.5 dBHz (First Generation),
C/No = 35.5 dBHz (Future Generations) ................................................. 14
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.
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:
(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.
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:
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.
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.
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.
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
Cumulative Losses
The frequency uncertainties shown in Table 4 are based on 5 degrees satellite orbital inclination and
worst case MES and LES locations.
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
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
and are not to be interpreted as technical performance requirements, which are detailed in other
volumes of the Inmarsat-C definition documentation.
"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).
C/No PEP (128) PEP (40) PEP (20) PEP (10) PEP (1)
dBHz
C/No PEP (128) PEP (40) PEP (20) PEP (10) PEP (1)
dBHz
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.
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.
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.
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.
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
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:
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:
(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.
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)
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.
Contents
1 Introduction ............................................................................ 6
1.1 References to Constants...................................................................................6
Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 1
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 2
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 3
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 4
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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.
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 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.
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)
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.
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).
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
-Inm-C Signalling , EGC & polling -Inm-C Signalling & To-Mobile Messages
Page: 9
(Version Release CD004, CN141)
C SDM
FIG 4-2 Inmarsat-C Channels & Signals
TDM Channel
Test Result
NCS Common Channel
Message Channel
Message Status Request
Signalling Channel
Signalling Channel
Test Request
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.
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
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
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 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;
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)
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
Idle 639
Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 14
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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)
Scrambling Generator
Output
LSB MSB
Figure 7: Encoder
Encoder
G(1)=(1011011)
G(2)=(1111001)
G(1)
Output
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
Row
Unique Word
Unique Word
61
62
row i=63 L
63
Page: 17
(Version Release CD004, CN141)
C SDM
FIG. 4-9 Forward Link Serial TDM Transmission
j 0 1 2 62 63 0
Notes:
1. j is the order in which rows are transmitted
4. Frame start time reference is always leading edge first of first unique
Page: 18
(Version Release CD004, CN141)
C SDM
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
- the message channel is quasi-continuous and therefore a preamble is added to aid acquisition;
- 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:
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:
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.
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.
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)
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
Message Packet
No. 3
Message Packet
No. 4
Message Packet
No. 5
Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 21
FIG. 4-11 Message Channel; Serial Data Format
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
Page: 22
(Version Release CD004, CN141)
C SDM
FIG. 4-12 Signalling Channel Frame Format
10368 TDM Symbol Periods
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
Page: 23
370 TDM Symbol Periods
(Version Release CD004, CN141)
C SDM
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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)
1) Start State
1 D D2 D6
F 0 0 0 0 0 0
2) Finish State
2
1 D D D6
0 0 0 0 0 0 L
Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 25
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
(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.
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.
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
2 2 2
4 Channel Access
This section describes the method of accessing each channel and the types of information transfer
that are possible.
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;
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.
With the highest priority level given first, the priority levels are (see Vol.3, Pt 1, Chapter 3, for details):
(iv) messages.
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)
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
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.
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:
(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).
Transmit_Frame_Number := Frame_Offset;
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)
The MES will start transmitting the carrier on the indicated frequency at the appropriate slot time.
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.
• signalling between each LES and the NCS to synchronise MES databases;
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;
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)
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)
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
Services
Rnd Interval
Checksum
BULLETIN BOARD
Checksum
Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 34
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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);
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.
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.
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.
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.
Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 37
FIG 4-19 To-Mobile Message Transfer
1. <MES Status Request + Announcement> 2) Steps 7-10 are repeated until all message
packets have been correctly received.
7. <Message>
8. <Message>
9. <Acknowledgement Request>
[MES Tunes to Signalling Channel]
10. <Acknowledgement> (Reserved)
[MES Tunes to TDM channel]
11. <Clear>
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
3. <Logical Assignment>
5. <Message>
6. <Acknowledgment>
or 7. <Clear> [MES Tunes to LES TDM]
Page: 39
(Version Release CD004, CN141)
C SDM
FIG 4-20 From-Mobile Message Transfer
Sheet 2 of 2
message immediately.
3. <Request Pending>
5. <Announcement Request>
6. <Announcement>
7. <MES Status> [MES Tunes to LES TDM]
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)
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.
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)
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)
Bit No.
8 7 6 5 4 3 2 1
Assignment Request
Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 43
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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)
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.
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.
On receipt of this packet the MES must stop its activity and retune to the NCS common channel.
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.
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.
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)
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.
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.
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.
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.
(a) monitor individual MES performance, and provide for the identification of malfunctioning MESs;
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.
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.
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.
(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.
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.
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.
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.
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)
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.
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.
• not commissioned;
• 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.
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.
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.
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.
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.
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.
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.
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)
Service Code
C P Repetition
Message Sequence
Number
Packet Sequence No.
Presentation
LES ID
Address
Information
ISL
CRC
Information
Address
Information
CRC
CC
Information
Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 55
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
Service Code
C P Repetition
Message Sequence
Number
Address
Information
CRC
Information
16 Bytes
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
CRC
Message Sequence No.
Information
RS Spare
ISL 16 Bytes CC
EGC Acknowledgement
Service Code
C P Repetition
Message Sequence
Number
Packet Sequence No.
Presentation
LES ID
Address
Information
CC
CRC
Information
Volume 1: System Description, Chapter 4: Protocols for the Message Services Page: 56
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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.
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)
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)
Contents
1 Introduction ............................................................................ 2
2 Addressing ............................................................................. 2
Figure 1: Data Reporting MES Configurations ........................................................3
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)
DTE
Configuration I MES
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.
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.
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).
Volume 1: System Description, Chapter 5: Protocol for the Data Reporting Service Page: 5
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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)
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.
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:
(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:
- 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.
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.
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).
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)
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)
Contents
1 Introduction ............................................................................ 2
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.
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.
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.
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:
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.
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)
Contents
1 Introduction ............................................................................ 2
2 Protocol .................................................................................. 2
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.
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).
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.
Contents
1 Scope ..................................................................................... 3
2 Introduction ............................................................................ 3
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)
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
The mechanisms for the transmission of polling packets to the destination MES can be achieved as
follows:
- The poll packets to mobiles are sent via the NCS common channel TDM and those to
the Base Station via the LES TDM.
- 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 :
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.
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
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.
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
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:
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.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.
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.
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)
The definitions of the polling packet type 24H are given in Figure 4.
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)
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
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
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
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.
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:
00H 0 length i.e. no address field and all group member polled
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
4 LES ID 4
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)
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.
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
Command
Data Data
Sequence No.
Data
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.
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
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)
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"
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)
Contents
1 Introduction ............................................................................ 2
1 Introduction
This chapter explains the terms and abbreviations used throughout the Inmarsat-C system definition
documentation.
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
BINDING
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.
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
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
MESSAGE CHANNELS
Used for transmitting control, signalling and data reporting packets from the MES to the LES.
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.
Used for call announcements, confirmations, polling commands and as a timing reference for
all MESs.
Used for the passing of network operational and status information and EGC messages
between LESs and the NCS.
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.
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.
Users of a communication service who have the facility to communicate with one another but access
is barred to and from all others.
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).
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
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.
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).
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
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.
A closed network identification number identifying a closed user group making use of the EGC
FleetNETSM group calling capability.
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).
FLEETNETSM
An EGC service for the transmission of commercial messages and data to individuals or groups of
subscribers.
FORWARD 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.
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.
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.
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.
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.
MESSAGE CHANNEL
MESSAGE PACKET
A self-contained segment of a message consisting of packet number, data fields and a checksum.
The term mobile earth station refers to the Inmarsat-C mobile user terminal consisting of a DCE and
DTE, whether maritime or land based.
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.
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).
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
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.
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.
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
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.
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.
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
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.
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.
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 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.
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.
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.
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.
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.
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
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:
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.
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
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
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
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
Contents
1 Introduction ............................................................................ 2
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.
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.
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.
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
executes the assignment; transmitting pre-assigned data reports at the next available scheduled
slot/frame/channel, once the MES is idle.
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.
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.
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
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.
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.
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.
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
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.
- Introduction/Description of service
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.
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.
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
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:
d) Polling protocol
f) Alerting 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.
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.
h) Polling 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.
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.
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
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.
d) ISDN
e) Private Networks
f) Leased Lines
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.
b) PSDN Terminal
d) Minitel Terminal
e) Inmarsat-A/B/C/M/Aero Terminal
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
d) Position reporting
e) Data logging and remote monitoring and control (SCADA) applications, e.g. weather
monitoring, water supply management etc.
g) Document/file transmission
i) E-Mail
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.
Contents
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.
Packet definitions are included in Volume 4. The following references in Volume 4 are particularly
relevant:
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).
The following CCITT Recommendations are also relevant to LES - telex network interfacing:
F.72 International telex store and forward - general principles and operational aspects
F.127 Operational procedures for interworking between the telex service and the service offered by
nmarsat-C system
S.18 Conversion between International Telegraph Alphabet No. 2 and 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.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
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.
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).
- LES ID
- Date
- Time (UTC)
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.
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):
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.
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.
Contents
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).
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
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.
Volume 1, Chapter 4
Volume 4, Chapter 6
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.
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
The specific requirements for EGC receivers and MESs providing EGC functionality are in Volume 3,
Part 2, Chapter 8.
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.
Where:
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.
The meanings of the C codes are explained in Volume 3, Part 1, Chapter 2, Section 9.
Chapter 4: SafetyNETSM
Contents
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 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.
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.
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.
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.
[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.]
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.
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.
• 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;
• 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.
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
0°
141°
20°
127°
55°
95°
30° 29°
30° 30°
XIV 35° 50'
120°
VII X 45°
VI
80°
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)
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.
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.
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.
Chapter 5: FleetNETSM
Contents
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.
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.
/1/N/05454/
*************************
[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.
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:
b) this registered user has the right to have the given ENID downloaded or deleted.
In any event, access to the service must be restricted to registered and authorised users.
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.
Contents
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.
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.
Also see the SDL figures in Volume 5 for the handling of Distress Alerts and Distress Priority
messaging traffic.
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.2.1 Addressing
Addressing of distress messages is currently undefined.
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:
Maritime DTE software approved for GMDSS use shall inhibit the input of a destination address when
distress From-Mobile messages are being set up.
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.
Contents
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.
Packet definitions are included in Volumes 4. The following references in Volume 4 are particularly
relevant:
Volume 4, Chapters 4 and 5 provide most detail on the MES addressing requirements.
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).
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.
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.
T.30 Procedures for document facsimile transmission in the general switched telephone
network
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.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
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:
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.
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.
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). 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:
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.
Contents
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.
Packet definitions are included in Volumes 4. The following references in Volume 4 are particularly
relevant:
Volume 4, Chapters 4 and 5 provide most detail on the MES addressing requirements.
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.
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
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.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
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.
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.
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.
Contents
1 Introduction ............................................................................ 2
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.
S.18 Conversion between international telegraph alphabet No. 2 and 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
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.
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.
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.
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.
It is likely that further presentation codes for X.400 interworking will be defined.
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:
WEST CENTRAL:
HI__ WINDS EXPW_TED, GUS_hNG GALE FORCE 9 NORTH NORTH-WEST. HEAVY RAIN.
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
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.
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
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.
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.
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.
From-Mobile: The Destination Network (in the assignment request packet) specifies telex.
EGC FleetNETSM: The call originates from an authorised (FleetNETSM) telex subscriber.
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.
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:
_________________________________________________________________________________
[message text......]
_________________________________________________________________________________
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:
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.
EGC FleetNETSM: The call originates from an authorised (FleetNETSM) subscriber using a data
network that supports 8-bit data.
Contents
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.
Polling: Chapter 6
Polling: Chapter 9
An algorithm for determining if an MES at a known location lies within a circularly addressed area is
described in Chapter 4, Appendix 2.
a) Downloading a DNID
*************************
[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:
MES models need not support all command types. As a minimum command type 0AH and 0BH
(download and delete DNID) must be supported.
LES operators should ensure that their stations are equipped with sufficient return signalling channel
capacity to meet anticipated demand for data reporting.
Contents
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.
Volume 4, Chapter 4
Also see the SDL figures in Volume 5, Chapters 2 and 3 for the handling of Maritime Distress Alerts.
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.
Contents
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.
The following CCITT Recommendations are also relevant to Basic X.400 interworking:
X.411 Message handling systems: message transfer system: abstract service definition and
procedures
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.
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
1 Introduction
This Application Note explains how Chinese characters may be transmitted and received in IA5 code
and Graphic Character Internal (GCI) code.
3352 1316 0668 3938 0060 3189 0057 5898 2502 c- 2871 0402 4541
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
}
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.
KEYBOARD
ADMINISTRATION
MODULE
GCI
GCI
CCM GCI
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
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.
Contents
1 Introduction ............................................................................ 5
2.4.1.2 C (1 bit)................................................................................................................................... 6
2.5.2.2.1.2 N (2 bits)......................................................................................................................... 13
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.
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.
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.
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)
2.4.1.1 P (1 bit)
2.4.1.2 C (1 bit)
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.
The Extended Category is used when sub-categories are required (see 2.4.1.7.1).
This field is included only if the Extended Category is selected (see 2.4.1.7).
The reserved sub-categories will be used to define additional standardised reports. Examples of sub-
categories that might be included are:
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.
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.
Byte
Byte
Only the fields specific to Position Reports are described in the following paragraphs.
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.
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).
10 bytes are available in the first continuation packet and 12 bytes in the second continuation packet
for user definition.
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.
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.
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".
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 ".
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.
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.
- to program MESs with the parameters used for the Reserved Data Reporting Protocol
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.
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.
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
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
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.
Uses the Polling protocol (see Volume 1, Chapter 6 and Volume 4, Chapter 9).
Used to initiate Data Reporting using the Pre-Assigned Data Reporting protocol (see Volume 1,
Chapter 7). The supplementary parameters field is used:
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)
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.
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.
Available for use to send any byte oriented binary data or text.
Uses the Pre-Assigned Data Reporting protocol (see Volume 1, Chapter 7).
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.
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.
Packet Byte
First packet 6- 13
Continuation packets 2 - 13
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.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.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:
0H Data Report
2H-FH Reserved
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
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;
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.
(If no valid message is available, the MEM code should be set to zero.)
Notes:
1) Coded as a two byte unsigned binary number. The first byte is the most significant.
[Date, time]::=[month][day][hour][minute]
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
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
SP Speed 2 0 Stopped
1 Slow < 20 kph
2 Medium 20 to 70
3 Fast >70
Contents
Glossary ...................................................................................... 5
1 Scope ..................................................................................... 6
2 Introduction ............................................................................ 7
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)
9 Summary ............................................................................... 31
1.2 Polls............................................................................................................................................ 33
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
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
ID Identity
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 role of the MES, describing the breakdown of functions between DCE and DTE;
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.
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.
- Telex and data (text) store and forward communication in both directions
- 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
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.
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.
Figure 1: Inmarsat-C channels Used for the Data Reporting and Polling Protocol
POLLING COMMANDS
USE NCS COMMON
CHANNEL (TDM) MES
NCS
DATA REPORTS
USE LES SIGNALLING
CHANNEL MES
(UNRESERVED ACCESS)
LES
DATA REPORTS
USE LES SIGNALLING
CHANNEL MES
(RESERVED ACCESS)
LES
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.
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.
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.
3.3.2 Polling
Three types of polling are supported:
(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.
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.
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.
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.
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.
Figure 2: Grouping of DNID-LES Pairs (Note that DNIDs are Reused by LESs)
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.
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.
Application Application
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.
DTE
Configuration I MES
DCE
Interface to Satellite
DNID LES ID Member No.
Configuration II MES
- to manage DNIDs,
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.
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.
- To program MESs with the parameters used for the reserved data reporting protocol.
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.
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.
The treatment of some fields depends on whether the addressed port is a configuration I or
configuration II DCE (see section 5).
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.
D Not defined/used.
Note 2. Only polls for valid DNID/LES pairs may be accepted. Area validity
checking may be performed either by DCE or DTE.
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)
D Not defined/used.
For data reporting and polling, the principal functions of the DCE are to:
- manage DNIDs (by associating DNIDs with LESs and member numbers);
- transmit data reports (for pre-assigned data reporting the data report has to be sent in correct
frame).
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.
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.
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.
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.
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.
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.
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;
3) On receiving an individual poll conveying a data transfer with a DNID not previously
downloaded;
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).
- 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.
(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.
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.
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.
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
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
- wait on the NCS Common Channel until the occurrence of the next programmed transmission,
- tune to the LES for transmission of the data report (LES frame numbers may be ignored),
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.
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.
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.
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.
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.
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.
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.
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.
- 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
- Start Frame
- Slot Number
- Duration
- Signalling Channel
- LES TDM
- Interval
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.
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.
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.
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.
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.
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.
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.
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.
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 1:
- Volume 2, Part 1:
- Volume 4:
Chapter 10, ‘Packet Formats for the Pre-Assigned Data Reporting Service’
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.
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:
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
(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).
The command field is an important part of the poll. The basic Inmarsat defined commands are shown
in the following table.
0C-3FH Reserved
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.
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)
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).
- MEM (08H);
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.
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;
- Start Frame
- Slot Number
- 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.
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.
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.
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.
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.
The implementation of single or multiple threading depends upon several factors, for example:
(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).
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;
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.
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).
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 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 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).
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.
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:
3) Randomise;
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.
In demand assigned mode, there is no difference to the reception of polls as the MES is permanently
tuned to the NCS TDM.
- EGC reception;
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.
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.
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.
Figure A-2: Flowchart for MES Action on Receipt of a DOWNLOAD DNID Poll
Poll: Download
DNID
PQ730
Is
N
individual
poll?
PQ650
Y
Read DNID-LES
pair in poll
N Y
DNID N
Are any DNIDs
memory
disabled
full ?
?
N Y
Figure A-3: Flowchart for MES Action on Receipt of a PROGRAM DNID Poll
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
Y Individual
poll
? PQ661
N
PQ634
PQ660
LES TDM N
valid
? (Is LES TDM in range
Y allowed for TDMs?)
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)
Figure A-4(i): Flowchart for MES Action on Receipt of an INITIATE DNID Poll
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
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
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)
Figure A-4(ii): Flowchart for MES Action on Receipt of an INITIATE DNID Poll
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
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 = 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?
Figure A-5: Flowchart for MES Action on Receipt of a STOP DNID Poll
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
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 = 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?
Figure A-6: Flowchart for MES Action on Receipt of a DELETE DNID Poll
Is Y
area
poll?
PQ666
N
Read DNID-LES
pair in poll
Y Individual
poll
?
N PQ661
Group/area poll
PQ634
PQ660 N
LES TDM
valid
(Is LES TDM in range
?
Y allowed for TDMs?)
Delete DNID-LES
pair from memory
(at sub-address)
and all associated
parameters
Figure A-7: Flowchart for MES Action on Receipt of a SEND UNRESERVED Poll
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
Y Individual
poll
?
PQ661
N Group/area poll
LES TDM N
valid
PQ634
? (Is LES TDM in range
PQ660
Y allowed for TDMs?)
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
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
Contents
1 Scope ..................................................................................... 4
2 Introduction ............................................................................ 4
2.1 Aims of Mobile-Mobile Reporting ......................................................................4
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
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
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.
a) Primary Requirements:
(iv) Support for existing polling application software in customers’ base stations (terrestrial
link to be replaced by an Inmarsat-C link)
(ii) Support for validation of data transmitted by the LES at the source mobile
3 General Description
Inmarsat-C Inmarsat-C
Network Network
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
Server
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.
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
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.
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)
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.
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
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.
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.
Figure 5: Data Report Format for Base-Mobile Transactions Using Group Polls
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
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.
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
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.
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.
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.
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.
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.
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.
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.
Mobile-mobile Database
Protocol Engine Engine
Application Server
Printer Console
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.
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:
b) specification of DNID/member number (and Inmarsat-C Mobile Number for individual polls)
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.
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.
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 ID
Customer Name
Customer Address
Group Entity ID
Interpret data within polls? (Y/N) (receive DNID in range 40960 to 49151)
Mobile Entity ID
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.
Mobile-Mobile Specific
Polling Packets
Standard
Data Reports
ISL
Base station
Server
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.
Figure 9: Base Station Architecture for Operation with Large Groups of Mobiles
Data Reports Polling Packets
to LES from NCS
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.
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.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.
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.
Figure 10: Example Data Report Format for Generic Mobile-Mobile Reporting
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
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.
8 References
[1] CCITT Blue Book: Volume VIII.6. Data Communication Networks; Inter-Working Between
Networks: Recommendation X.300.
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 ?
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
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;
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 ++;
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?
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
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
?
Update
Records
Result Remote LES
Update
Records
Contents
Preface ........................................................................................ 8
Abbreviations .............................................................................. 8
1 Introduction .......................................................................... 11
4.4.1.11 CMC_X_IMS_GEN_REQUEST_DELIVERY_REPORT.................................................... 68
4.4.2.2 CMC_X_IMS_MES_AVAILABLE_MES_MEMORY............................................................. 73
4.4.2.10 CMC_X_IMS_MES_ENID_MGMT..................................................................................... 78
4.4.2.11 CMC_X_IMS_MES_GEOGRAPHICAL_COORDINATES................................................. 79
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.
[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
IM Interpersonal Messaging
MS Message Store
MT Message Transfer
O/R Originator/Recipient
UA User Agent
UI User Interface
XOM API X/Open OSI - Abstract Data Manipulation Application Program Interface
Glossary Of Terms
Application
A set of functions and/or procedures used by an application to access particular services provided by
another program(s) or operating system.
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.
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.
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.
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.
The term Mobile Earth Station refers to the Inmarsat-C mobile user terminal consisting of a DCE and
DTE, whether maritime or land based.
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
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.
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
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.
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.
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.
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
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.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.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,
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).
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 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.
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.
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
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).
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.
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:
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:
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 (“=”).
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
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.
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 0701-0704 and 0717-0718 are errors applicable to MES implementations of CMC.
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).
The following Basic X.400 error code strings may have additional diagnostic reasons appended:
LES Access and Request Error Codes (To-Mobile messaging, EGC and Polling)
MES Access and Request Error Codes (From-Mobile messaging, land mobile alerting and data
reporting)
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 (“=”).
TITLE:Receipt Report
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
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 (“=”).
If the EGC could not be cancelled, the text note should have the following:
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:
[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.
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
− 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.
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 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.
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 -
MTR -
NOHEADERS= -
0 is Atlantic West
1 is Atlantic East
2 is Pacific
3 is Indian
all other numbers are (currently) undefined
REPLY -
RR -
[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).
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
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..
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.
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.
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.
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.
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 -
MTR -
NOHEADERS= -
REPLY -
RR -
[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
(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.
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.
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.
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.
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.
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 -
MTR -
NOHEADERS -
PROTOCOL= DATAREPORT
| MESSAGE
| NORESPONSE
(If the PROTOCOL keyword is not present, DATAREPORT is
assumed).
REPLY -
RR -
[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)
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 -
DUPLICATE -
INTERVAL= [Interval]
MTR -
NOHEADERS -
PROTOCOL= DATAREPORT
| MESSAGE
| NORESPONSE
(If the PROTOCOL keyword is not present, DATAREPORT 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.
[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.
[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).
The following notes are applicable to message addresses for sending polls using the CMC API:
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.
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.
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.
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”.
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.
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.
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:
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.
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.
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.
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.
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.
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).
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.
The following notes are applicable to DNID address, From-Mobile, sent using the CMC API:
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.
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.
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.
This addresses the DNID 13212 at LES 102. The data report (or message) will be randomized over
the next 100 frames (approximately 15 minutes).
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:
3 The address must specify the LES identity, using the LES keyword.
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.
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:
This address indicates that the originator was the MES with member number 1 in DNID 19876, LES
102.
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:
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
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.
Keyword(=) Value
ECHO -
MTR -
NOHEADERS -
[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.
[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.
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:
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:
GENERALCALL
4 The DOWNLOADGROUPID service keyword must have both an MES Number and a Group
Address. The ENID should follow the MES number, e.g.
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.
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.
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.
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
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 -
MTR -
SPEED= [Speed]
ddmm.mm
For example,
- 0520.50 is 5º20’30”
- 4600.75 is 46º0’45”
dddmm.mm
For example,
- 00520.50 is 5º20’30”
- 13200.75 is 132º0’45”
[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)
If the Land Mobile Alert transmission is not successful, a non-delivery report should be generated.
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.
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.
will generate a Message Transfer Report after the message has been received by the default LES.
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
- CMC
- MES
- LES
- LES Gateway
The message originator should reflect the origin or the delivery or non-delivery report.
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
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:
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.
- 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).
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
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
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.
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.
Data Report
A CMC API implementation can, if desired, include additional information in the subject after the
above.
All other command types should be shown on the command line as:
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: Command 96
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.
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.
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.
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
4.2.1 CMC_X_IMS_channel_number
NAME
C-DECLARATION
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;
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.
4.2.3 CMC_X_IMS_keyword_value_pair_list
NAME
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
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
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 Stopped 0 km/h
1 Slow < 20 km/h
2 Medium 20 to 70 km/h
3 Fast > 70 km/h
4.2.5 CMC_X_IMS_mes_number
NAME
C-DECLARATION
DESCRIPTION
4.2.6 CMC_X_IMS_message_transfer_report
NAME
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.
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.
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.
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.
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.
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.
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
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.
4.2.11 CMC_X_IMS_station_id
NAME
C DECLARATION
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
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.1 X_Set_Configuration
NAME
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
Opaque session handle which represents a session with the messaging service.
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.
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
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.
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
CMC_E_UNSUPPORED_FUNCTION_EXT
CMC_E_USER_NOT_LOGGED_ON
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.
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
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.
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.
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.
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
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.
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.
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.
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).
item_reference
Not used.
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.
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:
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.
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
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
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.
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.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
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
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:
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
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
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
Output
extension_flags
No further flags are defined
item_data
CMC_X_IMS_channel_number
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:
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
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.
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
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.
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:
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
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.
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
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()
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.
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.
item_reference
NULL
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.
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
item_reference
NULL
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
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.
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().
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.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.
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.
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.
• conform to the X.400 API Association CMC API specification version 1.0
• 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.
• support all of the address structures and message types defined in this specification.
4.6.1 General
Every terrestrial implementation shall
• conform to the X.400 API Association CMC API specification version 1.0
• implement all the additional data types and error codes that are defined in this specification
• support all of the address structures and message types defined in this specification.
INMC:499999999
INMC:499999999;REGION=0
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.
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:
/* 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;
/* MES number */
typedef CMC_uint32 CMC_X_IMS_mes_number;
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;
/* ** 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
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.
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
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:
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;
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;
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.
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.
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.
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:
2 Add DR and REPLY parameters if present in recipient extensions and not already present in
addresses.
4 Concatenate all “To” addresses together separating each address with a comma (“,”) and put
the resulting string after TO: as a header line.
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):
ACKNOWLEDGEMENT
AUTOMATIC
DR
DUPLICATE
ECHO
MTR
NOHEADERS
RR
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..
[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.
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:.
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:
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.
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:
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.
LOW
NORMAL
HIGH
DEFAULT
PERSONAL
PRIVATE
CONFIDENTIAL
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.
TELEX: 5551234; DR
Note non-delivery reports are automatic in the Inmarsat-C system and do not need to be requested.
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.
6 Examples
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.
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.
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.
CMC_return_code Status;
CMC_session_id Session;
CMC_extension Extensions[2];
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 */
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.
CMC_return_code Status;
CMC_session_id Session;
CMC_extension Extensions[2];
CMC_boolean UI_available;
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 */
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.
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.
/* ... */
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;
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.
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:
2 The message subject, and the filename to carry on the attachment cannot be carried so are not
included in the call.
#define NO_FLAGS 0
#define NO_UI_ID 0
#define NO_EXTENSION ((CMC_extension *) NULL)
#define NO_MESSAGE_REFERENCE ((CMC_message_reference *) NULL)
/* 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 */
}
#define NO_FLAGS 0
#define NO_UI_ID 0
#define NO_EXTENSION ((CMC_extension *) NULL)
#define MAX_LATITUDE 90
/* 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;
/* Send Message */
return cmc_send (session, & request, NO_FLAGS, NO_UI_ID, NO_EXTENSION);
#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 */
/* 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 */
}
ext.item_code = CMC_X_IMS_GEN_LAND_MOBILE_ALERT_DATA;
ext.item_data = 0; /* not used */
ext.item_reference = (CMC_buffer) & LMAdata;
ext.extension_flags = CMC_EXT_LAST_ELEMENT;
/* Send Message */
return cmc_send (session, & LMAmessage, NO_FLAGS, NO_UI_ID, NULL);
}
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.
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.
Key:
N Not supported
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.
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.
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
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.
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:
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.
Key:
N Not supported
M Mandatory
E Extensions
Key:
N Not supported
M Mandatory
E Extensions
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.
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
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:
These elements apply to MESs, but not to systems connected to LESs by terrestrial networks.
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.
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.
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.
Key:
N Not supported
M Mandatory
E Extensions
These elements apply systems connected to LESs by terrestrial networks, but not to MESs.
1 Descriptions
Inmarsat-C Access Control
This element of service enables the mobile UA to manage the set of known NCS TDM Channels.
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
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).
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.
This element of service enables the mobile UA to abort the current operation.
This element of service allows messages waiting to be sent to be deleted from the DCE.
This element of service enables the delivery status of a message (previously sent) to be requested.
This element of service enables the mobile UA to manage the peripherals attached to the MES DCE.
This element of service enables the mobile UA to manage MES specific items.
This element of service enables the mobile UA to have visibility of the signal strength observed by the
MES.
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.
This element of service enables the mobile UA to have visibility of the status of a message transfer in
progress. Enumeration of states TBD.
This element of service allows the mobile UA to have visibility of the current network information held
in the MES.
This element of service enables the mobile UA to have visibility of the results of the last PVT.
This element of service allows the mobile UA to have visibility of the current MES activities.
Enumeration of activities TBD.
This element of service enables the mobile UA to have visibility of the approximate amount of free
DCE memory for messaging.
This element of service enables the mobile UA to have visibility of particular protocol related
messages and alarms.
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.
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).
This element of service enables the mobile UA to determine the current frame number.
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.
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.
This element of service enables the mobile UA to manage the current set of downloaded DNIDs.
This element of service enables the mobile UA to send a data report to a previously downloaded
DNID.
This element of service enables a land-based UA to receive a data report that has been sent to a
DNID.
This element of service enables the mobile UA to identify poll contents (e.g. DNID, sub-address, free
field)
This element of service enables a land-based UA to send a poll (of any kind).
This element of service enables the mobile UA to respond to Program Polls by sending Data Reports
or messages.
This element of service enables the mobile UA to manage polling and data reporting sub-addresses.
This element of service enables the mobile UA to determine data reporting programs previously
downloaded (in Polls).
Inmarsat-C EGC
This element of service enables the mobile UA to manage primary and secondary NAVAREA codes
for receipt of certain EGC messages.
This element of service enables the mobile UA to set the NAVTEX code for receipt of certain EGC
messages.
This element of service enables the mobile UA to manage previously downloaded ENIDs.
This element of service enables the mobile UA to receive EGCs and all the header contents (service
code, priority, etc.).
This element of service enables a land-based UA to send EGCs and all the header contents (service
code, priority, etc.).
This element of service enables the mobile UA to send a Maritime Distress alert.
This element of service enables the mobile UA to send a Land Mobile alert.
The Inmarsat system consists of the following major elements in an ocean region:
SIGNALLING
CHANNEL
TELEX
NETWORK LES MESSAGE CHANNEL MES
(DCE)
DATA TDM CHANNEL
NETWORKS EGC
TERRESTRIAL NETWORKS
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.
Satellite utilisation is co-ordinated by the Inmarsat Network Operation Centre (NOC) in London.
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.
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.
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:-
- 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.
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
For store and forward messaging, the mandatory end to end service supported by all elements of the
network is Telex.
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.
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.
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.
- unique individual ID
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.
- FleetNETSM
- SafetyNETSM
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.
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.
- 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 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.
- 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.
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
Contents
1 Introduction ............................................................................ 2
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:
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 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,
(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.
IF Interface
C band
Message Packets
Channel Processing
ACCESS CONTROL AND SIGNALLING SUB-SYSTEM
Control
Timing
L band LES TDM Generator
Demodulator
- Reference Tuning
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)
This channel shall be used by the LES to transmit the following information to the NCS:
The LES shall continuously receive the NCS-to-LES interstation signalling link carrier which carries:
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.
(a) the establishment and clearing of logical channels under normal and abnormal conditions;
(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.
(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;
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)
"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."
"........ 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: 6
Chapter 1: Introduction and Overview
Inmarsat Confidential C SDM
(Version Release CD004, CN142)
Contents
1 Introduction ............................................................................ 6
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)
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)
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)
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
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
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)
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
- Maritime distress call handling (i.e. distress alerts and distress priority messages)
- Polling
- Data reporting
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
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)
(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:
(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:
Notes:
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)
6
(c) symbol rate stability: long term stability ±0.8 part in 10 ;
(e) frame unique word: two unique words are transmitted uncoded 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;
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;
(d) Maximum frequency offset (prior ±30 kHz for first generation
to LES AFC correction): ±4 kHz for second generation;
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)
-25
-30
-35
-40
Power in 1 Hz ( dBc )
-45
-50
-55
-60
-65
-70
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:
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)
(b) symbol rate: 1200 symbols per second (for second generation satellites);
600 symbols per second (for first generation satellites);
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;
(b) symbol rate: 1200 symbols per second (for second generation satellites);
600 symbols per second (for first generation satellites);
(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);
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
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.
(ii) slot timing reference generation which needs timing information from the LESs own
received TDM;
(v) de-scrambling;
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.
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)
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.
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.
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.
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.1 Performance
(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).
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%.
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.
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)
A control interface with the access control sub-system to message channel processing will be
required to provide the following message information:
where:
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)
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.
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.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%.
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)
(a) the transmission of signalling and message packets on the TDM channel(s);
Each LES shall have the capability to operate in the demand assigned mode according to the
protocols described in Volume 1.
(c) Assignment of To-Mobile logical channels for distress priority messages; and
The LES shall encode packets using the shortest packet type which will contain the information.
(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:
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)
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.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.
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.
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:
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:
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.
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.
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.
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.
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].
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.
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:
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:
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.
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.
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)
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
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)
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)
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.
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.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.
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.
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.
(i) public switched telephone network (PSTN) for voice band data;
(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)
(vii) perform number translation between the Inmarsat Mobile Number and the MESs return 24 bit
code that is allocated by Inmarsat;
(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.
(b) provide the message originator with the following message reference information:
(e) perform number translation between the Inmarsat Mobile Number used by terrestrial
subscribers and the forward 24 bit MES code;
(h) assemble message packets for transmission over the satellite channel;
(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)
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.
(i) LES or message handling system identifier — for example, "Eik LES" for To-Mobile calls;
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.
(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.
(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.
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:
BK Message aborted
NA Access Barred
NC Network Congestion
NP Not Obtainable
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)
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.
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.
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)
b) this registered user has the right to have the given ENID downloaded or deleted.
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:
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.
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)
6 Testing
In the future, it may be desirable to introduce additional assistance codes. No specifications are
included here, but future introduction should not be precluded.
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:
The measurement accuracy of the Received signal strength shall be [±1 dB] referred to the L-to-C
AFC pilot.
7 Distress
"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."
"........ 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)
(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.
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.
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)
Where
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:
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.
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
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
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)
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.
C3 Code — Empty
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.
C3 Code — 12 digits
Description — rectangular addresses will consist of 12 digits as received at the LES. These are as
follows:
If the longitude is less than 100° then set D3 (and D4) to zero as necessary. For example: 085 for
85o.
A rectangle whose Southwest corner is 12° S and 124° E. The extent of the rectangle is 10° north and
10° east.
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
0B-FF Spare
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.
B1 is a character identifying the Coastal information coverage area (see Volume 2, Chapter 4).
A: Navigational warnings
B: Meteorological warnings
C: Ice reports
E: Meteorological forecasts
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)
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.
C3 Code - 10 digits
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°
C3 Code — 9 digits
Name of Service — Urgency message, Meteorological and Navigational Warnings to Circular areas:
C3 Code — 10 digits
C3 Code — 2 digits
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)
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:
Where:
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
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.
C3 Code — 12 digits
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
C3 Code — 5 digits
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.
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.
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)
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
Delay
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"
A cancellation facility for messages transmitted to an LES with Category (b) repetition codes shall be
provided at the LES to terminate the repetition.
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:
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
- ++++
Notes:
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.
01 Reserved
02 Reserved
03 Reserved
04 Reserved
05 Reserved
06 ITA 2
07 Data
10.1 General
This section describes a method by which terrestrial users can gain access to the Polling services via
a Land Earth Station.
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)
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.
(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.
(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.
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)
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)
Contents
1 Introduction ............................................................................ 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)
The number includes 3 digits which identify the country in which the MES is registered.
4 M1 I2 D3 X4 X5 X6 X7 X8
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.
2 bits 6 bits
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)
The unique LES IDs will take the following decimal form:
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)
Contents
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)
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)
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)
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)
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.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.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)
Gateway
SendMessage
Result
ReceivedMessage
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. 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
Figure 3 gives a graphical representation of the overlap of protocol elements providing the three
services.
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.
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.
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.
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)
EOS EOS'
Service Inmarsat-C
MT Service mapping MT Service
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'.
1: Note that a delivery report is requested on a per-recipient basis and not on a per-message
basis.
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.
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.
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)
EOS EOS'
Service Inmarsat-C
IPM Service mapping IPM Service
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.
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)
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.
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)
Inmarsat-C Agent
AU UA
Access User
Network
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
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.
The submission and delivery ports enables the interaction of the inmc-mes and the inmc-gtw via the
satellite link.
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
(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
a. MessageSubmission
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)
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 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)
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:
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.
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.
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
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.
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)
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
'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').
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'.
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)
BEGIN
IMPORTS
-- upper bounds
FROM INMC-MTS-UB;
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)
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)
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
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)
-- Extension fields
ExtensionField :: = SEQUENCE {
type [0] ExtensionType,
criticality [1] Criticality DEFAULT { },
value [2] ANY DEFINED BY type DEFAULT NULL }
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)
-- O/R names
-- Standard Attributes
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)
-- Domain-defined Attributes
-- Extension attributes
INMC-MTS-EXTENSIONS -- { iso:org:dod:internet:private:enterprise:inmarsat:inmc-mts-extensions }
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
-- ConversionWithLossProhibited extension
-- DEFAULT conversion-with-loss-allowed
-- CRITICAL FOR DELIVERY
-- Extension attributes
INMC-MTS-UB -- { iso:org:dod:internet:private:enterprise:inmarsat:inmc-mts-ub }
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)
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)
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.
<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.
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.
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.
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.
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.
2. Direct mapping of information elements with possible loss of information due to different
character-sets used in the originating and receiving mail system.
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.
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.
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 -
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.
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.
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.
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
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.
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.
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 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,
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
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)
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.
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)
Packets convey
first part of
Deliver-IAPDU MES STATUS
ISL
ANNOUNCEMENT
NCS Common Channel
ASSIGNMENT RESPONSE
MES Signalling Channel
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
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)
"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.
[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 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.}
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)
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:
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.
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.
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.
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.
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.
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.
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.
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.
- Ambiguous OR name
- Mts congestion
- Loop detected
- Recipient unavailable
- Conversion impratical
- Invalid arguments
- Protocol violation
- No bilateral agreement
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)
- Page split
- DL expansion prohibited
- No DL submit permission
- Dl expansion failure
- 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)
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)
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)
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)
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)
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)
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)
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)
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)
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.
MT Information
objects
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)
MT Information
objects
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 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:
An IPM comprises a heading, containing information about the IPM, and a sequence of body parts,
containing the actual information conveyed between users.
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)
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)
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.
INMC-IOB -- { iso:org:dod:internet:private:enterprise:inmarsat:inmc-iob }
BEGIN
IMPORTS
-- upper boundsI
FROM INMC-IOB-UB
Time ::= UTCTime
-- Information object
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)
-- Heading
-- Note: The heading set is a subset of the CCITT X420 set. Any heading field not listed is not handled
by the InmCA.
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)
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
}
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
INMC-IOB-EXTENSIONS -- { iso:org:dod:internet:private:enterprise:inmarsat:inmc-iob-extensions }
BEGIN
IMPORTS -- nothing
-- Extensions
-- Incomplete Copy
END -- of Extensions
INMC-IOB-UB -- { iso:org:dod:internet:private:enterprise:inmarsat:inmc-iob-ub }
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
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
InmCA(Inmarsat-C
Agent)
Submission
InmC-U InmC- InmC- MTS
ser MES Delivery Gtw
Origination Import
Reception Export
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)
inmc-user OBJECT
PORTS {
origination [C],
reception [C] }
::= id-ot-inmc-user
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
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
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).
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
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).
The ReceiveReport abstract operation receives a report at the Inmarsat-C user from the IPMS
(InmCA).
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)
• 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.
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)
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
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)
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.
Delivery 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)
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
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)
Transfer of
delivery
notification
mts-id , ipm-id
Delivery of
delivery
notification
mts-id, ipm-id
Receipt of
delivery
notification
mts-id, ipm-id
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.
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.
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
"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:
[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)
[IPM element keyword] ::= {IPM keywords are listed in the element keyword column of
tables 22 through 24}
[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.}
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:
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.
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].
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.
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
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)
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)
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)
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)
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)
Contents
0 General ................................................................................... 5
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)
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)
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)
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.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:
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)
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)
REQUEST
MSAP
MAILBOX
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.
• 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.
• 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;
• Provides X.400 services only to those MES subscribers who are registered with a mailbox
system associated with one or more LESs.
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)
DELIVERY
MTA
IWU
TEMPORARY
QUEUE
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.
• 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.
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.
• Convenient support for multiple users or multiple applications on a single MES; and,
• 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.
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:
• 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.
• 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.
- MSAP which interfaces the existing store and forward equipment using a
dedicated protocol, as shown in Figure 4.
- 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.
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.
LES
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.
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.
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)
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).
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
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.
• 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.
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.
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)
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:
• Originator addresses;
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.
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):
• 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.
• 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.
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.
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.
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;
• 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:
• 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)
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.
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.
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)
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)
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
MESSAGES IN P1
PROTOCOL
COMPRESSED &
ENCAPSULATEDTO
USEINMARSAT-C
MESSAGING SERVICE
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)
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.
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.
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.
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.
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.
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.
• 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
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)
• 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:
• 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.
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 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.
• 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.
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.
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.
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)
This PDU must be specified solely within an Inmarsat-C message; i.e. no other PDUs are expected.
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.
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.
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.
protocol-version may be used to indicate the version of the protocol that has been implemented at
the station.
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.
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)
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.
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.
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.
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)
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.
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.
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.
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
Content corresponds to the Content abstract syntax definition of the MTS abstract service defined in
CCITT X.411.
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
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.
message-states indicates the summary operation should consider one of the following condition:
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,
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.
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.
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.
protocol-version may be used to indicate the version of the protocol that has been implemented at
the station.
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)
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.
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.
result-code is an indication whether the specified message store entry specified by ms-reference-
number has or has not been deleted.
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)
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.
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.
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.
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)
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.
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).
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)
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.
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.
4.4.6 MbxProblemReport
The MbxProblemReport PDUs is described in section 4.3.7.
IMPORTS
-- 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)
END
IMPORTS
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)
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)
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)
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)
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.
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.
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.
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.
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.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:
• The maximum size of a collection of PDUs to be transmitted in one Inmarsat-C message shall
not exceed 65536 bytes.
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.
bit 7 bit 0
3
Compressed Size
Compressed Size
Second PDU
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.
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.
2. ARITHMETIC
ENCODING
3. CONCATENATION
4. ENCAPSULATION
INMARSAT-C MESSAGE
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.
Direction: 0 - To-Mobile
Priority: 0 - Routine
Extension Length: 1
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)
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 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)
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).
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.
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)
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.
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)
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)
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)
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.
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.
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)
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.
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.
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
Volume 3: Earth Station Requirements, Part 2: Mobile Earth Station Requirements, Page: 1
Chapter 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)
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.
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.
- 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)
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)
Contents
1 Introduction ............................................................................ 5
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
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.
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
Handle
Confirmation Save Save Save Save
packet
Handle
Message Status Save Save Save Save
packet
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.
The mandatory capabilities for each class of MES are described below.
CLASS 1:
(a) transmitting Store and Forward messages to full telex addresses (CCITT Rec. U.80);
(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).
CLASS 2:
(a) continuous reception of EGC messages transmitted on the NCS common channel when in the
EGC mode.
CLASS 3:
(a) continuous reception of EGC messages transmitted on the NCS common channel.
3 RF Subsystem Requirements
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.
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).
(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.
(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)
Note:
3. Minimum G/T profile is circularly symmetrical about the 90° (zenith) axis.
Refer to Volume 1, Chapter 2, Table 1 for details of transponder power levels and bandwidths of first
and future generation INMARSAT satellites.
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.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:
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.
Note:
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.
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:
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
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)
Decimal Hexadecimal
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).
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:
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
(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;
(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.
(e) symbol rate stability: long term stability ±0.8 parts in 106;
(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:
expressed in hexadecimal:
expressed in hexadecimal;
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
(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);
(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);
(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;
unfaded
signal
at fo
(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.
The limits for the maximum acceptable PEP for a range of equivalent unfaded power flux densities
(PFD) at the antenna are as follows:
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.
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.
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.
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;
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.
5 Transmitter Performance
(c) coded symbol rate: 1200 symbols per second ±1 part in 105 (for future
generation satellites)
transmitted first
0000 0111 1110 1010
1100 1101 1101 1010
0100 1110 0010 1111
0010 1000 1100 0010
transmitted last
or expressed in hexadecimal:
(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:
expressed in hexadecimal:
or expressed in hexadecimal:
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.
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:
where G=2 or 1 for first generation or future generation satellites respectively. Symbol periods as
defined above.
(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.
MESs shall be inhibited from using the following signalling channels for general signalling (refer to
Volume 4, Chapter 2, Section 3.2):
iii) Closed user group channels (unless access has previously been authorized).
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.
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.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;
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.
It shall not be necessary for the operator to enter frequency information when setting up a call.
The term 'Stand Alone' is used because an LES will be stand alone i.e. operating independently
without an NCS.
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.
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.
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
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.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;
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.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.
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.
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
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.
shall be provided.
Additional dedicated function keys or controls for controlling the MES and message handling functions
are recommended.
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).
(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.
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.
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.
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.
The interchange circuits between the DTE and the DCE should conform to CCITT Red Book
Recommendation V.24.
The electrical characteristics of the interchange circuits should comply with CCITT Red Book
Recommendation V.11/X.27.
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:
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.
(c) to alert the operator to the possibility that reliable communications may not be achievable due
to a degraded link.
(a) the MES shall be designed so that no transmission shall occur if an equipment module fails or
is
removed;
(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.
In addition to the above, it shall be possible to disable the transmitter for testing and/or safety
reasons.
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.
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.
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.
measurement methods and apparatus described in CISRP publication 16, "CISRP Specification for
Radio Interference Measuring Apparatus and Measurement Methods".
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.
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.
Spectral composition:
Infra Red 51%
Visible 44.5%
Ultra Violet 4.5%
(h) Vibration:
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:
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.
Contents
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)
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
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)
A suggested standard interface is defined in IEC 1162, Part2 (NMEA 0183) Standard for Interfacing
Electronic Marine Navigational devices.
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.
The interchange circuits between the DTE and the DCE should conform to CCITT Red Book
Recommendation V.24.
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)
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:
- 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:
- Slot Number
- 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
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.
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.
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 ⎠ ⎭
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)
Contents
1 Introduction ............................................................................ 4
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)
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)
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.
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>
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 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.
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.
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)
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 ';'.
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.
<CSI> [NCS] a
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.
<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 ' ; '.
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.
<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.
<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.
<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.
<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:
where
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.
<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.
<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.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
<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.
<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.
<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.
<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.
<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.
<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.
<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).
<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.
<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).
<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.
<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);
[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.
<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.
<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.
<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.
<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)
<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.
<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.
Command:
<CSI> 0 Z
Purpose: to terminate the current operation leaving the parameters in the DCE unchanged.
<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.
<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)
<CSI> 5 Y
<CSI > 5 L
Purpose: to initiate a Distress Alert. The DCE shall reply with within 1 second with:
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:
<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).
<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.
Command:
<CSI> 1 L
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.
<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).
<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).
<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.
<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.
<CSI> [NCS] l
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.
<CSI> ? C
Purpose: to interrogate the DCE about the channel type it is currently engaged on.
'5' Retuning
<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.
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:
<CSI> ? P
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.
<CSI> ? W
Purpose: to interrogate the DCE about the status of the current message transfer.
where [MESSAGE STATUS] is a string describing the current state of the message transfer in plain
language.
<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)
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.
<CSI> ? D
Purpose: to interrogate the DCE about the description of the first received message waiting to be
read.
Response from DCE:
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)
<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.
Examples: <CSI>?b will cause the DCE to respond with <CSI>079b if the
Destination LES ID has been previously set as 79;
<CSI> ? V
Purpose: to interrogate the DCE about the result of the previous Performance Verification Test.
Response from DCE :
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)
<CSI> ? M
Purpose: to retrieve the next received message from the DCE. The DCE then removes it from the
head of the waiting queue.
<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.
<CSI> ? X
Purpose: to determine the sequence of events and actions within the DCE since the last enquiry.
Used for testing.
<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".
<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)
<CSI> [STATUS] s
where [STATUS] is one character representing the current status of the MES and is coded as follows:
<CSI> ? N
Purpose: to interrogate the DCE about the information contained in the currently received TDM
(Bulletin Board and Signalling Channel Descriptor packets).
<DCS>N;<TDM INFO><ST>
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)
Example: slot 7 unreserved and burst correctly received in slot 7 will result in S7 as '2'.
Purpose: this status indicator will be presented by the DCE whenever the memory available is less
than 2 kbytes.
Example:
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;REQUEST PENDING<ST>
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)
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:
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:
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:
where [IDi] is an eight-character ASCII decimal representation of the 24-bit Group ID.
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)
Presentation <CSI>[PRES]g
Log in <CSI>0L
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)
3.5 Query
Current Channel ? <CSI>?C
Network ? <CSI>?B
Address ? <CSI>?c
Presentation ? <CSI>?g
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)
Network <DCS>B;<NETWORK><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)
Presentation <CSI>[PRES]g
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)
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)
Contents
0 Scope ..................................................................................... 2
1 Introduction ............................................................................ 3
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.
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
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.
e) 2-digit prefixed code addressing for From-Mobile Safety messages (see Volume 4, Chapter 4);
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.
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.
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:
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)
(i) Vibration:
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:
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)
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)
Contents
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)
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.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.
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.
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"
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)
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.
(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)
N.B. This programming material or software shall be resident in the DCE and/or the primary DTE.
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.
SOLAS SESs shall not perform automatic 24 hourly scanning of NCS common channels.
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".
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)
(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
(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.
This shall be the latest update of the distress alert parameters (see Section 8.2)
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.
Note that dedicated distress signalling channels are channels for which only the maritime distress bit
has been set in the signalling channel descriptor.
(7) Course;
(8) Speed;
(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 :
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).
(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)
(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.
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.
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:
A visual indication shall be provided at the primary DTE on initiation of a distress message.
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:
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.
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.
"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.
Where this option is fitted it shall be possible to test the security buttons. Method as 9.3.4.
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
(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.
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:
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:
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)
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.
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:
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:
2-5 Hz 2.54 mm
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)
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:
iv) overriding any From-Mobile or To-Mobile distress calling function being executed at the
primary DTE, distress buttons or DCE;
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.
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)
Contents
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.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.
"Shipborne Radio Equipment Forming Part of the Global Maritime Distress and Safety System and
Marine Navigational Equipment", published by the IEC as IEC 945.
2 General Requirements
As Chapter 2, Section 2 except where indicated below.
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.
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.
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:
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)
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 .
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:
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:
2-5 Hz 2.54 mm
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
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)
Contents
1 Introduction ............................................................................ 2
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.
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:
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)
Contents
1 Introduction ............................................................................ 3
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)
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
3 RF Subsystem Requirements
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.
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)
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.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.
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.
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)
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.
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.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.
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.
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.
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
Note: In the performance requirements above, the value of the Doppler variation is +/–50Hz over 10s.
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.
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.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)
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.
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.
The precedence for using these or other available channels for live Land Mobile Alerts are as follows:
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)
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.
(1) MES ID
(2) LES ID
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.
9 Testing Functions
As Chapter 2, Section 9, with the following exceptions:
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
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.
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).
(j) Mechanical Shock 1 : Half sine wave shock with a peak of 20g and a
duration of 11 ms.
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.
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)
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)
Contents
1 Introduction ............................................................................ 3
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)
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
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.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)
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.
(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)* ;
(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);
* 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.
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.
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)
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:
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.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.
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.
As Chapter 6.*
10 Electromagnetic Compatibility
As Chapter 2.
11 Environmental Conditions
As Chapter 2, Section 11.2, except where indicated below.
* 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).
(g) As Chapter 2, Section 11.2 with the following addition for battery operated equipment:
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)
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
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)
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.
Inmarsat does not require Non-SOLAS EGC receivers to comply with the electromagnetic
compatibility (EMC) or environmental requirements specified by IMO/IEC.
The following table gives a guide to the different sets of specifications for EGC receivers:
1 Introduction
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).
Designers of EGC receivers should familiarize themselves with the other chapters of this volume and
with other appropriate system definition documentation (see Chapter 1).
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)
Inm-C
transmitter receiver
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)
Inm-C
EGC receiver
EGC message
processor
2 General Requirements
(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;
(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
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)
4 Receiver Performance
The signal modulation and channel characteristics are identical to those presented in Chapter 2,
Sections 4.1 and 4.2.
The limits for the maximum acceptable PEP for a range of equivalent unfaded power flux densities
(PFD) at the antenna are as follows:
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.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:
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.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)
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).
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.4 Keyboard
Where a keyboard is fitted the requirements of Chapter 2 shall apply.
(iii) storing position coordinates and Navarea geographical area data; and
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)
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.
The type of address used in the header of an EGC packet is uniquely determined by the service code
field.
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.
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)
(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
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)
Contents
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.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.
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.
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-
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
2 General Requirements
(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)
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.
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 .
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.
It is recommended that provision is made for non-volatile storage of position coordinates and Navarea
geographical area data.
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.
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.
(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.
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:
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)
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.
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
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)
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)
Contents
1 Introduction ............................................................................ 3
1.1 Non-Solas SafetyNETSM Receivers ....................................................................3
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
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.
7.1 General
This Section describes the requirements and recommendations for the message processing
subsystem of the Non-SOLAS SafetyNETSM receiver.
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.
(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.
Additionally it is recommended that provision is made for non-volatile storage of position coordinates
and Navarea geographical area data.
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)
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.
Subsequent receptions of messages printed with mutilated characters shall be output again until
received error free.
"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:
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
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: 6
Chapter 8 - Annex B: Technical Requirements for a SafetyNETSM Receiver for Non-
SOLAS SESs
Inmarsat Confidential C SDM
(Version Release CD004, CN000)
Contents
1 Introduction ............................................................................ 2
1.1 FleetNETSM EGC Receiver .................................................................................2
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:
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.
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".
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.
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.
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
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
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)
Contents
1 Introduction ............................................................................ 3
1.1 Purpose and Scope ..........................................................................................3
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)
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
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
3 RF Subsystem Requirements
As Chapter 2, except where indicated below.
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)
(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
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.
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°.
With the aircraft in horizontal flight, the service coverage of the AMES installation shall be greater than
60%.
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:
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.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.
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.
4 Receiver Performance
As Chapter 2, except where indicated below.
(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).
(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)
(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).
(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:
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.
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.
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.
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)
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).
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
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:
6 - Humidity
8 - Vibration
16 - Power input
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)
Contents
1 Introduction ............................................................................ 3
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)
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
b) A target Packet Error Rate (PER) of 5% for packet length of 128 bytes
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)
3 RF Subsystem Requirements
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.
The G/T requirements shall be met under the conditions specified in Chapter 2 Section 3.3.1.
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.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:
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.
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.
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)
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.
-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
In addition the spurious within the frequency range between 960 MHz and 40000 MHz shall not
exceed the following values:
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)
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)
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.
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)
4 Receiver Performance
As Chapter 2, Section 4, except performance under blockage conditions is as described in Section
4.7 below.
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.
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.
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.
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
Note: In the performance requirements above, the value of the Doppler variation is +/–50Hz over 10s.
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.
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)
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.
- A signalling channel with low power C bit set in its signalling channel descriptor, if available.
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.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.
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.
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.
The precedence for using these or other available channels for live Land Mobile Alerts are as follows:
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)
(1) MES ID
(2) LES ID
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.
9 Testing Functions
As Chapter 2, Section 9, with the following exceptions:
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
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.
Note:
(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)
(j) Mechanical Shock 1 : Half sine wave shock with a peak of 20g and a
duration of 11 ms.
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.
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)
Contents
1 Introduction ............................................................................ 3
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)
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.
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
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)
3 RF Subsystem Requirements
The G/T requirements shall be met under the conditions specified in Chapter 2 Section 3.3.1.
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.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 :
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.
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.
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
-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
In addition the spurious within the frequency range between 960 MHz and 40000 MHz shall not
exceed the following values:
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.
- A signalling channel with low power C bit set in its signalling channel descriptor, if available.
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.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.
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)
When a display device is required, the following alarms and indications must be provided:
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:
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)
(i) Vibration:
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:
(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: 10
Chapter 11: Technical Requirements for Low Power Ship Earth Station
Inmarsat Confidential C SDM
(Version Release CD004, CN000)
Contents
1 Introduction ............................................................................ 2
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.
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)
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.
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:
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)
Contents
1 Introduction ............................................................................ 3
1.1 Document Structure ..........................................................................................3
1.2 NCS Site Interface ............................................................................................3
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.
This chapter provides an overview of the functions to be performed by the NCS and a summary of the
operational requirements.
- 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
Chapter 3 describes the requirements to be met in order to ensure the continued satisfactory
operation of the NCS, including:
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:
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.
(a) C-band,
(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.
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.
- 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.
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
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.
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.
(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.
(c) bar individual MESs (that is, prevent them from sending or receiving any messages other than
distress messages);
(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.
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.
The NCS is linked to each of the LESs within the ocean region by means of separate NCS – LES and
LES – NCS signalling channels.
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:
(b) a list of all LESs operating in the ocean region controlled by that NCS;
(d) a list of all the TDM frequency and associated return channel assignments available for
allocation by that 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.
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.
The NCS shall be able to coordinate a maximum of 64 LESs within an ocean region.
Contents
1 Introduction ............................................................................ 4
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:
- Data reporting
- Polling
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.
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.
NOC data
Links NCS/NCS Data Links
NOC NCSs
NCS 3
Signalling
Channel
Message SES
LESs channel
MESs
TDM
channel
Terrestrial
circuits
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.
- 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.
- the transmission of signalling and enhanced group call message packets on the NCS common
channel(s);
- the transmission of signalling and enhanced group call message packets on the ISLs;
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.
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.
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.
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.
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.
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:
Packet structure and individual packet formats are described in Volume 4, Chapter 6.
The transmission of packets on the NCS – LES interstation signalling link shall be in the following
priority basis in descending order:
The packet structure and individual packet formats are described in Volume 4, Chapter 6.
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.
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.
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
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.
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.
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.
The action of the NCS on receiving a polling request specifying an area directed polling command is
identical to that for group directed polling.
forwarded by the NCS for any reason then it is the responsibility of the NCS to handle the distress
alert.
- 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.
The following events will cause MES status information to be sent to the other NCSs:
- commissioning/de-commissioning of an MES;
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.
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.
- TDM channel;
- 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.
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.
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.
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.
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.
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.
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.
(1) equipment fault or loss of facility requiring immediate attention at all times; and
(b) Semi-Urgent Alarm-Equipment fault or loss of facility requiring attention as soon as possible
during working hours; and
(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;
- records details of the distress alert in the system and distress logs;
- 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.
(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.
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.
- 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.
- the forward and return Inmarsat-C 24 bit binary MES identities as defined in Part 2;
- result of the last commissioning or performance verification test performed on the MES;
- MES type
Entries are added to, and removed from, the MES list by the Inmarsat NOC.
Each MES listed in the MES list shall have the following status information associated with it:
This indicates whether or not a defined MES is currently in commission. Valid states are:
- pre-commissioned;
- commissioned.
This determines whether or not an MES may make calls. Valid states are:
This indicates whether or not the MES is logged-in to one of the ocean regions. Valid states
are:
This indicates whether or not the MES is currently busy interacting with an LES. Valid states
are:
- LES identity;
- Whether a continuous TDM channel is broadcast or whether demand assignment of LES TDMs
is in operation at that earth station;
The entries in the LES list are updated by the Inmarsat NOC.
The entries in the NCS list are updated by the Inmarsat NOC.
The information in the TDM assignment list is updated using information supplied by the Inmarsat
NOC.
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)
(i) spare;
(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.
- all protocol messages on the interstation signalling channels relating to allocation of LES TDM
assignments, logical channel establishment and channel clearing;
- distress alerts;
- changes in the operational status of LESs within that ocean region; and
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.
- all operator actions which affect the ability of the NCS to handle distress priority traffic.
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.
Contents
1 Introduction ............................................................................ 2
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
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.
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.
- 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.
3 Maintenance
The NCS shall provide a comprehensive fault logging system capable of producing a hard copy
output of all faults that occur.
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.
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.
Contents
1 Introduction ............................................................................ 2
1 Introduction
This chapter contains the technical requirements for the following communications network:
• NCS to NCS;
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
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;
NCS NCS
LES-NCS ISL
NCS NCS-NCS ISL
NCS-NOC ISL
The link supplied by Inmarsat will have a minimum speed of 1200 baud.
Inmarsat will supply the connection to the PSTN at each of the NCS sites.
NCS
AOR(E)
PSTN
PSTN
NCS NCS
NOC
AOR(W) POR
Speed 1200bps
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.
• MLP;
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.
• retransmit the oldest unacknowledged I frame with the poll bit set; or
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.
• when a polling REJ is sent, all frames shall be ignored until the final RR or RNR is
received, and,
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.
• 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.
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
Chapter 1: Introduction
Contents
1 Introduction ............................................................................ 2
1.1 Inmarsat C Services ..........................................................................................2
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.
- 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.
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
2 Packet Formats
The packet formats are described in Chapters 2 to 10. Most have a similar general structure which is
described here.
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.
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.
0B a short packet
An unsigned binary number giving the number of bytes from the end of the [Length] field.
An unsigned binary number giving the number of bytes from the end of the [Length] field.
An unsigned binary number giving the number of bytes from the end of the [Length] field.
Packets received on a Signalling channel and re-transmitted over an Interstation Signalling Link (ISL)
are treated according to the following rules:
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.
GENERATOR CHECKER
C0=0, C1=0 C0=0, C1=0
Inmarsat Confidential
Chapter 1: Introduction
B = First Byte B = First Byte
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
D1/3-22/cfh
Page: 6
(Version Release CD004, CN000)
C SDM
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
Contents
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.
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).
It is recommended that the LES keep frame numbers in synchronisation with real time—that is, as if
transmission never ceased.
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.
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.
Indicates whether there are any packets aside from the bulletin board and signalling channel
descriptors in this frame.
0H Reserved
1H NCS Common Channel
2H LES TDM Channel
3H Joint Common and TDM
4H Standby NCS Common Channel
5H-7H Reserved
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.
This uniquely identifies the ground-based station originating the bulletin board (see Volume 3, Part 1,
Chapter 3).
B6 1 = in service
0 = out of service
B5 1 = clear
0 = congested
B3-B2 Spare
Byte 1
B7 1 = SafetyNETSM Traffic
0 = No SafetyNETSM Traffic
B6 1 = Inmarsat-C Traffic
0 = No Inmarsat-C Traffic
B2 1 = Closed Network
0 = No Closed Network
B1 1 = FleetNETSM Traffic
0 = No FleetNETSM Traffic
Byte 2
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.
0B Signalling Channel is available NOT exclusively for the Low power C MES signalling.
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.
Bit No.
8 7 6 5 4 3 2 1
0 Type Length Packet Descriptor
Network Version
Frame Number
Services
Rnd Interval
Checksum
BULLETIN BOARD
Checksum
Contents
Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 1
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 2
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 3
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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.
Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 5
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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.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]
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.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].
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.
Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 8
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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:
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.
This field contains the priority of the message transmission and is coded:
00B Routine
01B Safety
10B Urgency
11B Distress
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)
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.
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:
Used for service code 02H and 72H, the address field contains the binary EGC network identity
(ENID);
Rectangular areas are used for service codes 04H and 34H.
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
Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 10
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
Circular areas are used for service codes 14H, 24H and 44H.
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
An unsigned binary number giving the radius of the circle in nautical miles.
This address is used for service code 11H and is a binary code indicating the type of system
message. It is coded as follows:
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)
An unsigned binary number giving the Navarea. This addressing is used for service code 31H.
Used in service code 23H and 33H, this address field contains an EGC receiver's forward MES
identity number.
Used with service code 73H. This address field contains a Chart Correction Service Fixed Area
number.
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).
Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 12
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 13
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
0B Pending
1B Rejected
Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 14
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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:
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:
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.
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)
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
Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 16
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
An unsigned binary number giving the number of message packets to be transferred (up to 255).
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.
The sequence and length fields (8 bits) are simply copied from the received enhanced data report for
which the acknowledgement refers.
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.
Defines the length, in bytes, of the data contents of the data report to which the acknowledgement
refers.
Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 18
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
A value of FFFFH in the LES TDM field implies that the particular land earth station is operating with
demand assigned TDM carriers.
0H To-Mobile
1H From-Mobile
2H SPARE
3H Both directions
01H 2048
02H 4096
03H 6144
04H 8192
05H 10240
Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 19
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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)
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
Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 21
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 22
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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
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)
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)
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)
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
Bit No.
8 7 6 5 4 3 2 1
MES ID
LES ID
Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 25
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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
Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 26
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
MES ID MES ID
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)
LES ID
MES ID
Logical Channel No.
Packet Sequence Number
LES ID
Message
Reference Number
Message Data
Message Status
Descriptor
n
LES ID
L.C.N
Message
Reference
Number
LES Descriptor
for
Service Dependant Descriptor
LES number "LES Total"
Presentation
Last Count
Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 28
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
MES ID MES ID
LES ID LES ID
PR Request Status
Test Results
Request Status
Signalling
Channel
Frame Offset
A Spare Slot No.
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)
Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 29
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
Address
Information
CRC
Information
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
Volume 4: Packet Formats and Usage, Chapter 3: TDM Packet Formats Page: 30
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
Contents
3.3.2.3 Examples.............................................................................................................................. 11
Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 1
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 2
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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.
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.
It should be noted that if the bit is set, then the [Checksum] field will always be at bytes 14 and 15.
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.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:
3.1 Acknowledgement
[Acknowledgement] ::= [Logical Channel Number]
[Errored Packet No]11
Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 5
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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.
The [Service Dependent Descriptor] field contains sub-fields relevant to the service as given in the
[Type] field as follows:
For PVT, this is set to the number of packets required to send the same message as received
during the To-Mobile stage.
An unsigned binary number giving the number of message packets to be transferred (up to
255).
Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 6
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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).
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
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)
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
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.
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
1H full addressing is in the [Additional Information] field of the message channel packet(s);
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.
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.
Byte 1 - the CCITT series identifier coded in IA5 with odd parity
(e.g. "V")
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).
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:
Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 11
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
3.5 Clear
[Clear] ::= [MES ID] [LES ID] [Logical Channel Number]
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)
Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 13
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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.
This field is reserved for future use, presently unused and set to zero.
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
Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 14
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 15
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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
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
Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 16
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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
Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 17
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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
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)
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
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
Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 19
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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
Volume 4: Packet Formats and Usage, Chapter 4: Signalling Channel Formats Page: 20
Inmarsat Confidential C SDM
(Version Release CD004, CN000)
Contents
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.
Coded as:
0 Immediate delivery
1 Deferred delivery
Coded as:
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.
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.
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.
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.
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.
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.
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
Data
Checksum Checksum
127 127
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
Contents
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
Note: EGC packets (codes 30,31,32,33H) are constrained to use the medium format.
For To-Mobile:
Copy of the [Frame Length] field of the logical channel assignment packet sent to the MES by the
LES.
An unsigned binary number representing the number of packets given in the assignment request
packet.
0B Failed
1B Completely delivered
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.2 I (1 bit)
0H No call
1H Announcing
2H Announcement in Queue
This is an unsigned binary number whose representation is dependent on the [Service] field.
For store and forward telex the following coding applies:
An unsigned binary number giving the number of packets to be transferred on the land earth station's
TDM.
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.
Data Report
Distress Alert
Message Status Request
MES Forced Clear
Test Request
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:
2) Only the packet descriptor from the first (or only) packet is retained, all others are removed.
0B Normal Priority
1B Distress Priority
3H Reserved
The time contained in the last Registration packet to be received which caused an update to the MES
database at the LES.
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.
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).
0H Reserved
3H..7H Reserved
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).
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]
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.
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.
0H Reserved
1H Inmarsat Mobile Number of the MES is used for the registration update request
4-7H Reserved
0-16FFH Illegal
0H To-Mobile
1H From-Mobile
2H Spare
3H Both directions
0H Not Commissioned
1H Barred
2H Not in OR
3H Idle
4H Busy
5H Decommissioned
Bit No.
8 7 6 5 4 3 2 1
Closed Network ID
NCS ID NCS ID
Last Sequence Number
Update
Request
Latest time time
Return MES ID
Class
Spot ID
RS Spare
Current NCS
MES Status Call Status Return MES ID
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
Announcement Reference
Service D Spare
Priority
LES TDM
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
LES TDM
Spot ID
Text
Spot ID Spot ID
Hold Time
Return
Channel 1
Return
Channel n
Bit No.
8 7 6 5 4 3 2 1
NCS ID
Update Request
Inmarsat Inmarsat
Mobile Number Mobile Number
Answerback Answerback
ISP_Code
AA_Code
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
Contents
1 General Structure
The packets conform to the general structure given in Chapter 1.
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.
[Block Update End] ::= [NCS ID] [Last Sequence Number] [Latest Time]
B3 1 = Not Barred
0 = Barred
B2 1 = Logged in
0 = Logged out
B1 1 = Commissioned
0 = Not commissioned
NCS ID NCS ID
UpdateTime
Contents
1 Introduction ............................................................................ 2
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
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
[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.
Contents
1 Introduction ............................................................................ 3
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.
2 Packet Formats
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
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
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
1H NAVAREA address.
3H Rectangular Area.
4H Circular Area.
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.
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.
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:
It is recommended that this bit is set for the Download DNID and Delete DNID commands.
Set to the same value as the [Command] field received in the Poll.
Set to the same value as the [Sequence Number] field received in the Poll.
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.
* 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.
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.
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.
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.
Used to program regular reporting by means of the Unreserved Data Reporting protocol. The [Text]
field in the Group Poll is defined as follows:
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.
This field defines the interval between data reporting transmissions as a frame count.
[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...
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.
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.
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).
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:
N is restricted by the constraint that the maximum length of a Poll packet is 300 bytes.
The MEM code that is to be associated with the message given in the [Message] field.
The MEM attribute code which, together with the MEM code, is to be associated with the message
given in the [Message] field.
An unsigned binary number indicating the number of bytes in the [Message] field.
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:
The MEM code representing the message stored at the MES to be displayed
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.
The [Text] field is available for use by the user and is treated as byte oriented binary data.
Used to download a Data Network ID. The MES stores five basic parameters associated with a Data
Network ID:
ii) the Sub-address in the [Subaddress] field (depending on the MES configuration; see Volume 1,
Chapter 5);
A number uniquely identifying the MES within the group defined by the Data Network ID, LES ID.
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.
The MES DCE shall ignore these commands and they may be passed directly to the sub-
address/DTE/application (depending on the DCE configuration).
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.
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.
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.
00B No Response
11B Reserved
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).
Contents
1 Introduction ............................................................................ 2
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.
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.
[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
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).
[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).
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).
The Logical Channel Number given in the Slot Logical Channel Assignment.
Byte
6 Sub-address 6
Data Network ID
7 Randomising Interval 7
Byte
Contents
1 Introduction ............................................................................ 2
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.
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]
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.
- Manual position flag (1 bit), set to 1 if position has been manually entered.
0H Unspecified (default)
1H Ambulance
2H Fire
3H Police
4H Hijack
7H Accident
8H Vehicle Breakdown
9H Severe Weather
AH-FH Spare
4H 1 hour or older
5H Not Available
6H Spare
7H Spare
0H Stopped
2H Medium 20 to 70 km/h
Contents
1 Introduction ............................................................................ 4
Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 1
Inmarsat Confidential C SDM
(Version Release CD004, CN142)
5 Alerting ................................................................................. 23
5.1 Distress Alert ................................................................................................... 23
5.2 Land Mobile Alert ............................................................................................ 24
5.3 Distress Alert Acknowledgement .................................................................... 24
Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 2
Inmarsat Confidential C SDM
(Version Release CD004, CN142)
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.
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.
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 Network Defines the type of terrestrial network or service to which the
message should be sent.
Address Location Indicates how and where the addressing information is held in
this packet and in the first message packet.
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)
Request Status Code Gives further information as to the reason for rejection/pending.
- 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.
Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 5
Inmarsat Confidential C SDM
(Version Release CD004, CN142)
From-Mobile:
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:
Message Reference Number A reference number for the message (binary coded).
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)
Logical Channel Number The LCN that has been assigned for the call.
With the exception of Follow-on To-Mobile calls, an Announcement is always used to initiate a To-
Mobile call.
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.
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)
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.
Presentation The presentation code to be used for the message text. For
PVT, this is normally set to data.
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.
Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 8
Inmarsat Confidential C SDM
(Version Release CD004, CN142)
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:
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.
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.
Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 9
Inmarsat Confidential C SDM
(Version Release CD004, CN142)
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.
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.
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.
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.
Logical Channel Number The LCN that has been used for the call.
For To-Mobile Message transfer the Message Reference Number has already been supplied at the
time of the Announcement.
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.
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.
Frame Length Copy of the [Frame Length] field of the logical channel
assignment packet sent to the MES by the LES.
For To-Mobile:
Logical Channel Number The LCN that has been used for the call.
Reason for Clear A code to indicate the reason for Force clearing.
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.
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:
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.
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.
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:
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.
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
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 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.
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.
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
Byte 2
Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 16
Inmarsat Confidential C SDM
(Version Release CD004, CN142)
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.
Land Mobile Alert Indicates if the channel is available for Land Mobile Alerting.
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.
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.
Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 17
Inmarsat Confidential C SDM
(Version Release CD004, CN142)
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.
LES Descriptors For each LES in the above total, a descriptor is included. It
contains the following information:
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.
Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 18
Inmarsat Confidential C SDM
(Version Release CD004, CN142)
LES Descriptors For each LES in the above total, a descriptor is included. It
contains the following information:
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.
INMARSAT Mobile Number The INMARSAT Mobile Number for the MES encoded in
binary.
Current NCS If the MES is logged into a region, this field will contain the
NCS ID. Otherwise it will be set to 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.
MES Status Four bits defining which station caused the change, whether
the MES is barred, logged in and commissioned.
Update Time The time at which the update was applied to the sender's MES
database. In Date-Time format.
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.
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.
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)
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.
Latest Time The time stored at the NCS of the last update to its database.
In Date-Time format.
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: 21
Inmarsat Confidential C SDM
(Version Release CD004, CN142)
Test Results The results of the Performance Verification Test are returned in the following format:
BBER The result of the Bulletin Board Error Rate assessment carried
out over the last 100 bulletin boards received by the MES.
Distress Alert Test The result of the Distress Alert test. The following codes
are used in the circumstances listed:
Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 22
Inmarsat Confidential C SDM
(Version Release CD004, CN142)
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.
5 Alerting
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.
Nature of Distress A code indicating the nature of the vessels distress situation.
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.
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.
Time of Position 3 bits coded to indicate how recently the position information
conveyed was updated.
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.
Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 24
Inmarsat Confidential C SDM
(Version Release CD004, CN142)
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.
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 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.
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)
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.
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.
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.
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.
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.
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
Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 27
Inmarsat Confidential C SDM
(Version Release CD004, CN142)
Member Number The member number of that MES within the DNID.
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.
The parameters of the acknowledgement data report (contained in the data field of the data report
packet) are as follows:
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.
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.
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.
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.
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)
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.
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.
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)
EGC Header Identical copy of the EGC Header in the first packet of the pair.
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.
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.
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.
Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 31
Inmarsat Confidential C SDM
(Version Release CD004, CN142)
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:
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
Current NCS If the MES is logged into a region, this field will contain the
NCS ID. Otherwise it will be set to zero.
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)
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.
Call Volume For From-Mobile - two fields: Packets and Frame Length,
where:
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)
Data Report
Distress Alert
Test Request
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).
9 Demand Assignment
If the NCS receives a TDM Request with the same reference number as a previously answered
request, the NCS will resend the response.
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.
Request Priority Indicates whether or not LES has distress traffic to process
immediately.
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.
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:
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.
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.
Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 35
Inmarsat Confidential C SDM
(Version Release CD004, CN142)
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.
Volume 4: Packet Formats and Usage, Chapter 12: Packet Usage Page: 36
Inmarsat Confidential C SDM
(Version Release CD004, CN000)
Contents
1 Introduction ............................................................................ 2
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.
2 Packet Formats
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
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.
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
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.
The definitions for standard data report packets are described in Volume 4, Chapter 4 of the SDM.
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.
The definitions of the polling packet type 24H are given in Figure 4.
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.
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
Contents
1. Introduction ........................................................................... 3
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.
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
[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.
0B No acknowledgement requested
1B Acknowledgement requested (default for unreserved data reporting)
Gives the closed network address to be used when sending a Data Report.
A number uniquely identifying the MES within the group defined by the Data Network ID and LES ID.
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.
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.
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]
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.
MES FWD ID
Enhanced Data Report
descriptor (MES 1)
Seq Length
The sequence and length fields (8 bits) are simply copied from the received enhanced data report for
which the acknowledgement refers.
Contents
1 Introduction ............................................................................ 3
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.
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.
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] ::= [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
LES ID LES ID
Slot Logical Channel Number Slot Logical Channel Number
M R R St Code
Start Frame
Signalling Channel
LES TDM
The format of the Slot Logical Channel Assignment Control/Query packet is defined below and
illustrated in Figure 2.
MES FWD ID
LES ID
Slot Logical Channel Number
A Q S R Control Code
2.2.1 A (1 bit)
Coded as follows:
0B No response/acknowledge requested
2.2.2 Q (1 bit)
Coded as follows:
1B Query function
2.2.3 S (1 bit)
Coded as follows:
0B Send assignment details for queried slot logical channel number only
9H - AH Not used
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.
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]
P C Type
MES RTN ID
LES ID
Slot Logical Channel Number
Pkts Spare
Interval Duration
Packet Checksum
Fill
An LES may only send this to MESs having assignments with that LES.
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]
P C Type P C Type
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
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.
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)
P C Type P C Type
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
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.
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
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]
7H Not used
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.
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)
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.
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.
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
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.
1–7 Increments of 1
10 – 70 Increments of 10
[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.
Demand assigned is not applicable in this context, since LES’s operating TDM’s in demand assigned
cannot support enhanced pre-assigned data reporting.
Chapter 1: Introduction
Contents
1 Introduction ............................................................................ 2
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.
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
3 Structure Information
Throughout this Volume, the SDL pages have individual figure numbers arranged as follows:
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.
System INMARSAT_C
Block LES
Process Demand_Assignment
Process MES_Control
Procedure Announce
Procedure Anomaly_SC
Procedure Distress
Procedure Test
Process MES_Sig
Process Multislot_Control
Procedure Anomaly_MC
Process Slot_Control
Procedure Anomaly_SL
Procedure Convert_Data_to_Signal
Process TDM_Generator
Macro Idle_Wait
Macro Clear_Idle_Wait
Block MES
Process LES_NCS_Sig
Process MES_MSG
Process MES_Sig_O_P
Process Process_Control
Procedure Data_Report
Procedure Forced_Clear
Procedure Login
Procedure Logout
Procedure MES_Distress
Procedure MES_Test
Procedure Poll
Procedure Test_Setup
Process Sig_Ch_Control
Procedure Anomaly_SCH
Procedure Select_Next_Frame_Offset
Macro Timeout
Block NCS
Process NCS_Demand_Assign
Process NCS_MES_Control
Procedure NCS_Announce
Procedure NCS_Distress
Procedure NCS_Login
Polling
Process Closed_Network_Control
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.
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);
MES _O (NCS_CC_LIST)
( MES_O UTPUT_L IST) NCS _C C
MES
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
Contents
1 Introduction ............................................................................ 4
Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 1
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 2
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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. 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
Individual poll request An individual poll request for the MES has arrived.
Inform R.C.C. Inform the rescue coordination centre that a distress alert has
been received.
Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 4
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
Various Packets Packet from NCS referring to this MES has arrived.
Reserve Confirm Confirmation that the reserving packet has been sent on the
TDM channel.
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.
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 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)
MS free The multislot may be reserved slot has failed to respond or has
persistent errors.
2.3.1 Variables
Clear Wait: boolean Set to T if waiting on timer t1.
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.
Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 6
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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.
Max Res Ctr: integer Maximum number of attempts to send a Test Result.
T16: duration Time to wait for MES message; transmission and re-
acquisition of TDM.
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.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.1 Variables
P: integer Count of number of multislots with errors or data after a
reservation.
Waiting for Input: boolean Data input is expected from the Signalling Channel.
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.
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.
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.
Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 9
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 10
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 11
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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)
(false)
TDM_
_Request(inf)
VIA NCSISL
1_Idle
- -
(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)
(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)
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*/
RESET(t3)
Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 15
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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)
(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
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)
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)
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
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)
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
(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
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)
2_In_OR
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
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)
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)
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
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)
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)
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)
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
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
Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 25
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
72_Wait_For_
_MES_Reply
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)
Test_ Distress_
Assignment_
_Request _Alert
_Request
/*NCS*/ /*MES_Sig*/
(MES)
RESET
Origin
(t2,t3,t4)
(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
(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)
'Inform_
_Operator'
Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 28
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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)
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*/
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)
21_Wait_For_
_Message
(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)
21_Wait_For_
_Message
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)
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)
61_Wait
Assignment_ Transfer_
_Request _Status_Request(inf) t2
/*MES_Sig*/ /*MES_Sig*/
(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)
62_Wait_For_
_Distress_
_Test
Distress_ Transfer_
_Alert_Test t2 _Status_Request(inf)
/*MES_Sig*/ /*MES_Sig*/
(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
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)
64_Wait_For_
_Result_
_Ack
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
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)
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)
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)
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)
11
Slot_ Transfer_Status_
_Reserved(inf) _Request(inf)
/*Slot_Control*/ /*MES_Sig*/
SET(NOW+
T17,t2)
12_Wait_For_
_Assignment_
_Response
Assignment_ Transfer_Status_
_Response _Request(inf) t2
/*MES_Sig*/ /*MES_Sig*/
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)
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)
DCL
A Boolean := False
2_in_OR
Enh_Data_R Enh_Data_R
t
eport eport_SRQ
False
A
False
CRC valid? - -
True
A? -
False
Set (NOW+
MaxCC*T0, t)
A:=True
Enh_Data_R
eport TO
LES_I_O
No Ack A
requested?
Yes
Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 42
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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)
1_Available *
Next_Slot(inf) Reserve_
Nothing Slot_Error Data(inf)
/*Slot_ _Request(inf)
/*MES_Sig*/ /*MES_Sig*/ /*MES_Sig*/
_Control*/ /*Slot_Control*/
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)
Anomaly_MC
2_Reserved_
*
_For_MES
Next_Slot(inf) SCD_Gone(inf)
Nothing Slot_Error
/*Slot_ /*Slot_
/*MES_Sig*/ /*MES_Sig*/
_Control*/ _Control*/
Next_Slot(inf) Reserve_
Nothing Slot_Error
/*Slot_ _Confirm(inf)
/*MES_Sig*/ /*MES_Sig*/
_Control*/ /*Slot_Control*/
- -
Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 45
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
'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)
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)
1_Waiting
Reserve_ Multislot_
_Slot _Free
/*MES_Control(x)*/ /*MSC(f_s_p)*/
'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)*/
'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)
Anomaly_SL Convert_Data_
_To_Signal
1_Waiting
('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)
'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)
DCL
; FPAR IN Message_Type INTEGER;
Class Integer := 0;
Message_
_Type
Volume 5: SDL, Volume 5: SDL, Chapter 2: Land Earth Station SDL Page: 51
Inmarsat Confidential C SDM
(Version Release CD004, CN141)
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)
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)
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)
Contents
1 Introduction ............................................................................ 3
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.1 Processes
1. LES/NCS Signalling Selects reserved or unreserved access for signalling packet
transmission.
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
Login/Out Request Operator wishes to log in/out of ocean region or spot beam.
Data Report Sent A message in data reporting mode has been sent successfully.
Report not sent A message in data reporting mode has failed to be sent.
Various Packet Types Packet of this type for this MES has been received on the NCS
common channel.
Various Packet Types Packet of this type for this MES or logical channel has been
received on a TDM channel.
Packet (reserved m-slot) Request to send a packet with reserved access on a particular
multislot.
2.3.1 Variables
C: Integer Count of attempts to send packet on the signalling
channel.
2.3.2 Timers
t Timer waiting for response from ground-based earth
station or from the operator.
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.
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.1 Variables
A: integer Number of blocks in a signalling channel transfer.
K: Frequency/multislot identifier.
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.
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
Figure 2: LES_NCS_SIG
Idle
(false)
Reserved_
_Access
(true)
Unreserved_Access
Reserved_
(C_Priority,
_Access
C_Service)
Idle
Send_
_Message
Message_
_Packet
Message_
_Sent
Idle
(LES)
Direction
(NCS)
Message_
_Type
Message_
_T ype
For C N132
compliant MES only
(8) (9) (10) (11) (12)
WT:=Nil
MES tuned to
0_Idle
NCS Common Channel
(PV_Test)
class
(From_MES)
(To_MES)
(Nil)
WT
(Other)
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 )
/*Signals_s hown_below_are_
MES_Distress to_apply_to_all_states_
of_process_including_
states_within_
all_procedur es*/
Login *
To_MES_ -
_Mess age_M
Forced_Clear
MES_Test
Test_Setup 0_Idle
Data_Report t1
(test)
Poll WT
(From_MES)
From_MES_ Test_
Data_Report_ _Message_M _Setup
_With_Ack (I_O,res ult) (test)
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
C:=0 *
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*/
MES_Forced_Clear()
MES_Distress To current
/*unreserved_access*/
(Real_Distress) TDM
VIA LES_Sig
15_Wait_For_
MES_Sig
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
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
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
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)
27_Wait_For_
_Message_ *
_Sent
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_
29_Wait_For_
_Message_
_MES_Sig
_Sent
Success,Fail
/*MES_LES_
Sig*/
SET(NOW+
T0,t)
28_Wait_
_For_Ack
C:=0,
Result:= *
Fail
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
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
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*/
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*/
Successful_ Logout_Request
MES_Distress
_Logout /*unreserved_access*/
(Real_Distress)
TO MES_I_O VIA NCS_Sig
75_Wait_For_
_MES_Sig
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
; 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_ (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
(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)
(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
61_Wait_For_
_Distress
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
-
65_Wait_For_
*
_MES_Sig
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*/
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)
DCL
MES_I_O PId;
Poll_Request
(selected_device)
TO MES_I_O
C:=0 *
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
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
(false)
Presentation_
_Code_Accepted
(true)
Unrecognised
Result:=Fail, Forced_ 84_Wait_For_Message,
Presentation
C:=0 _Clear 86_Waiting_For_Clear
Code
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
84_Wait_For_
_Message
Forced_Clear_ LES_Forced_Clear
t _Request (inf)
/*I_O*/ /*LES_TDM*/
82_Wait_For_
_MES_Sig
Success,Fail
85_Wait_For_
/*MES_LES_ *
_MES_Sig
Sig*/
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
Assignment_Response
RESET(t) RESET(t) /*reserved_access*/ Timeout RESET(t)
VIA LES_sig
Result
Result:=O_K C:=0 C:=0
:=Fail
VIA LES_Sig
85_Wait_For_ 85_Wait_For_
/*Unreserved_
_MES_Sig _MES_Sig
_access*/
DCL
C INTEGER :=0,
Destination_lES_Operating_with_
Permanent_TDMs Boolean :=False,
MES_I_O Pid;
Destinated_LES_Operating_
C:=0 with_Permanent_TDMs
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
DCL
C INTEGER :=0,
Destination_LES_Operating_with_
Permanent_TDMs Boolean :=False
C:=0
Destination_LES_operating_
with_permanent_TDMs?
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 C
eport_OK TO
MES IO
Reset t
C:=0,D:=0, C:=0,D:=0,
E:=0,B:=0, F:=0,A:= C:=C+1
R:=False Blocks,B:=A
/*BB(n)_or_ (true)
_BB(n-1)_or_ Offset=1 1_Waiting
_BB(n-2)=OK*/
(false)
(false)
TXEnable A
(true)
D:=D+1
Fail TO 2_Waiting_For_
Process_ _SCDs_In_
_Control _Next_Frame
1_Waiting
(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
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
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
(true) (unreserved)
Slot_Marker_
B=1 E
_For_K
(false) (reserved)
4_Waiting_ Fail TO
_For_SCD_ Process_
_Response _Control
1_Waiting
'Unspecified_
_Action'
e.g. Inform
Operator
'Select_Next_
_Frame_Offset'
Select a frame at
random between 1 and RI.
The selected number of
RI:=0
frames is the 'Backoff'.
C:=C+1
(false)
C<MaxCC
(true)
Timeout
TO MES_I_O
LES_TDM_d
escriptor_pac
ket
New
Contents
1 Introduction ............................................................................ 3
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.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 Packet regarding this MES has arrived from other NCS.
Various packets Packet regarding this MES has arrived from LES.
Various Packets Packet for this MES has arrived from the Signalling
Channel.
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.
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.1 Variables
Announcing: boolean Set true if announcement or individual poll
is current.
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.
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.
T22 Maximum time for NCS to hold MES for an announcement or poll.
LESi an arbitrary LES through which signalling packets, to or from the MES, are being
handled.
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.
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)
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
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
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
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
1_Not_
_Commissioned, 3_Idle 4_Busy
2_Not_In_OR
'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
2_Not_In_
_OR
(fail)
Result - - -
(O_K)
Registration
/*To non CN127
(idle)
compliant LESs*/
VIA LES_ISL
MES_Status_Change
To all
(commissioned,login,
other NCSs
MES_action)
MES_Region
:=This_OR
3_Idle
2_Not_In_
_OR
Test_Result MES_Status
Logout_Ack
(inf) (not_in_OR)
VIA NCS_CC
TO NCS_I_O VIA LES_ISL
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)
3_Idle
Request_ MES_Status_
_Status(inf) _Request
/*LESi*/ /*LESi*/
Request_ MES_Status
_Status(inf) (idle)
VIA NCS_CC VIA LES_ISL
3_Idle
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
3_Idle
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
(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)
- -
4_Busy
(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
4_Busy
'Place_In_ SET(NOW+
- RESET(t)
_Queue' T20,t)
SET(NOW+
T21,t1)
(message_status)
Class
(confirmation)
Confirmation Message_
VIA NCS_CC _Status
VIA NCS_CC
3_Idle
3_Idle,
*
4_Busy
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
RESET RESET
(t1,t,t2) (t1,t,t2)
/* All t1*/ /* All t1*/
2_Not_In_ 1_Not_
_OR _Commissioned
NCS_Login
R egistration_Update_
NC S_Announce
R equest
/* via ISL*/
LES_Enhanced_
R egistration
? no
yes Registration
VIA LES_ISL
Enhanced_Regis tration
VIA LES_ISL
-_
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
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'
Database_ (false)
_Check
=OK
(true)
Result Result
:=O_K :=Fail
Contents
1 Introduction ............................................................................ 2
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.
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
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_ Group_Poll_
t _Status t _Status
from NCS from NCS
(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
Inmarsat C
© 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
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.
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).
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.
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)
1. INTRODUCTION ..................................................................................................................... 1
2.1.1 General.......................................................................................................... 1
Recommended Test Procedures (RTPs), Front Page & Table of Contents, Page: 3
Section 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)
ITEM 6-A/1 POLLING AND DATA REPORTING TEST PROCEDURES ....... 131
Recommended Test Procedures (RTPs), Front Page & Table of Contents, Page: 4
Section 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)
3.1.1 General.......................................................................................................... 1
Recommended Test Procedures (RTPs), Front Page & Table of Contents, Page: 5
Section 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)
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)
Recommended Test Procedures (RTPs), Front Page & Table of Contents, Page: 7
Section 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)
Recommended Test Procedures (RTPs), Front Page & Table of Contents, Page: 8
Section 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)
7.2.3 RECEPTION................................................................................................. 5
8.1.1 Introduction................................................................................................... 1
Recommended Test Procedures (RTPs), Front Page & Table of Contents, Page: 9
Section 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)
Recommended Test Procedures (RTPs), Front Page & Table of Contents, Page: 10
Section 1: Introduction
Inmarsat Confidential C SDM
(Version Release CD004, CN000)
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.
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.
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.
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.
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.
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.
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.1 Place the equipment under test in the environmental test chamber(s) (temperature and
humidity).
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.
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 *.
tr is time it shall take to reach a specified condition (next test environment) from ambient.
x >3 hr >1 hr
>3 hr
Ambient
>3 hr
0ÞC EME 0ÞC
IME
-35ÞC Test
-35ÞC
x >1 hr
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.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).
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).
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.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.8 Repeat steps C.1.1 to C.1.6 for the DTE (if applicable).
(*) 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 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.
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.
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 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.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.
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:
NCS
7DFFxxxx5020206CFFFFFF03chks
6CF036AE00000000000000chks
MES
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.
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
LES 11:
- ID = 01110
LES 12:
- ID = 01210
LES 13:
- ID = 01310
- out of service;
LES 14:
- ID = 01410
- operating with a permanent TDM at ch. 232E (f = 1532.515 MHz) on a spare satellite;
LES 15:
- ID = 01510
- operating with a permanent TDM at ch. 27A4 (f = 1535.370 MHz) on a spare satellite;
- out of service
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.
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.
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.
The NCS/LES simulator should be able to respond with a Distress Alert Acknowledgement set up for the MES
ID.
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.
1 ANTENNA TESTS
7 MESSAGE PROCESSING
9 TESTING FUNCTIONS
10 ELECTROMAGNETIC COMPATIBILITY
Notes:
A: ambient temperature
T: temperature
H: humidity
P: power
V: vibration
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
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:
- 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).
(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;
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).
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:
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:
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).
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.
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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
Note: If a radome is used under normal operation conditions these characteristics should be
measured with the radome fitted.
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:
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.
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.
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.
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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
MES
ANTENNA
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.
(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.
Pn
Y1 = P
a
Po
Y2 = P
a
Po
Y3 = P
n
(h) Calculate the system noise temperature as follows:
since
where
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
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.
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
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:
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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient
Temperature
4 TEST SET-UP
NCS/LES MES
SIMULATOR
TEMPERATURE CHAMBER
CONTROLLER DTE
Figure 2-C
6 PROCEDURE
(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.
7 PASS/FAIL CRITERIA
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient
Temperature
Humidity
4 TEST SET-UP
ENVIRONMENTAL CHAMBER
IF TEST* SPECTRUM
ANALYSER
GENERATOR
MES DCE
Figure 2-D
6 PROCEDURE
(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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient
Temperature
Humidity
Power supply
4 TEST SET-UP
ENVIRONMENTAL CHAMBER
IF TEST* SPECTRUM
ANALYSER
GENERATOR
MES DCE
Figure 3-A
(b) Power meter, of known accuracy over the desired frequency and level 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 Inmarsat-C
unit (i.e. AC mains, DC mains, battery).
(e) Coupling Network: This may consist of directional coupler, circulator, combiner, attenuator
and/or load.
6 TEST PROCEDURE
(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.
(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.
(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.
(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
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
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:
dPT = variation of power output due to effects of temperature and humidity and
variations in the power supply;
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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
NCS/LES
COUPLER
SIMULATOR MES
SPECTRUM
ANALYSER DTE
CONTROLLER
Figure 3-C
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).
(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
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
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
(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).
(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.
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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient
Temperature
Humidity
Vibration
4 TEST SET-UP
NCS/LES
COUPLER
SIMULATOR MES
ATTEN-
UATOR
NOTCH SPECTRUM
FILTER ANALYSER
CONTROLLER DTE
Figure 3-E
(b) Notch filter and calibrated LNA (if necessary for the receive band);
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.
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
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
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:
(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.
(ii) 0°C
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
1661.5 -77
1751.5 -85
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient
Temperature
4 TEST SET-UP
NCS/LES
SIMULATOR COUPLER
MES
ATTENUATOR
SPECTRUM
ANALYSER
CONTROLLER DTE
Figure 3-F
(c) Attenuators
6 PROCEDURE
(b) Adjust the attenuators such that the carrier is at the spectrum analyzer reference level.
(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
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient
Temperature
Vibration
4 TEST SET UP
SIGNAL
GENERATOR
DTE
Figure 3-G
(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.
(d) Mixer.
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.
(d) Scan the phase noise between 10Hz and 100kHz from the carrier and plot the result. The
maximum permitted analyzer bandwidth is:
---------------------------- -----------------
10 - 100 1
100 - 1k 10
1k - 10k 100
0°C
35°C
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.
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
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
Temperature
4 TEST SET-UP
TEMPERATURE CHAMBER
NCS/LES
SIMULATOR COUPLER MES
FREQUENCY
COUNTER
CONTROLLER DTE
Figure 3-H
6 TEST PROCEDURE
Channel Number
7 PASS/FAIL CRITERIA
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient
Temperature
Humidity
Power Supply
4 TEST SET-UP
ENVIRONMENTAL CHAMBER
NCS/LES
SIMULATOR COUPLER
MES
CONTROLLER DTE
Figure 3-I
(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).
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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient
Temperature
Humidity
Vibration
4 TEST SET-UP
NCS/LES CHANNEL
SIMULATOR SIMULATOR MES
POWER
SUPPLY
DTE
CONTROLLER
Figure 4-A
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
(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.
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.1 Received carrier level corresponding to a PFD of -145.5 dBW/m2 at the MES antenna*;
*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.
(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).
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).
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.
(i) Disable the multipath and repeat step (e) with a simulated out-of-band interference at +130
dBc (referred to the wanted carrier).
(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:
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient
Temperature
Humidity
Power supply
Vibration
4 TEST SET-UP
(c) RF switch.
(d) Counter.
(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.
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)
(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:
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).
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.
(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
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:
...
Pk 1-10-(2+k)
PART B:
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)
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient
Temperature
Power supply
4 TEST SET-UP
TEMPERATURE CHAMBER
SPECTRUM POWER
ANALYSER COUNTER SUPPLY
DTE
CONTOLLER
Figure 5-A
(d) RF Coupler.
(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).
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:
Steps d.2: The clock frequency shall be within the following limits:
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient
4 TEST SET-UP
CLOCK
SPECTRUM COUNTER
ANALYSER
CONTROLLER DTE
Figure 5-B
(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).
(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:
Steps d.2: The clock frequency shall be within the following limits:
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
NCS/LES SIMULATOR
MES
DEMODULATOR
DATA
ANALYSER DTE
CONTROLLER
Figure 5-C
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).
(b) Cause the MES to send an Acknowledgement packet with normal priority to the NCS/LES
simulator. Record the values assumed for:
(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:
(e) Cause the MES to send a Clear packet with normal priority to the NCS/LES simulator.
Record the values assumed for:
(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:
- 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.
(h) Cause the MES to send a Forced Clear packet with normal priority to the NCS/LES simulator.
Record values assumed for:
(i) Cause the MES to send a Login Request packet with normal priority to the NCS/LES
simulator. Record the values assumed for:
(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:
(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 stage;
(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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
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.
(b) Cause the MES to transmit a message with the following characteristics:
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:
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:
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:
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.
and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.
(g) Cause the MES to transmit a message with the following characteristics:
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:
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:
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:
and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.
(k) Cause the MES to transmit a message with the following characteristics:
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:
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:
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:
and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.
(o) Cause the MES to transmit a message with the following characteristics:
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:
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:
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:
and indicate on the test data sheet the values assumed for the class, confirmation request and
logical channel number fields.
(s) Cause the MES to transmit a message with the following characteristics:
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:
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:
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:
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.
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
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 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 address (12 bits; 3 bcd digits - {ccc}, the 3-digit country code).
(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 address (16 bits; 4 bcd digits - {0ddd} or {dddd}, the DNIC prefixed with zero if
necessary).
(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.
(h) Repeat (f) and (g) for the Prefixed Store and Forward service, if the protocol is supported.
- 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:
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.
(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.
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
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.
protocol PSTN
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.
protocol PSDN
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.
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.
(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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
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 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).
(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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
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:
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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
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 destination extension (1 byte; value 80H, Basic X.400 presentation 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 (b) and (c) for the Prefixed Store and Forward service, if the protocol is supported.
(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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
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.
protocol X.400
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.
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.
(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.
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
Signalling Channels =1
Two-frame Count =0
Empty Frame =0
Spare =0
Local ID =0
Spare =0
Services(byte two) =0
Randomising = 10
Spare =0
X indicates setting as required for test. The settings of the Checksums will be given for each test.
(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.
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.
For this test another Test Frame is defined for the NCS TDM only:
Bulletin Board same as for the Basic Test Frame, except that the Empty Frame field is set to 1;
Direction = To-Mobile
Priority = Routine
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.
Note: Frame(s) may be lost whilst the receiver re-tunes and synchronises with the LES TDM
(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.
(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
MES on the NCS Common Channel a Test Announcement Frame in frame 0. In the Nth
frame reset the SCD checksum to good.
Note: Frame(s) may be lost whilst the receiver re-tunes and synchronises with the LES TDM
(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.
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.
(a) Repeat Test 2 up to Frame 0 then continue the following variations for frames 1 to 3:
Expected result: The MES should tune to the LES Signalling Channel and send an Assignment
Response packet.
Expected result: The MES should tune to the LES Signalling Channel and send an Assignment
Response packet.
Expected result: The MES should tune to the LES Signalling Channel and send an Assignment
Response packet.
(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.
(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.
(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).
(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.
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.
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 Services[2] =0
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.
(f) Perform the following steps in sequence and note the MES response:
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:
3) Send as EGC message from the selected LES (only for Class-2 or 3 MES).
(h) Reset the NCS and LES TDM bulletin boards. Transmit a sequence of unmodified Basic Test
Frames from both the NCS and the LES.
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 Services[2] =0
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:
(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 Services[2] =0
Good Checksum
Expected result: the MES remains tuned to the NCS. The new network configuration information is
accepted and stored.
(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.
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.
(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.
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 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.
(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.
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.
(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.
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.
(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.
(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.
(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.
(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.
(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.
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.
(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.
(a) Transmit a sequence of Basic Test Frames from the NCS and LES, each with a good
checksum for both BB and SCD.
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.
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) 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.
(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.
Bulletin Board same as for the Basic Test Frame, except that the Empty Frame field is set to 1;
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.
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.
(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.
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.
(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
(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.
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.
(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.
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 Services[2] =0
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.
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:
NCS
LES
MES
MES/CSIG/F0/ASSIGNMENT REQUEST - OK
MES/MSG/F1/Test Message
LES/TDM/F(EOM)+3/ACKNOWLEDGEMENT
LES/TDM/F2+R+3/CLEAR
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:
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.
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).
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
b) Repeat as in a), but send the Acknowledgement Packet R+N2 frames later.
MES/NSIG/F0/DISTRESS ALERT - OK
Expected result: MES should repeat the Distress Alert automatically after the timeout on the NCS
Signalling channel:
MES/NSIG/F1/DISTRESS ALERT - OK
c) Repeat as in a) and make the transmission of the Distress Alert packet fail.
Expected result: MES should repeat the Distress Alert MaxC times on the NCS Signalling channel:
MES/NSIG/F1/DISTRESS ALERT - OK
(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
(b) Repeat as in a), but send the Acknowledgement Packet R+N2 frames later.
MES/CSIG/F0/DISTRESS ALERT - OK
MES/CSIG/F1/DISTRESS ALERT - OK
---
MES/CSIG/Fn/DISTRESS ALERT - OK
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
(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
MES/CSIG/F2/DISTRESS ALERT - OK
---
MES/CSIG/Fn/DISTRESS ALERT - OK
MES/NSIG/Fn1/DISTRESS ALERT - OK
MES/NSIG/Fn2/DISTRESS ALERT - OK
---
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
(d) Repeat as in a). but make the transmission of the Distress Alert Packet 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
(e) Repeat as in d) and send the Acknowledgement Packet from the NCS after R+N2 frames.
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:
MES/NSIG/F1/DISTRESS ALERT - OK
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
Expected result: The MES should send the Distress Alert on the NCS Signalling channel. Alert OK
With the MES's memory cleared, initiate a request for Log-in with network version number 0.
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
(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
(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
(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
(f) Enter a new NCS ID and channel number in the NCS ID list as follows:
NCS ID 145
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
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.
Expected Result: The network version number in login request packet should be zero.
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).
MES/NSIG/F0/LOGOUT - FAIL
(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: The network version number in login request packet should be the same as what is
given in the login ACK in step (g).
Login and prepare a test message and initiate a From-Mobile message transfer to the LES with
permanent TDM.
(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
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
(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)
(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/F1/FORCED CLEAR
(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
MES/MSG/F1/Test Message
LES/TDM/F(EOM)+N2/ACKNOWLEDGEMENT
LES/TDM/F2+R+N2/ACKNOWLEDGEMENT
LES/TDM/Fn+R+N2/ACKNOWLEDGEMENT
(g) As above but with a Clear packet from the LES after the first time-out
MES/CSIG/F0/ASSIGNMENT REQUEST - OK
MES/MSG/F1/Test Message
LES/TDM/F(EOM)+N2/CLEAR
LES/TDM/F2+R+N1/CLEAR
(h) As above but with an Acknowledgement packet for only a part of the message
MES/CSIG/F0/ASSIGNMENT REQUEST - OK
MES/MSG/F1/Test Message
LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT(Part)
LES/TDM/F(EOMP)+N1/CLEAR
(i) As above but with a subsequent assignment after the first message transfer (retransmit the
whole message)
MES/CSIG/F0/ASSIGNMENT REQUEST - OK
MES/MSG/F1/Test Message
MES/MSG/F2/Test Message
LES/TDM/F(EOM)+N1/CLEAR
MES/CSIG/F0/ASSIGNMENT REQUEST - OK
MES/MSG/F1/Test Message
LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT(Part)
MES/MSG/F2/Test Message(Part)
LES/TDM/F(EOMP)+N1/FORCED CLEAR
(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
(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
MES/MSG/F3/Test Message
LES/TDM/F(EOM)+N1/CLEAR
MES/CSIG/F0/ASSIGNMENT REQUEST - OK
LES/TDM/F0+R+N1/REQUEST STATUS(Pending)
NCS/NCC/F0+N1+70/ANNOUNCEMENT
(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
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
MES/MSG/F1/Test Message
LES/TDM/F(EOM)+N1/CLEAR
NCS/NCC/F2/CONFIRMATION
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
(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
MES/CSIG/F1/DISTRESS ALERT - OK
i) Repeat (n) but following the message transmit the Distress Alert whilst awaiting the
Clear.
MES/CSIG/F0/ASSIGNMENT REQUEST - OK
MES/CSIG/F1/Test Message
MES/CSIG/F2/DISTRESS 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
(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
MES/MSG/F3/Test Message
LES/TDM/F(EOM)+N1/CLEAR
(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
(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
(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
(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
MES/MSG/F3/Test Message
LES/TDM/F(EOM)+N1/CLEAR
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)
NCS/NCC/F2+N1/ANNOUNCEMENT (From-Mobile)
MES/CSIG/F3/ANNOUNCEMENT RESPONSE - OK
MES/MSG/F4/Test Message
LES/TDM/F(EOM)+N1/CLEAR
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
(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
MES/NSIG/F3/DISTRESS ALERT - OK
(a) Send an Announcement packet (To-Mobile) and make the subsequent Assignment Response
fail
NCS/NCC/F0/ANNOUNCEMENT
(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
(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
(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
LES/TDM/F2+R+N1/ACKNOWLEDGEMENT REQUEST
LES/TDM/F(FO1)+4/Test Message
LES/TDM/F4/ACKNOWLEDGEMENT REQUEST
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
(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
LES/TDM/F(FO)+R+N1/FORCED CLEAR
(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
(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.
NCS/NCC/N0/ANNOUNCEMENT
MES/CSIG/F1/ASSIGNMENT RESPONSE - OK
LES/TDM/F1+4/Test Message
(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
NCS/NCC/F0/ANNOUNCEMENT
MES/CSIG/F1/ASSIGNMENT RESPONSE - OK
LES/TDM/F1+4/Test Message
LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT REQUEST
LES/TDM/F(FO)+R+N1/CLEAR
(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
LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT REQUEST
LES/TDM/F(EOMP)+N1/ACKNOWLEDGEMENT REQUEST
LES/TDM/F(FO2)+R+N1/CLEAR
(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/F2/ASSIGNMENT RESPONSE - OK
LES/TDM/F(EOM2)+N1/ACKNOWLEDGEMENT REQUEST
LES/TDM/F(EOMP)+N1/ACKNOWLEDGEMENT REQUEST
LES/TDM/F(FO3)+R+N1/CLEAR
(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
MES/CSIG/F1/ASSIGNMENT RESPONSE - OK
LES/TDM/F2/Test Message
LES/TDM/F(EOM)+N2/ACKNOWLEDGEMENT REQUEST
LES/TDM/F3+R+N1/ACKNOWLEDGEMENT REQUEST
MES/CSIG/F(FO)/ACKNOWLEDGEMENT(no error) - OK
LES/TDM/F(FO)+R+N2/CLEAR
LES/TDM/F4+R+N1/CLEAR
Expected result: Anomaly Timeout, should be reported on both occasions, but final result should be
OK-Message available.
(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)
(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
LES/TDM/F(FO)+R+N1/CLEAR
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
LES/TDM/F(FO)+R+N1/CLEAR
MES/CSIG/F3/ASSIGNMENT REQUEST - OK
MES/MSG/F4/Test Message
LES/TDM/F(EOM)+N1/CLEAR
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.
(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
LES/TDM/F(FO)+R+N1/CLEAR
MES/CSIG/F3/ASSIGNMENT REQUEST - OK
MES/MSG/F4/Test Message
LES/TDM/F(EOM)+N1/CLEAR
MES/CSIG/F7/DISTRESS ALERT(TEST) - OK
LES/TDM/F8+N2/TEST RESULT
Note: F8 is equal to the frame number (F7+R+N1) where the Distress Alert Acknowledgement packet
is sent.
(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
LES/TDM/F(FO1)+R+N1/CLEAR
MES/CSIG/F3/ASSIGNMENT REQUEST - OK
MES/MSG/F4/Test Message
LES/TDM/F(EOM)+N1/CLEAR
MES/CSIG/F7/DISTRESS ALERT(TEST) - OK
LES/TDM/F8+N2/TEST RESULT
LES/TDM/F9+R+N1/TEST RESULT
LES/TDM/F10+7+N1/FORCED CLEAR
(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
LES/TDM/F(FO1)+R+N1/CLEAR
MES/CSIG/F3/ASSIGNMENT REQUEST - OK
MES/MSG/F4/Test Message
LES/TDM/F(EOM)+N1/CLEAR
MES/CSIG/F7/DISTRESS ALERT(TEST) - OK
LES/TDM/F8+N2/TEST RESULT
LES/TDM/F9+R+N1/TEST RESULT
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
LES/TDM/F(FO1)+R+N1/CLEAR
MES/CSIG/F3/ASSIGNMENT REQUEST - OK
MES/MSG/F4/Test Message
LES/TDM/F(EOM)+N1/CLEAR
MES/CSIG/F6/DISTRESS ALERT(TEST) - 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
LES/TDM/F(FO1)+R+N1/CLEAR
MES/CSIG/F3/ASSIGNMENT REQUEST - OK
MES/MSG/F4/Test Message
LES/TDM/F(EOM)+N1/CLEAR
MES/CSIG/F7/DISTRESS ALERT(TEST) - OK
LES/TDM/F8/TEST RESULTS
Expected result: The transfer status request (waiting for clear) is sent MaxCC-1 times and the PVT fails
(timeout).
(a) Issue a Test Request from the DTE Operator's console. Make the Test Request signal fail.
(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/F1+R+N1/ANNOUNCEMENT(PVT)
MES/CSIG/F2/ASSIGNMENT RESPONSE - OK
LES/TDM/F3/Test Message
LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT REQUEST
LES/TDM/F(FO1)+R+N1/CLEAR
MES/CSIG/F4/ASSIGNMENT REQUEST - OK
MES/MSG/F5/Test Message
LES/TDM/F(EOM)+N1/CLEAR
MES/CSIG/F7/DISTRESS ALERT(TEST) - OK
LES/TDM/F8+N1/TEST RESULT
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
(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
MES/NSIG/F2/TEST REQUEST - OK
NCS/NCC/F3+R+N1/ANNOUNCEMENT(PVT)
MES/CSIG/F4/ASSIGNMENT RESPONSE - OK
LES/TDM/F5/Test Message
LES/TDM/F(EOM)+N1/ACKNOWLEDGEMENT REQUEST
LES/TDM/F(FO1)+R+N1/CLEAR
MES/CSIG/F6/ASSIGNMENT REQUEST - OK
MES/MSG/F7/Test Message
LES/TDM/F(EOM)+N1/CLEAR
MES/CSIG/F9/DISTRESS ALERT(TEST) - OK
LES/TDM/F10+N1/TEST RESULT
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
LES/TDM/F(FO1)+R+N1/CLEAR
MES/CSIG/F4/ASSIGNMENT REQUEST - OK
MES/MSG/F5/Test Message
LES/TDM/F(EOM)+N1/CLEAR
MES/CSIG/F7/DISTRESS ALERT(TEST) - OK
LES/TDM/F8+N1/TEST RESULT
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.
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.
(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.
Network Version =1
Signalling Channels =1
Two-frame Count =0
Empty Frame =0
Spare =0
Local ID =0
Spare =0
Services(byte two) =0
Randomising = 10
Spare =0
X indicates setting as required for test. The checksums should be set as required for each test.
(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.
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.
For this test, another Test Frame is defined for the NCS TDM only:
Bulletin Board same as for the Basic Test Frame, except that the Empty Frame field is set to 1;
DNID =4
LES ID = 111
Sub-address =0
Randomising Interval =0
Start Frame =1
DNID =4
LES ID = 111
Sub-address =0
Randomising Interval =1
Response = 01
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.
Note: Frame(s) may be lost whilst the receiver re-tunes and synchronises with the LES TDM
Moreover, the MES will attempt to send the data report at every interval until the stop command is
received.
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.
Note: Frame(s) may be lost whilst the receiver re-tunes and synchronises with the LES TDM
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.
(i) Repeat Test (b) up to Frame -3, and then continue the following variations for frame -1 to 1:
Expected result: The MES should tune to the LES Signalling Channel and send a Data Report.
Expected result: The MES should tune to the LES Signalling Channel and send a Data Report.
Expected result: The MES should tune to the LES Signalling Channel and send a Data Report.
(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).
(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.
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.
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 Services[2] =0
(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.
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
LES Total =1
LES Services[2] =0
(ii) Transmit a continuous sequence of good Basic Test Frames from the NCS with the Channel
Type set to NCS Common Channel.
(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'.
(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.
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.
(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.
Note: Frame(s) may be lost whilst the receiver re-tunes and synchronises with the LES TDM
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.
(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.
(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.
(i) Use the simulator to transmit to the MES on the LES TDM a sequence of Test Frames and all
slots free.
Note: Frame(s) may be lost whilst the receiver re-tunes and synchronises with the LES TDM
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.
(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.
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).
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).
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.
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).
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)
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.
Expected result: The MES should consider the transmission failed after Max F attempts.
(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)
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.
(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.
Expected result: The MES should terminate sending the subsequent data reports until the LES is back
in the permanent mode.
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.
(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.
(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.
Expected result: The MES may resume the unreserved data reporting after receiving the Login ACK.
Network Version =2
Signalling Channels =2
Two-frame Count =0
Empty Frame =0
Spare =0
Local ID =0
Spare =0
Services(byte two) =0
Randomising = 10
Spare =0
Spare =0
DNID =4
LES ID = 111
Sub-address =0
Randomising Interval =0
Start Frame =1
DNID =4
LES ID = 111
Sub-address =0
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
Note: Frame(s) may be lost whilst the receiver re-tunes and synchronises with the LES TDM
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-100)2
Kei = 100 ;
28
Xe = Xei
i=24
(iii) Change the Setup as defined above and repeat the test step (i).
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-25)2
Kfi= 25 ;
20
Xf = Kfi
i=1
PART 2 POLLING
(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.
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.
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.
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.
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.
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.
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.
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.
Expected result: The MES should handle the EGC message until it is completed. Then send the
unreserved data reports at subsequent intervals.
Bulletin Board same as for the Basic Test Frame, except that the Empty Frame field is set to 1;
Sub-address =0
DNID = 23456
Response = 00
Command = 0A
Sequence No. =1
(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.
(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.
(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
Sub-address =0
Randomising Interval = 00
Response = 00
Command = 09
Sequence No. =3
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
Sub-address =0
Randomising Interval = 00
Response = 00
Command = 89
Sequence No. =1
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.
(v) This test is only possible for the MES which has both EGC receiving and Data Reporting
functions
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.
LES ID = 112
Sub-address =0
DNID =4
Response = 00
Command = 8A
Sequence No. =7
(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.
LES ID = 113
Sub-address =0
DNID =4
Response = 00
Command = 8A
Sequence No. =7
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
Sub-address =0
Randomising Interval = 02
Response = 00
Command = 89
Sequence No. =1
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.
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.
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.
Expected result: The MES should consider the transmission of the ACK succeeded.
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
Sub-address =0
Randomising Interval = 02
Response = 00
Command = 89
Sequence No. =1
Expected Result: The MES should receive such a data transmission poll and send back an ACK.
Sub-address =0
DNID = 3333
Response = 00
Command = 8A H
Sequence No. =1
Member Number = 44
(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 tune to the LES Signalling Channel and
send the ACK as follows:
DNID = 3333
Member Number = 44
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
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.
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.
Sub-address =0
DNID = 9999
Response = 00
Command = 01
Sequence No. =2
Member Number = 88
Start Frame = 50
Slot No. =2
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.
Sub-address =0
DNID = 9999
Response = 00
Command = 8A H
Sequence No. =3
Member Number = 99
(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:
DNID = 9999
Member Number = 99
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.
Sub-address =0
DNID = 9999
Response = 01
Command = 02
Sequence No. =1
(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.
Sub-address =0
DNID = 3333
Response = 00
Command = 04
Sequence No. =2
(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.
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.
Sub-address =0
DNID = 3333
Response = 00
Command = 8B
Sequence No. =4
(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.
(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
Member Number = 44
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.
Sub-address =0
DNID = 3333
Response = 01
Command = 00
Sequence No. =3
(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.
(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
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.
DNID = 7777
Sub-address =1
Randomising Interval =1
Response = 00
Command = 84
Sequence No. =5
Start Frame = 50
(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
Member Number = 99
Command = 84 H
Sequence No. =5
DNID = 7777
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.
DNID = 7777
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.
(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.
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.
(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
Sub-address =0
DNID = 9999
Member Number = 88
Start Frame = 50
Slot No. =2
Duration =4
DNID = 9999
Sub-address =0
Randomising Interval = 00
Response = 01
Command = 02
Sequence No. =8
(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.
DNID = 9999
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.
DNID =0
Sub-address =0
Randomising Interval = 00
Response = 00
Command = 03
Sequence No. =8
LCN =1
(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.
This test will be done after the area polling test if the MES supports Area Polling Service.
DNID = 9999
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: 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.
NAVAREA =9
DNID = 3333
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.
DNID = 7777
Sub-address =0
Randomising Interval =3
Response = 01
Area Type =1
Area Length =1
Area =8
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.
(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.
(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.
DNID = 7777
Sub-address =0
Randomising Interval =0
Response = 00
Area Type =3
Area Length =4
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.
(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.
(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.
DNID = 7777
Sub-address =0
Randomising Interval = 40
Response = 00
Area Type =4
Area Length =4
Command = 89
Sequence No. = 14
(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
Member Number = 99
Command = 89 H
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.
(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.
(iiv) Repeat the test steps (i) and (ii) except that the LES ID and the Sequence No. are changed in
the area poll packet.
Sub-address =0
DNID = 11111
Start Frame =5
Slot No. =2
Duration =1
DNID = 11111
Sub-address =0
Randomising Interval = 00
Response = 01
Command = 02
Sequence No. =8
(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.
Note: Frames may be lost whilst the receiver re-tunes and synchronises with the LES TDM
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.
(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.
Note: Frames may be lost whilst the receiver re-tunes and synchronises with the LES TDM
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.
(i) Repeat Test (a) up to Frame 0, and then continue the following variations for frame 3 to 5:
Expected result: The MES should tune to the LES Signalling Channel and send a Data Report.
Expected result: The MES should tune to the LES Signalling Channel and send a Data Report.
Expected result: The MES should tune to the LES Signalling Channel and send a Data Report.
(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.
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.
(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
(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 Services[2] =0
(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.
(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
(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.
(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.
(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) 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.
(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.
(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.
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.
(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.
(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.
DNID = 11111
Sub-address =0
Randomising Interval = 00
Response = 01
Command = 02
Sequence No. =1
(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.
(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.
Expected result: The MES may resume the reserved data reporting after receiving the Login ACK and
the correct slot logical channel assignment is used.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
Temperature
4 TEST SET-UP
TEMPERATURE CHAMBER
SYNC
RF
DETECTOR
STORAGE
SCOPE
DTE
CONTROLLER
Figure 6-B
(c) RF detector.
6 TEST PROCEDURE
(a) Connect the simulators and the MES as shown in the TEST SET-UP.
(b) Set the Bulletin Board and the Signalling Channel Descriptors.
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).
(c) Set the Bulletin Board and the Signalling Channel Descriptors:
Randomizing Interval = 1;
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:
(d) Set the Bulletin Board and the Signalling Channel Descriptors:
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):
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:
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:
(f) With the MES in the temperature chamber at 0 deg C set the Bulletin Board and the Signalling
Channel Descriptors:
Randomizing Interval = 1;
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:
(g) With the MES in the temperature chamber at +35 deg C set the Bulletin Board and the
Signalling Channel Descriptors:
Randomizing Interval = 1;
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:
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 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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
NCS/LES
MES
SIMULATOR
DTE
CONTROLLER
Figure 6-C
a. NCS/LES simulator.
6 TEST PROCEDURE
(a) Connect the simulators and the MES as shown in TEST SET-UP. Initialise the set-up.
Randomising Interval = 1;
Signalling Channels = 1;
Slots Available = 1 to 5;
Send an Announcement.
(c) Record the slot number in which the Assignment Response was received.
(e) Repeat steps (b) through (d) for 499 times and calculate the Xe: (i = 1 through 5);
(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;
(Nfi-25)2
Kfi= 25 ;
28
Xf = ∑Kfi ;
i=9
Randomising Interval = 5;
Send an Announcement.
(i) Record the frame in which the second Assignment Response was sent.
(k) Repeat steps (g) through (i) for 99 times and calculate the Xj (i = 9 through 28);
(Nji-20)2
Kji= 20 ;
5
Xj = ∑Kji ;
j=1
7 PASS/FAIL CRITERIA
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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
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.
(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
Part A
Part B
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
Part C
step f. The MES tune to NCS ID 150 and valid Log-in request is transmitted.
step j. The MES tuned to NCS ID 250 and valid Log-in request is transmitted.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
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 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;
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
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.
(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.
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.
6 TEST PROCEDURE
PART A
(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.
PART B
(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.
(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.
(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
(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
(d): the FORCED CLEAR packet shall be transmitted and the transmission of the message
terminated;
(f,g): the FORCED CLEAR packet shall be transmitted and no message or any part of it shall be
available;
(d): The EGC packets received correctly and no From-Mobile message transfer shall have been
initiated;
(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.
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.
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
3 ENVIRONMENTAL CONDITIONS
4 TEST SET-UP
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).
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient
Temperature
Humidity
Power supply
Vibration
4 TEST SET-UP
POWER
SUPPLY
DTE
CONTROLLER
TEMPERATURE CHAMBER/VIBRATION TABLE
Figure 7-B
(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).
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.
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.
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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient
Temperature
Humidity
Vibration
Power Supply
4 TEST SET-UP
POWER
SUPPLY
CONTROLLER DTE
Figure 7-C
(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).
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.
(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
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
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.
(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.
[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
Steps(g): the data in the MES non-volatile memory shall be retained as entered during step (f).
The test shall demonstrate that the mechanical, electrical and circuital characteristics of the interface
DCE - DTE comply respectively with either:
or
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
(a) Multimeter;
(b) Oscilloscope;
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.
Repeat a) through j) under high temperature/high power and low temperature/low power supply
conditions.
Repeat a) through d) under high temperature/high power supply and low temperature/low power supply
conditions.
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.
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
(a) Interface Analyser Test Set capable of displaying the signals exchanged both ways via the
interface in ASCII or Hexadecimal form.
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;
b.1 Enter the NCS common channel frequencies to channel 8000, 8100, 8200 up to channel
14000;
. Preferred OR selected;
. Log-in status;
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.15 Ask for the result of the last PV test (step b.8);
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);
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.
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
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
b. Coupling network
c. Signal generator
d. Power meter
e. Temperature chamber
6 TEST PROCEDURE
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.
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.
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.
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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient
4 TEST SET-UP
NCS/LES MES
SIMULATOR
DTE
CONTROLLER
Figure 9-B
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.
(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.
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.
(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.
(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.
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.
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
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
(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.
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
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
operational. The MES, artificial network and measuring device must be connected to a
common earth (ground) plane.
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.
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.
7 PASS/FAIL CRITERIA
Within the limits shown in SDM Volume 3, Part 2, Chapter 2, figure 4-9.
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
4 TEST SET - UP
VIBRATION TABLE
NCS/LES
SIMULATOR MES
PLOTTER
TRANSDUCER
DTE
CONTROLLER
Figure 11-A
- Vibration Table capable of transmitting to the equipment under test vibration conditions as
specified in Table 1 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 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).
(*) 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.
TABLE 1
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
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
- 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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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
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.1 Place the equipment under test in the environmental test chamber(s) (temperature and
humidity).
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 *.
tr is time it shall take to reach a specified condition (next test environment) from ambient.
x >3 hr >1 hr
>3 hr
Ambient
>3 hr
0ÞC EME 0ÞC
IME
-35ÞC Test
-35ÞC
x >1 hr
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.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).
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).
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.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.8 Repeat steps C.1.1 to C.1.6 for the DTE (if applicable).
(*) 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.
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.
The test shall be carried out by spraying the equipment from all practicable directions with
(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.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.
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:
NCS
7DFFxxxx5020206CFFFFFF03chks
6CF036AE00000000000000chks
SES
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.
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
LES 11:
- ID = 01110;
LES 12:
- ID = 01210;
LES 13:
- ID = 01310;
- out of service;
LES 14:
- ID = 01410;
- operating with a permanent TDM at ch. 232E (f = 1532.515 MHz) on a spare satellite;
LES 15:
- ID = 01510;
- operating with a permanent TDM at ch. 27A4 (f = 1535.370 MHz) on a spare satellite;
- out of service
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.
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.
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.
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.
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.
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
9 TESTING FUNCTIONS
Notes:
A: ambient temperature
T: temperature
H: humidity
P: power
V: vibration
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient
4 TEST SET-UP
NCS/LES SIMULATOR
SES
DEMODULATOR
DATA
ANALYSER DTE
CONTROLLER
Figure S5-C
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
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:
(c) Cause the SES to send a Distress Alert Test packet to the NCS/LES simulator (maritime
protocol). Record the values assumed for:
(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:
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.
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
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 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.
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
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:
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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient
Temperature
Humidity
Power supply
Vibration.
4 TEST SET-UP
POWER
SUPPLY
DTE
CONTROLLER
TEMPERATURE CHAMBER/VIBRATION TABLE
Figure S7-B
(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).
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.
(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
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
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.
(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.
[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
Steps(g): the data in the SES non-volatile memory shall be retained as entered during step (f).
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
NCS/LES SES
SIMULATOR
NAV EQPT
(OPT)
DTE
CONTROLLER
Figure S8-A
6 TEST PROCEDURE
a. Connect the simulators and the SES as shown in S8-A. Tune the NCS/LES simulator and the
SES to channel no. 1100010.
c. Initiate a distress alert transmission and record the packet received at the NCS/LES simulator.
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.
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 :
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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient
Temperature
Humidity
Power supply
Vibration.
4 TEST SET-UP
NCS/LES
SIMULATOR
SES
POWER
REMOTE SUPPLY DTE
CONTROLLER DISTRESS
(OPT)
Figure S8-B
6 TEST PROCEDURE
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.
d. Whilst the message is being transferred, initiate a distress alert transmission and record the
packets received at the NCS/LES simulator.
f. If a remote distress button facility is provided, repeat steps b. through e. initiating the distress
alert transmission from the remote distress button.
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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient
4 TEST SET-UP
NCS/LES SES
SIMULATOR
DTE
CONTROLLER
Figure S9-B
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.
(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.
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.
(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.
(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.
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.
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.
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.
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.
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.
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.
The procedures presented below assume the environmental conditions limits as stated in Volume 3, Part 2,
Chapter 6, Section 11 of the SDM.
A.1 Place the equipment under test in the environmental test chamber(s) (temperature and
humidity).
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)
tr is time it shall take to reach a specified condition (next test environment) from ambient.
x >3 hr >1 hr
+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
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.
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.
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.
5 - 20 Hz [0.005] g2/Hz
20 - 150 Hz -3dB/oct.
[0.5 g rms]
5 - 20 Hz [0.05] g2/Hz
20 - 150 Hz -3 dB/oct.
[1.7 g rms]
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:
performed.
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.
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.
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:
NCS
7DFFxxxx5020206CFFFFFF03chks
6CF036AE00000000000000chks
LMES
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.
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
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
LES 11:
- ID = 01110;
LES 12:
- ID = 01210;
LES 13:
- ID = 01310;
- out of service;
LES 14:
- ID = 01410;
- operating with a permanent TDM at ch. 232E (f = 1532.515 MHz) on a spare satellite;
LES 15:
- ID = 01510;
- operating with a permanent TDM at ch. 27A4 (f = 1535.370 MHz) on a spare satellite;
- out of service
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.
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.
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.
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.
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.
1 ANTENNA TESTS
7 MESSAGE PROCESSING
8 ALERTING FUNCTIONS
9 TESTING FUNCTIONS
T: temperature
H: humidity
P: power
V: vibration
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
6 TEST PROCEDURE
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.
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
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.
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
3 PROCEDURE
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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
Temperature.
Humidity.
Power supply.
4 TEST SET-UP
6 TEST PROCEDURE
(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:
(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.
(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.
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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
Temperature.
Humidity.
Vibration.
4 TEST SET-UP
6 TEST PROCEDURE
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.
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:
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
Temperature.
humidity.
Vibration.
4 TEST SET-UP
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.
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:
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
Temperature
humidity
Vibration
4 TEST SET-UP
NCS/LES CHANNELSI
SIMULATOR MULATOR LMES
SYNC
Figure L4-B
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
(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.
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.1 Received carrier level corresponding to a PFD of -145.5 dBW/m2 at the LMES
antenna*;
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.
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.
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:
-144.5 [36] 2 10
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
Temperature
humidity
Vibration
4 TEST SET-UP
6 TEST PROCEDURE
7 PASS/FAIL CRITERIA
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
Temperature
humidity
Vibration
4 TEST SET-UP
6 TEST PROCEDURE
(a) Connect the simulators and the LMES as shown in figure L4-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.
antenna;
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:
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
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:
6 TEST PROCEDURE
7 PASS/FAIL CRITERIA
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
6 TEST PROCEDURE
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.
c) Repeat as in b), but send the Acknowledgement Packet R+N2 frames later.
Expected result: LMES should repeat the Land Mobile Alert automatically after the timeout
on the NCS Signalling channel:
d) Repeat as in b) and make the transmission of the Land Mobile Alert packet fail.
Expected result: LMES should repeat the Land Mobile Alert MaxC times on the NCS
Signalling channel.
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.
(c) Repeat as in b), but send the Acknowledgement Packet R+N2 frames later.
---
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.
(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/F2/LAND MOBILE - OK
---
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.
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:
(f) Repeat as in e) and send the Acknowledgement Packet from the NCS after R+N2 frames.
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:
Expected result: LMES should repeat the Land Mobile Alert on the NCS signalling channel.
Note any further action of the LMES (ie, operator prompts).
(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.
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.
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 .
.........
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
Expected result: Alert should be received on the general signalling channel and OK.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
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
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
6 TEST PROCEDURE
See Test Item 6-D. However, the NCS only transmit FleetNet EGC in Test Item 6-D, Part B.
(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].
(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.
(j) Check that the LPES tuned to the spot beam NCS 250 and Log-in request was sent.
7 PASS/FAIL CRITERIA
For the LMES,the criteria of the alternative test procedure in Part C shall be as follows:
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
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.
(f) Repeat steps (c) to (d) with the simulator NCS ID 150 (1100010).
(h) Repeat steps (c) to (d) with the simulator NCS ID 244 (1258010).
(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).
(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
step d, j, l The MES should tune to the NCS common channel but not send a log-in packet
automatically;
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.
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
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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient
Temperature
Humidity
Power supply
Vibration
4 TEST SET-UP
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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient
4 TEST SET-UP
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.
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.
(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.
(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.
(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 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.
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
3 ENVIRONMENTAL CONDITIONS
4 TEST SET - UP
-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).
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).
Note:
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).
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
3 ENVIRONMENTAL CONDITIONS
4 TEST SET - UP
- 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.
b) 3 shocks shall be performed on each side (a total of 6 shocks on both sides) under the
following conditions:
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).
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).
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
3 ENVIRONMENTAL CONDITIONS
4 TEST SET-UP
- 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.
7 PASS/FAIL CRITERIA
Step d): the EME shall not reveal any water leaks which might affect the performance of the
equipment.
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.
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.
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.
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.
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.
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
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.
The procedures presented below assume the environmental conditions limits as stated in Volume 3, Part 2,
Chapter 7, Section 11 of the SDM.
A.1 Place the equipment under test in the environmental test chamber(s) (temperature and
humidity).
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.
tr is time it shall take to reach a specified condition (next test environment) from ambient.
x >3 hr >1 hr
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.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).
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 .
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.
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.
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:
NCS
7DFFxxxx5020206CFFFFFF03chks
6CF036AE00000000000000chks
LPES
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.
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
LES 11:
- ID = 01110;
LES 12:
- ID = 01210;
LES 13:
- ID = 01310;
- out of service;
LES 14:
- ID = 01410;
- operating with a permanent TDM at ch. 232E (f = 1532.515 MHz) on a spare satellite;
LES 15:
- ID = 01510;
- operating with a permanent TDM at ch. 27A4 (f = 1535.370 MHz) on a spare satellite;
- out of service
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.
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.
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.
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.
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.
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.
1 ANTENNA TESTS
7 MESSAGE PROCESSING
8 ALERTING FUNCTIONS
9 TESTING FUNCTIONS
10 ELECTROMAGNETIC COMPATIBILITY
T: temperature
H: humidity
P: power
V: vibration
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
6 TEST PROCEDURE
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.
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
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.
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
3 PROCEDURE
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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
Temperature.
Humidity.
4 TEST SET-UP
6 TEST PROCEDURE
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:
1590.0 -70.0
1626.5 -48.0
1646.5 -48.0
In addition that the total radiated power (excluding harmonics) in the following bands should not
exceed the levels specified below:
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
Temperature.
humidity.
4 TEST SET-UP
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:
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
Temperature
humidity
4 TEST SET-UP
6 TEST PROCEDURE
7 PASS/FAIL CRITERIA
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
6 TEST PROCEDURE
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.
c) Repeat as in b), but send the Acknowledgement Packet R+N2 frames later.
Expected result: LPES should repeat the Land Mobile Alert automatically after the timeout on
the NCS Signalling channel:
d) Repeat as in b) and make the transmission of the Land Mobile Alert packet fail.
Expected result: LPES should repeat the Land Mobile Alert MaxC times on the NCS
Signalling channel.
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.
(c) Repeat as in b), but send the Acknowledgement Packet R+N2 frames later.
---
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.
(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/F2/LAND MOBILE - OK
---
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.
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:
(f) Repeat as in e) and send the Acknowledgement Packet from the NCS after R+N2 frames.
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:
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).
(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.
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.
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 .
.........
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
Expected result: Alert should be received on the general signalling channel and OK.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
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
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
6 TEST PROCEDURE
See Test Item 6-D. However, the NCS only transmit FleetNet EGC in Test Item 6-D, Part B.
(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].
(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.
(j) Check that the LPES tuned to the spot beam NCS 250 and Log-in request was sent.
7 PASS/FAIL CRITERIA
For the LPES,the criteria of the alternative test procedure in Part C shall be as follows:
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient.
4 TEST SET-UP
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.
(f) Repeat steps (c) to (d) with the simulator NCS ID 150 (1100010).
(h) Repeat steps (c) to (d) with the simulator NCS ID 244 (1258010).
(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).
(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
step d, j, l The MES should tune to the NCS common channel but not send a log-in packet
automatically;
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.
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
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.
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
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.
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
3 ENVIRONMENTAL CONDITIONS
Normal ambient
4 TEST SET-UP
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.
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.
(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.
(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.
(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 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.
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.
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:
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
elect to implement either a FLEETNET-only or a SAFETYNET-only receiver (see SDM Volume 3, Part 2,
Chapter 6, Section 9).
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.
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.
Procedures for these tests are as stated in the section 2.1 of this document.
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.
1 ANTENNA TESTS
4 MESSAGE PROCESSING
6 ELECTROMAGNETIC COMPATIBILITY
T: temperature
H: humidity
P: power
V: vibration
*: 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
4-C Keyboard X3 X3 X X4
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.
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.
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).
(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
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.
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
4 TEST SET-UP
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).
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
Vibration
4 TEST SET-UP
(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).
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).
(c) Tune the EGC receiver to ch. no.11080 and wait for synchronisation to be achieved.
(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.
(f) Repeat step (d) with vibration in each of the three mutually orthogonal directions.
(g) Repeat step (d) with the relevant power supply variations.
(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.
*Notes:
QBF = THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG 1234567890
RY = RYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRY
7 PASS/FAIL CRITERIA
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
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).
NCS Channels
1 = ch. 11080, 1537.7 MHz (AOR-W); 2 = ch. 12580, 1541.45 MHz (POR);
1 = 11111; 2 = 22222;
3 = 33333; 4 = 44444;
5 = 55555; 6 = 6666;
7 = 7777; 8 = 8888;
9 = 9999; 10 = 10000;
Navarea: 10;
(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:
(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:
[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:
(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:
(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:
(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:
(q) Download new ENIDs until the memory for ENIDs is full.
(r) Allow at least twelve hours to elapse from the last update of the message addressing
information.
7 PASS/FAIL CRITERIA
(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.
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
4 TEST SET-UP
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:
Navtex Code: E, F, G;
(d) Send EGC packets (test messages) with the following Service and Address fields in the
header. Record the results:
(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.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:
f.2 [23H][ID]
[text:11111=abcdefg,9999=hijklmn,54321=opqrstu]
f.4 [33H][ID]
[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]
[text: 11111=abcdefg,9999=hijklmn,54321=opqrstu]
f.8 [33H][ID]
[new 22222]
[text: 22222=vwxjzz]
f.13 [33H][ID]
[delete 22222]
f.18 [33H][ID]
f.22 [33H][ID]
[new 00000]
[Text: 00000=qyqyqyry]
[delete 00000]
f.26 [33H][ID]
[delete 00000]
[New 65535]
[Text: 65535]
f.29 [33H][ID]
[New 65535]
[Text: 65535]
(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]
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]
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]
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]
7 PASS/FAIL CRITERIA
The receiver shall process and output the EGC messages transmitted during the following steps. All
output shall be error free:
The receiver shall disregard the messages transmitted during the following steps:
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.
The algorithm employed to determine whether or not the mobile is within a circular area shall be
stated.
The receiver shall process and output the EGC messages transmitted during the following steps. All
output shall be error-free:
The receiver shall disregard the messages transmitted during the following steps:
The receiver shall register new Closed Network ID's at the following steps:
and disregard the commands to add new Closed Network ID's issued during steps:
The receiver shall delete existing Closed Network ID's at the following steps:
and disregard the commands to delete Closed Network IDs issued during steps:
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.
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
3 ENVIRONMENTAL CONDITIONS
4 TEST SET-UP
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]
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]
e.5 Send an error-free repetition of the same message and record the results.
(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]
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.
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]
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
- 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;
Multi-packet messages
- 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
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
3 ENVIRONMENTAL CONDITIONS
4 TEST SET-UP
(a) Connect the NCS/LES simulator to the EGC receiver antenna port and adjust the level to
nominal.
(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.
(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.
5 PASS/FAIL CRITERIA
The receiver shall process and output the EGC messages transmitted in steps d, e, g, j and l
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
3 ENVIRONMENTAL CONDITIONS
4 TEST SET-UP
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:
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.
7. TEST SIMULATORS
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.
- 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.
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;
- 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.
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.
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.
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.
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
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.
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;
(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.
[This section will contain specifications for the functions of the General Processor in terms of a (simplified)
Inmarsat-C signalling protocol].
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;
- 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.
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.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.
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.
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
- 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.
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.
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.
(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.
(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).
Pass/Fail Criteria
The reciprocal of Interfade Interval and the Fading Duration at each level are:
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).
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.
SCRAMBLER, DTE
B1 1200 SPS CONVOLUTIONAL
BPSK
Inmarsat Confidential
A - RF interconnection point
B1 - B2 IF interconnection points
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
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
Page: 10
(Version Release CD004, CN000)
C SDM
Inmarsat Confidential C SDM
(Version Release CD004, CN000)
8. PHASE II 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).
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:
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:
- 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);
- 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;
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:
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;
iii) Indicate the frame and the slot numbers in which the MES actually sent out the bursts;
v) Show the slot state markers in Signalling Channel Descriptor packet in the expected frame.
i) Download DNID
7D0111110404206C78B20008XXXX BB
69F0300C00000000XXXX SCD
A30D0030394C0108AE008A0101XXXX POLL
7D0111190404204C78B20008XXXX BB
69F0300D20000000XXXX SCD
7D0111200404206C78B20008XXXX BB
69F0300C00000000XXXX SCD
A20F08AE4C2328000240050311310AXXXX POLL
7D0111340404204C78B20008XXXX BB
69F0300D08000000XXXX SCD
7D0111430404204C78B20008XXXX BB
69F0300D02000000XXXX SCD
7D0115450404206C78B20008XXXX BB
69F0300C00000000XXXX SCD
A3130030904C0008AF000105020E1575054303XXXX POLL
7D0115480404204C78B20008XXXX BB
69F0300D08000000XXXX SCD
E2000C08AF4C23280000400206XXXX POLL
7D0115770404204C78B20008XXXX BB
69F0300D00C00000XXXX SCD
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.
Test Item 25-B Alternative Network Service - X.400: From-Mobile Message Transfer
a. Calculate the operating elevation angle (θel) and azimuth (θaz) from the site coordinates
Parameters are:
Assuming that:
∆φ = φMES - φSat
cosβ = cosγ·cos∆φ
l = {R2+(R+H)2-2R(R+H)cosβ}1/2
⎧ (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:
---------------------------------------------------------
"<Location><Date>
This is a test message from MES <ID> undergoing type approval phase 2 tests. Please record.
---------------------------------------------------------
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>
---------------------------------------------------------
"<Location><Date>
This is a distress message for TEST PURPOSES from MES <ID> undergoing type approval phase 2
tests.
---------------------------------------------------------
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.
If the MES has Distress Alert capability, enter/update the Distress Message in the MES as:
NATURE: 0 (unspecified);
COURSE: 0;
SPEED: 0;
h. Turn off the MES and restore the transmitter's functions to normal.
i. The MES is now ready to start Phase II testing. Wait for the scheduled start and proceed with
Test Item 1-A.
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".
---------------------------------------------------------
"<Location><Date>
This is a test message from LES <Name and ID> performing type approval phase 2 tests with MES
<ID>. Please record.
---------------------------------------------------------
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.
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.
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
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;
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:
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.
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.
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:
LES:
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
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.
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.
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.
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:
The Database should indicate that the status of the MES under test is now updated to
"COMMISSIONED".
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
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.
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.
The test will demonstrate that the MES is capable of transferring a pre-formatted message to the LES.
2 APPLICABILITY
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.
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.
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)];
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.
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.
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.
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.
The test shall demonstrate that the MES can both initiate and respond to FORCED CLEAR packets.
2 APPLICABILITY
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.
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.
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.
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.
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.
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.
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;
NATURE: 0 (unspecified);
COURSE: 0;
SPEED: 0;
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.
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.
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.
5 PASS/FAIL CRITERIA
MES:
With reference to the above procedure, no abnormal responses shall have been observed and the
message successfully transferred.
LES:
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).
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
b. After completion of step a. (LOG-OUT ACK received) check the content of the non-volatile
memory via the DTE and record.
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).
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).
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-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.
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
(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.
(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.
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.
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:
FROM: 581492360025
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.
(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.
(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.
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.8 Repeat step b.7 with different DNIDs until the memory is full.
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
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
Navarea =9
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.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.
The test will demonstrate that the MES is capable of sending data reports as specified in SDM Volume
4, Chapter 8.
2 APPLICABILITY
3 TEST PROCEDURE
b. Send the data report to the destinations: DNID-12345 / LES ID-X and DNID-12346 / LES
ID-X respectively.
4 PASS/FAIL CRITERIA
The test will demonstrate that the MES is capable of transmitting the message or data reports as
required in [response] field.
2 APPLICABILITY
3 TEST PROCEDURE
a. Prepare the message and the data report which will be initiated by the polls.
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.
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
3 TEST PROCEDURE
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.
The test will demonstrate that the MES is capable of transmitting the data reports as required by the
poll.
2 APPLICABILITY
3 TEST PROCEDURE
a. Before frame C+80, send the area polls with the following settings:
Command-85
a.2 Repeat step a.1 but DNID is set to 12345 and Command is set to 05.
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.
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.
The test will demonstrate that the MES is capable of stopping unreserved data reports as required by
the polls.
2 APPLICABILITY
3 TEST PROCEDURE
a. After frame C+300, send the area polls with the following settings:
Area-20N033E05005 Command-86
Area-31N032E05005 Command-86
Area-31N032E05005 Command-86
Area-32N034E200 Command-86
4 PASS/FAIL CRITERIA
The MES should ignore the polls in steps a.1 and a.2.
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 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
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:
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.
4 PASS/FAIL CRITERIA
The MES should accept two polls in step a. and start unreserved data reporting.
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.
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
3 TEST PROCEDURE
Duration-2
Duration-20
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.
The test will demonstrate that the MES is capable of transmitting the data reports as required by the
poll.
2 APPLICABILITY
3 TEST PROCEDURE
a. Before frame C+80, send the group polls with the following settings:
Response-01 Command-02
Response-01 Command-02
Response-01 Command-02
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.
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
3 TEST PROCEDURE
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.
The test will demonstrate that the MES is capable of stopping reserved data reports as required by the
polls.
2 APPLICABILITY
3 TEST PROCEDURE
a. After the Reserved Data Reporting resumed, send the area polls with the following settings:
Area-20N033E05005 Command-03
Area-30N033E05005 Command-03
Area-30N033E05005 Command-03
Area-30N033E05005 Command-03
Area-32N034E200 Command-03
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.
The test will demonstrate that the MES complies with the specifications stated in SDM Volume 1,
Chapter 7, Section 3.1.
2 APPLICABILITY
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.
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
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.
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.
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.
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
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;
SECURITY/COVERT ALERT 1;