IMO - MSC 1 - CIR 1294 REV 2 & CIR 1259 REV 4 - 15 fEB 2011 - LONG-RANGE IDENTIFICATION AND TRACKING SYSTEM TECHNICAL DOCUMENTATION PDF

E
4 ALBERT EMBANKMENT
LONDON SE1 7SR
Telephone: +44 (0)20 7735 7611 Fax: +44 (0)20 7587 3210
Ref. T2-OSS/1.4 MSC.1/Circ.1259/Rev.4

15 February 2011
LONG-RANGE IDENTIFICATION AND TRACKING SYSTEM
TECHNICAL DOCUMENTATION
(PART I)
INTERIM REVISED TECHNICAL SPECIFICATIONS FOR THE LRIT SYSTEM

(Version 5)
1 The Maritime Safety Committee (the Committee), at its eighty-eighth session

(24 November to 3 December 2010), considered and approved amendments to the technical
specifications for the LRIT system agreed by the Ad Hoc LRIT Group (the Group) at its ninth
session (MSC 88/26, paragraph 6.14 refers). The present circular incorporates the aforesaid
amendments, as well as the amendments approved by the Committee, at its eighty-sixth session
(27 May to 5 June 2009), regarding a new version of the XML schemas and the entitlement of
Search and Rescue (SAR) services of SOLAS Contracting Governments to request and receive
archived LRIT (MSC 86/26, paragraphs 6.50 and 6.51 refer).
2 The Long-range identification and tracking system Technical documentation (Part I)*
(the Technical specifications) includes:
.1 Technical specifications for the International LRIT Data Exchange;
.2 Technical specifications for the International LRIT Data Centre;
.3 Technical specifications for communications within the LRIT system;
.4 Technical specifications for the LRIT Data Distribution Plan;
.5 Criteria for the location of the International LRIT Data Centre and the
International LRIT Data Exchange; and
.6 XML schemas.
3 The Committee had recognized that, in order to ensure the continuation of the
establishment and the continuous operation of the LRIT system, it might be necessary to
consider and adopt further amendments to the Technical specifications, in particular, in the light
of the results the developmental and integration testing of LRIT Data Centres and during the
operation of the LRIT system. To this end the Committee had established a process for the
*
The Long-range identification and tracking system Technical documentation (Part I) is available in English
only in accordance with the decision of MSC 84.
I:\CIRC\MSC\01\1259-Rev-4.doc
MSC.1/Circ.1259/Rev.4
Page 2
consideration of proposed amendments through correspondence (refer to annex 3 to

MSC.1/Circ.1294/Rev.2 on Long-range identification and tracking system Technical
documentation (Part II)) or by the Group.
4 The XML Schemas set out in the Technical specifications are available in their native
format for downloading from the LRIT Data Distribution Plan server. In addition, those wishing to
receive the XML Schemas in their native format might request them from the Secretariat by
sending an e-mail to LRIT@imo.org.
5 SOLAS Contracting Governments are invited to bring the present circular and its annex
to the attention of those engaged in implementation of the provisions of SOLAS regulation V/19-1
and/or the development, establishment, operation and maintenance of their LRIT Data Centres.
6 The United States, which had established the International LRIT Data Exchange on an
interim basis, is invited to bring the present circular to the attention of those engaged in the
operation and/or maintenance of the International LRIT Data Exchange.
7 Austria, Belgium, Bulgaria, Cyprus, the Czech Republic, Denmark, Estonia, Finland,
France, Germany, Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta,
the Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden and the
United Kingdom (the proposing Contracting Governments), which had submitted a proposal for
the establishment, maintenance and operation of the International LRIT Data Exchange as
from 2011, are invited to bring the present circular to the attention of those engaged in the
8 SOLAS Contracting Governments, LRIT Data Centres acting through SOLAS

Contracting Government(s) which have established them, the International LRIT Data Exchange
acting through the United States or the proposing Contracting Governments, as the case may
be, and the LRIT Coordinator are also invited to bring to the attention of the Committee, at the
earliest opportunity, the results of the experience gained from the use of the technical
specifications set out in annex for consideration of any action to be taken.
9 This circular revokes MSC.1/Circ.1259/Rev.3 issued on 21 May 2010 and any reference
to MSC.1/Circ.1259, MSC.1/Circ.1259/Rev.1, MSC.1/Circ.1259/Rev.2 or MSC.1/Circ.1259/Rev.3
should be read as reference to the present circular.
***
Annex, page 1
ANNEX
(English only)
(PART I)
INTERIM REVISED TECHNICAL SPECIFICATIONS FOR THE LRIT SYSTEM

(Version 5)
1 General provisions
1.1 Scope and background
1.1.1 Scope
1.1.1.1 This document sets out the Technical specifications for the Long-range identification
and tracking system as specified in the Revised performance standards and functional
requirements for the long-range identification and tracking of ships (the Performance standards)
adopted by resolution MSC.263(84).
1.1.1.2 This part provides an overview of the LRIT system and the various specifications are
set out in the following six annexes:
.1 Annex 1 Technical specifications for the International LRIT Data

Exchange;
.2 Annex 2 Technical specifications for the International LRIT Data

Centre;
.3 Annex 3 Technical specifications for communications within the

LRIT system;
.4 Annex 4 Technical specifications for the LRIT Data Distribution Plan;
.5 Annex 5 Criteria for the location of the International LRIT Data Centre
and the International LRIT Data Exchange; and
.6 Annex 6 XML schemas.
1.1.1.3 In preparing the document, account has been taken of the provisions of regulation
V/19-1 of the 1974 SOLAS Convention and of the Performance standards.
1.1.2 Background
1.1.2.1 The Maritime Safety Committee, at its eighty-first session, adopted amendments to
chapter V of the 1974 SOLAS Convention in relation to the long-range identification and tracking
of ships. The amendments entered into force on 1 January 2008 and the LRIT system has been
operations since 00:01 UTC on 31 December 2008.
1.1.2.2 The LRIT system provides for the global identification and tracking of ships which are
required to comply with the provisions of regulation V/19-1.
Annex, page 2
1.1.2.3 In operating the LRIT system, recognition should be given to international

conventions, agreements, rules or standards that provide for the protection of navigational
information.
1.1.2.4 The technical specifications for the International LRIT Data Exchange (IDE), within
the LRIT system, detail the routeing of LRIT information, LRIT request messages and system
messages between LRIT Data Centres (DCs).
1.1.2.5 The International LRIT Data Centre (IDC) is an element of the LRIT system that
receives, stores and disseminates LRIT information on behalf of Contracting Governments to
the 1974 SOLAS Convention. In the context of the LRIT system architecture, technical
specifications International LRIT Data Centre addresses the functional specifications for the IDC.
1.1.2.6 The IDC should be capable of receiving and processing LRIT information from all
ships, other than those that are required to transmit LRIT information to a National (NDC) or
Regional/Co-operative (R/CDC) LRIT Data Centres.
1.1.2.7 The IDC should accommodate any LRIT Data User not participating in a NDC or
R/CDC.
1.1.2.8 The specifications for data security throughout the network and protocols required for
transporting data from one network point to another are described in annex 3 on Technical
specifications for communications within the LRIT system.
1.1.2.9 Communication specifications within the LRIT system detail the messaging format
between LRIT components, data security throughout the network, and the protocols required for
transporting data from one network point to another.
1.2 General description of the system and definitions
1.2.1 LRIT system description
1.2.1.1 As described in Performance standards, the LRIT system consists of the following
components:
.1 the shipborne LRIT information transmitting equipment;
.2 the Communication Service Provider(s);
.3 the Application Service Provider(s);
.4 the DC(s), including any related Vessel Monitoring System(s);
.5 the LRIT Data Distribution Plan server;
.6 the IDE, and
.7 LRIT Data Users.
1.2.1.2 As described in paragraph 1.2 of the Performance standards, certain aspects of the
performance of the LRIT system are reviewed or audited by an LRIT Coordinator acting on
behalf of all Contracting Governments to the 1974 SOLAS Convention (Contracting
Governments).
Annex, page 3
1.2.2 LRIT system operation
1.2.2.1 Paragraphs 1.2.2.1 to 1.2.2.11 provide a high-level overview of the LRIT system
architecture. The Performance standards provide further details on the functions associated with
each component of the system.
1.2.2.2 Tracking of any applicable ship begins with LRIT information being transmitted from
the shipborne equipment. The LRIT information transmitted includes the ship's GNSS position
(based on the WGS84 datum), time and identification, as described in Table 1 of the
Performance standards.
1.2.2.3 The Communication Service Provider (CSP) provides the communication

infrastructure and services that are necessary for establishing a communication path between
the ship and the Application Service Provider (ASP). The LRIT information transmitted from the
ship travels across the communication path set up by the CSP to the ASP.
1.2.2.4 The ASP, after receiving the LRIT information from the ship, adds additional
information to the LRIT message and pass along the expanded message to its associated DC.
Functionality required for the programming and communicating of commands to the shipborne
equipment is provided by the ASP.
1.2.2.5 The LRIT data, along with all the parameters added by the various LRIT
components, is described in the messaging section of annex 3 on Technical specifications for
communications within the LRIT system.
1.2.2.6 DCs should store all incoming LRIT information from ships instructed by their
Administrations to transmit LRIT information to that DC. DCs disseminate LRIT information to
LRIT Data Users according to the LRIT Data Distribution Plan (DDP).
1.2.2.7 The DDP contains the information required by the DCs for determining how LRIT
information is distributed to the various Contracting Governments. The DDP contains
information such as standing orders from Contracting Governments and geographical polygons
relating to Contracting Governments' coastal waters.
1.2.2.8 DCs process all LRIT messages to and from the IDE. The IDE processes all LRIT
messages between DCs. The IDE routes the message to the appropriate DC based upon the
address in the message and the URL/URI in the DDP. The IDE neither processes nor stores the
information contained within LRIT messages.
1.2.2.9 LRIT Data Users might be entitled to receive or request LRIT information in their
capacity as a flag State1, port State2, coastal State3 or Search and Rescue (SAR) service.
1.2.2.10 The LRIT Coordinator assists in the establishment of components of the LRIT
system (namely the IDE and IDC), perform administrative functions, and review and audit the
performance of certain components of the LRIT system.
1.2.2.11 Figure 1 provides a high-level illustration of the basic LRIT system architecture.
1
The term flag State is used for simplicity and refers to the cases when a Contracting Government is requesting
LRIT information pursuant to the provisions of regulation V/19-1.8.1.1.
2
The term port State is used for simplicity and refers to the cases when a Contracting Government is requesting
LRIT information pursuant to the provisions of regulation V/19-1.8.1.2.
3
The term coastal State is used for simplicity and refers to the cases when a Contracting Government is
requesting LRIT information pursuant to the provisions of regulation V/19-1.8.1.3.
Annex, page 4
Figure 1
LRIT system architecture
Contracting Government ... Contracting Government ... Contracting Government ...
flag State flag State flag State

Contracting Government H Contracting Government O Contracting Government W
port State port State port State
Contracting Government G Contracting Government M Contracting Government U
coastal State coastal State coastal State
Contracting Government A Contracting Government
SAR serviceF Contracting Government
SAR serviceN Contracting Government
SAR serviceT The standard for data format, set of
coastal State coastal State coastal State possible commands, security and user
flag State flag State flag State flag State
SAR service SAR service SAR service interface may vary from place to place
coastal State coastal State coastal State
port State port State port State port State
SAR service SAR service SAR service
coastal State coastal State coastal State coastal State
SAR service SAR service SAR service SAR service International
routing
rules
National Regional Cooperative International
LRIT LRIT LRIT LRIT

Data Centre Data Centre Data Centre Data Centre LRIT
or or or or Data Distribution Plan
VMS VMS VMS VMS server
D/B D/B D/B D/B
One standard for data format,

set of commands, security
International LRIT Data Exchange and quality of service
Journal
1.2.3 Definitions
1.2.3.1 Unless expressly provided otherwise:
.1 Convention means the International Convention for the Safety of Life at

Sea, 1974, as amended.
.2 Regulation means a regulation of the Convention.
.3 Chapter means a chapter of the Convention.
.4 LRIT Data User means a Contracting Government or a Search and rescue

service that opts to receive the LRIT information it is entitled to.
.5 Committee means the Maritime Safety Committee.
.6 High-speed craft means a craft as defined in regulation X/1.3.
.7 Mobile offshore drilling unit means a mobile offshore drilling unit as defined
in regulation XI-2/1.1.5.
.8 Organization means the International Maritime Organization.
Annex, page 5
.9 Vessel Monitoring System means a system established by a Contracting

Government or a group of Contracting Governments to monitor the
movements of the ships entitled to fly its or their flag. A Vessel Monitoring
System might also collect from the ships information specified by the
Contracting Government(s) that has established it.
.10 LRIT information means the information specified in regulation V/19-1.5.
.11 IDC Operator means the individual responsible for the daily operation and
maintenance of the International LRIT Data Centre.
.12 IDE Operator means the individual responsible for the daily operation and
maintenance of the International LRIT Data Exchange.
.13 DC Operator means the individual responsible for the daily operation and
maintenance of an LRIT Data Centre.
.14 International Routeing Rules means a list of all DCs with their associated
URL/URI as identified in the DDP.
.15 Contracting Government means a Contracting Government to the

Convention.
.16 Flag State is used for simplicity and refers to the cases when a Contracting
Government is requesting LRIT information pursuant to the provisions of
regulation V/19-1.8.1.1.
.17 Port State is used for simplicity and refers to the cases when a Contracting
Government is requesting LRIT information pursuant to the provisions of
regulation V/19-1.8.1.2.
.18 Coastal State is used for simplicity and refers to the cases when a
Contracting Government is requesting LRIT information pursuant to the
provisions of regulation V/19-1.8.1.3
.19 LRIT Component refers to 1.2.1.1.
1.2.3.2 The term "ship" when used in this document includes mobile offshore drilling units
and high-speed craft as specified in regulation V/19-1.4.1 and means a ship that is required to
transmit LRIT information.
1.2.3.3 Terms not otherwise defined should have the same meaning as the meaning
attributed to them in the Convention.
1.2.4 Acronyms used within this document
1.2.4.1 The acronyms that appear within this document should have the meanings assigned
to them in this paragraph:
.1 ASP Application Service Provider
.2 BIST Built in Self Test
.3 CSP Communication Service Provider
Annex, page 6
.4 DC LRIT Data Centre
.5 DDP LRIT Data Distribution Plan
.6 FAT Factory Acceptance Test
.7 HMAC Hash Message Authentication Code
.8 IDC International LRIT Data Centre
.9 IDE International LRIT Data Exchange
.10 IP Internet Protocol
.11 LES Land Earth Station
.12 LRIT Long-Range Identification and Tracking of ships
.13 MMSI Maritime Mobile Service Identity
.14 NDC National LRIT Data Centre
.15 NOA Notice of Arrival
.16 OASIS Organization for the Advancement of Structured

Information Standards
.17 PKI Public Key Infrastructure
.18 R/CDC Regional/Co-operative LRIT Data Centre
.19 RFP Request for Proposal
.20 SAR Search and Rescue
.21 SAR SURPIC Search and Rescue Surface Picture
.22 SOAP Simple Object Access Protocol
.23 SOLAS International Convention for the Safety of Life at

Sea, 1974
.24 SSL Secure Sockets Layer
.25 TLS Transport Layer Security
.26 VPN Virtual Private Network
.27 VMS Vessel Monitoring System
.28 WS Web Service
Annex, page 7
Annex 1
Technical specifications for the International LRIT Data Exchange
1 Overview
1.1 General provisions
1.1.1 General
1.1.1.1 The technical specification described in this annex should always be read together
with:
.1 regulation V/19-1;
.2 the Revised Performance standards and functional requirements for the

Long-range identification and tracking of ships;
.3 the Technical specifications for communications within the LRIT system;
.4 the Technical specifications for the LRIT Data Distribution Plan; and
.5 the XML schemas.
2 Description of the International LRIT Data Exchange
2.1 Overview
2.1.1 International LRIT Data Exchange
2.1.1.1 The International LRIT Data Exchange (IDE) is a message handling service that
facilitates the exchange of LRIT information amongst DCs to enable LRIT Data Users to obtain
that LRIT information that they are entitled to receive. The IDE routes messages between DCs.
2.1.1.2 The IDE, at a minimum, should be accessible to DCs via standard Internet protocol.
2.1.1.3 The IDE should store and archive message header information in a Journal(s) for
audit, billing and statistical analysis purposes.
2.1.1.4 The IDE does not:
.1 read the LRIT information contained in LRIT messages; and
.2 store or archive any LRIT information.
2.1.1.5 The IDE Operator should not be able to access the LRIT information contained in the
LRIT messages. Further the IDE Operator should not be able to tamper with the contents of the
LRIT messages flowing through the IDE.
2.1.1.6 The application of standing orders and other information contained within the DDP is
a function of individual DCs. The IDE should only read the message header content. The IDE
should not perform any filtering function on the LRIT information.
Annex, page 8
2.1.1.7 As stated in the Performance standards, the message header refers to all
parameters with the exception of the parameters provided by the shipborne equipment.
2.1.1.8 The IDE should use the LRIT ID contained in either the Destination parameter, the
DataUserRequestor parameter or the DataUserProvider parameter included in the messages to
determine where to route the message. The IDE maps the LRIT ID to the URL/URI address of
the DC holding the information using the mappin2 g information contained in the DDP.
3 System architecture/High level design of the IDE
3.1 High level overview of system architecture
3.1.1 General composition of the IDE
3.1.1.1 The general composition (top level block diagram) of the IDE is illustrated in
Figure 1.
Figure 1
Top level block diagram of IDE data flow
Pricing and billing LRIT

(Pricing reports, Coordinator
etc)
Message processing and handling
IDE Operator
IDE
DC administratio
Journal storage
n interface
DC
DC
interface DC Operator
QoS monitoring
(Auditing reports,
etc.)
DC
DDP
Diagnostic tools
interface
DDP
3.1.1.2 The various blocks illustrated in the IDE block diagram represent functional modules
or sub systems of the larger system being the IDE itself.
3.1.1.3 Implementation of the IDE, for example, could consist of a high-speed computer
running IDE specific application software. The IDE application software could consist of various
software modules such as a DC interface module, message processing module, billing module,
Quality of Service (QoS) monitoring module, etc.
Annex, page 9
3.2 DC interface
3.2.1 Functional overview
3.2.1.1 The DC interface of the IDE should:
.1 receive LRIT messages from all DCs participating in the international LRIT
system;
.2 transmit LRIT messages to the appropriate DCs based upon message

processing performed by the IDE;
.3 maintain a secure communication connection to all participating DCs based

upon the communication and data security protocols outlined in annex 3 on
Technical specifications for communications in the LRIT system; and
.4 communicate, through an IP based network, with all DCs.
3.3 Message processing and handling
3.3.1 Message summary
3.3.1.1 Table 1 provides a summary of all LRIT messages (Messages 1-15) and indicates
whether the message is routed between DCs or broadcast to all DCs.
Table 1
Summary of LRIT messages 1
Type Name Description/Purpose TX 2 RX 2 Broadcast

LRIT information (position report) messages
1 Periodic Regular periodic position reports DC2 IDE No
position report
IDE DC1
2 Polled position Position report as a result of a poll DC2 IDE No
report request
IDE DC1
3 SAR position Position report as a result of a SAR DCx IDE No
report request
IDE DC1
LRIT request messages
4 Position To enable a DC to request LRIT DC1 IDE No
request information for ships being monitored
by another DC IDE DC2
5 SAR position To enable a DC to request LRIT DC1 IDE No

request information, as a SAR user, for ships
being monitored by another DC IDE DC2
6 SAR SURPIC SAR request for position of ships in a DC1 IDE Yes
request specific area, broadcast via the IDE to
all DCs IDE DCx
Annex, page 10
Type Name Description/Purpose TX 2 RX 2 Broadcast

Other messages
7 Receipt To enable a LRIT component to DC2 IDE
confirm the processing of a LRIT No
message IDE DC1
DDP DC1
server IDE
DC1 DDP
IDE server
8 DDP Notification that an updated version of DDP IDE Yes
notification the DDP file is available server
IDE DCx
9 DDP request Request for current full copy of the DC1 DDP No
DDP or incremental copy IDE server
10 DDP update This is a routine update of the DDP by DDP DC1 Does not
the DDP server to the IDE server IDE get routed
by the IDE
11 System status To enable the IDE to communicate a IDE DCx
status message every 30 min to each DDP Yes
DC and the DDP server advising that server
the system is "healthy" and receive
status messages from the DCs and DC2 IDE
the DDP server DDP
server
12 Journal Routine monthly, biweekly, weekly or R/CDC1 IDE No
daily message from a R/CDC or the and IDC
IDC to the IDE containing its Journal
13 Pricing Notification that a new pricing list for IDE DCx Yes
notification inter-DC charges is in place
14 Pricing Request for updated pricing list DC1 IDE No
request
15 Pricing update Updated pricing list file DC2 IDE No
IDE DC1
Note:
1
Refer to paragraph 2.2 of the Technical specifications for communications within the
for further information.
2
DC1 = requesting DC; DC2 = providing DC; DCx = all DCs; R/CDC1 = Regional or
Co-operative LRIT Data Centre.
3.3.2 General message processing functions
3.3.2.1 The IDE should have the functional capability to validate the DDP version# contained
in all received LRIT messages against the version number of the DDP it is using. If the IDE
Annex, page 11
detects a mismatch in DDP version numbers, it archives the received message and transmits a
receipt message to the originating DC. It should not route the LRIT message (unless it is a SAR
message) that contained the invalid DDP version #. The ability to enable or disable this function
should be accessible from the IDE administrative interface.
3.3.2.2 The DDP version number checking function should have a time delay feature that
automatically disables the DDP version # checking for a period of time after the IDE has updated
its internal DDP. The period of time in which this function is disabled should be programmable
through the IDE administrative interface.
3.3.2.3 SAR messages (Message types 3, 5, 6, and 7 where ReceiptCode = 1 (no ship in
SAR SURPIC area)) regardless of the DDP version used, should always be routed. The IDE
should also consider as SAR messages (and pass without DDP version checking) message
types 1 and 2 with ResponseType = 4 even though these are not proper message parameter
combinations.
3.3.2.4 The IDE should implement industry standard virus checking and network security
procedures on all messages to prevent malicious attacks (e.g., Structured Query Language
(SQL) injection).
3.3.2.5 The IDE should only perform schema validation on messages addressed to the IDE.
All other messages should be routed to their destinations with only schema validation performed
on parameters used by the IDE for routeing and DDPVersionNum checking.
3.3.2.6 If the destination DC sends a SOAP fault message to the IDE, the IDE should send a
receipt message (Message 7) with the SOAP fault information contained in the Parameter:
Message, Value: Text field to the originating DC.
3.3.3 Generic message handling
3.3.3.1 Section 5 contains message handling and processing diagrams for received LRIT
messages.
3.3.3.2 The following generic process should be followed for all LRIT messages
(Messages 1 to 15) received by the IDE:
.1 perform a DDPVersionNum check, if the function is enabled, by looking at

the DDPVersionNum parameter contained in the message and comparing it
with the current valid DDP version as defined in the Technical
specifications for the LRIT Data Distribution Plan;
.2 LRIT messages that fail the check (mismatch of DDP version #s) should be
archived in the Journal and a receipt message with a receipt code of "9"
should be sent to the DC which transmitted the message;
.3 LRIT messages that pass the check (DDP version #s match) should be
further processed by looking at the MessageType parameter in order to
identify the particular type of LRIT message and handling the message as
detailed in the subsequent paragraphs; and
.4 when connectivity issues occur, attempt redelivery of a message 3 times

in 9 min to a DC.
3.3.3.3 The IDE should handle LRIT messages with the test parameter set to "1" as
described in the following table:
Annex, page 12
Message Type Direction Message Handling action

Message Types 1 to Received The IDE should forward the LRIT message to the intended
6 and Message recipient and journal the message.
Type 7 not
addressed to IDE Sent The recipient component should not process or take any
action in response to the message.
Message Type 7 Received The IDE should journal the message.
Addressed to IDE
Sent The recipient component should not process or take any
Message Type 8 Received Normal the IDE should broadcast to all Data Centres and
DDP Notification journal.
Message Type 9 Sent The recipient component should not process or take any
DDP Request action in response to the message.
DDP Update
System Status
Message Type 12 Received The IDE should not process the message, but should journal
Journal it.
Message Type 13 Sent The recipient component should not process or take any
Pricing Notification action in response to the message.
Message Type 14 Received The IDE should not process the message, but should journal
Pricing Request it. No Pricing Update will be sent to the originating Data
Centre as a result.
Message Type 15 Received The IDE should not process the update but should
Pricing Update broadcast a Pricing Notification, with the test indicator set to
"1" to all Data Centres. The Pricing Update message and all
Pricing Notifications sent should be stored in the journal.
3.3.4 Message handling for Messages 1 to 7
3.3.4.1 The IDE should process LRIT messages with Messages 1 to 7 by:
.1 identifying the message destination (e.g., LRIT Data User, DC) by looking
at the DataUserRequestor parameter for Messages 1 to 3, the
DataUserProvider parameter for Messages 4 to 6 or the Destination
parameter for Message 7;
.2 mapping the LRIT ID associated with the message destination to the

Internet address of the appropriate DC using the mapping information from
the DDP;
Annex, page 13
.3 routeing the LRIT message to the appropriate DC or to all DCs in the case
of broadcast messages (i.e. SAR SURPIC request message);
.4 building a receipt message with a receipt code of 3 and route the receipt
message to the DC associated with the originating LRIT message if the IDE
determines that the DC intended to receive the message is not available
(not on line); and
.5 archiving everything in the messages except for the Shipborne equipment

parameters of messages 1, 2 and 3 as defined in Table 2 of annex 3 on
Technical specifications for communications within the LRIT system.
3.3.5 Message handling for DDP messages (Messages 8 to 10)
3.3.5.1 The IDE should process the DDP messages by:
.1 receiving update notifications for the DDP through the DDP notification
message (Message 8) automatically;
.2 building and transmitting a DDP request message (Message 9) for all

incremental updates (update type 2) of the DDP;
.3 receiving updated incremental DDP files through the DDP update message
(Message 10);
.4 updating the map of Internet addresses for all DCs accordingly; and
.5 archiving all messages in the Journal(s).
3.3.5.2 Additional details concerning the processing of DDP notifications and updates by the
IDE may be found in section 6.
3.3.6 Message handling for System status message (Message 11)
3.3.6.1 The IDE should:
.1 send out a system status message (Message 11) every 30 min to each DC
and the DDP server advising them on the health of the IDE, and archive the
transmitted message in the Journal(s); and
.2 on receipt of a system status message from the DCs and the DDP server,
process all system status messages by updating the system status
(i.e. if no message from a DC or the DDP server, generate a warning to the
IDE Operator), archiving everything in the messages in the Journal(s).
3.3.7 Message handling for R/CDC or IDC issued Journal message (Message 12)
3.3.7.1 The IDE should:
.1 receive and process Journal messages from all R/CDCs and the IDC; and
.2 archive all of the contents of the R/CDC and IDC Journals in the IDE
Journal.
Annex, page 14
3.3.8 Message handling for Pricing messages (Messages 13 to 15)
3.3.8.1 The IDE should process the pricing messages by:
.1 receiving pricing update messages (Message 15) from the DCs;
.2 on receipt of Message 15, sending updated pricing notifications to all DCs

by means of the pricing notification message (Message 13) automatically;
.3 receiving pricing request messages (Message 14) from DCs;
.4 on receipt of Message 14, building and transmitting pricing files through the
pricing update message (Message 15) to the requesting DC(s); and
.5 archiving all messages in the Journal(s).
3.3.8.2 Further to paragraph 0, the IDE should reject a pricing update and send a receipt
message (Message 7) to the originator if:
.1 the attached pricing file fails schema validation; or
.2 the effective date within the pricing file is not a date in the future, as this
would violate pricing data consistency.
3.3.8.3 The pricing update should go into effect at 00:00 UTC of the effective date within the
pricing file.
3.3.8.4 The pricing file contained within the pricing update message from the IDE should
include the pricing lists that are currently in effect or should become effective in the future for all
LRIT Data Users.
3.3.8.5 Each LRIT Data User should have a maximum of one currently effective and one
future effective price list at any given time. A newly received pricing update should supersede
any pending future pricing update for that LRIT Data User.
3.4 DDP interface
3.4.1 General
3.4.1.1 The IDE should maintain a secure communication connection to the DDP server
based upon the communication and data security protocols outlined in annex 3 on Technical
specifications for communications in the LRIT system.
3.5 Quality of service monitoring
3.5.1 Quality reporting
3.5.1.1 The IDE should monitor the communication connections to all DCs and:
.1 respond to quality-related requests from the IDE Operator and the

LRIT Coordinator;
.2 provide, to the LRIT Coordinator, the necessary level of access in order for
the LRIT Coordinator to carry out a performance review and audit of the
IDE performance; and
Annex, page 15
.3 provide sufficient information to the IDE Operator for daily operation at

required levels of reliability, maintenance and availability.
3.5.1.2 The archived LRIT information should provide a complete record of the activities of
the IDE between two consecutive performance reviews and audits of its performance.
3.5.1.3 The IDE should be able to measure quality of service as defined in the Performance
standards.
3.6 IDE administrative interface
3.6.1 General
3.6.1.1 The functionality associated with the IDE interface should provide the LRIT
Coordinator and the IDE Operator with the ability to connect to the IDE and perform simple
administrative tasks based on, but not limited to, the following requirements:
.1 integration and testing of a new DC; and
.2 trouble shooting a connection problem with a DC.
3.6.1.2 The LRIT Coordinator for the purpose of reviewing the performance of the LRIT
system should be given access to the management, charging, technical and operational data of
the IDE via the administrative interface.
3.6.1.3 The communication method used by the LRIT Coordinator and the IDE Operator to
connect to the IDE administrative interface should be over a secure communication link.
3.6.1.4 Notwithstanding paragraph 0, the following three levels of front end access to the
IDE Administrative interface should be provided:
.1 the DC Operator should have limited access so as to be able to query its

share of the Journal for troubleshooting or system management functions.
For this the DC Operator should use a web interface;
.2 the IDE Operator should have unlimited access to the IDE to perform all
required functions, however such access should not allow the IDE Operator
to process, store, or view LRIT information; and
.3 the LRIT Coordinator should have limited access so as to be able to submit

requests to the IDE Operator to bring new DCs on line and to conduct
performance review and audit functions. For this the LRIT Coordinator
should use a web interface.
3.6.1.5 All front end IDE administrative interface accounts should have user accounts using
standard user management/user authentication.
3.6.2 Administrative capabilities
3.6.2.1 The IDE should have the capability to allow external users to connect to the IDE
system and perform the following tasks if the user has been specified within brackets after each
task:
Annex, page 16
.1 Query the Journal for individual LRIT messages (DC Operator,

IDE Operator, LRIT Coordinator):
.1 Journal queries should be filterable by start/end times, message

type, data user, or DC;
.2 Journal queries should be filterable from one DC to other DC and

by referenceID (optional);
.3 Journal query results should be exportable as a CSV file; and
.4 Query results should be set to a limit of 1,500 records;
.2 Query the IDE for a list of all DCs (and their Uniform Resource
Locator/Uniform Resource Identifier (URL/URI) or Internet Protocol
Addresses (IP addresses)) connected to the IDE (IDE Operator);
.3 Query the IDE for network statistics (data rate, dropped packets, etc.) on
specific or all communication links (IDE Operator);
.4 Query the IDE for quality of service information (IDE Operator,

LRIT Coordinator);
.5 Query the IDE for a list of errors or anomalies that the IDE has detected
over a given period of time (IDE Operator);
.6 Query the IDE for the results of a diagnostic test (IDE Operator);
.7 Query the IDE for information pertaining to the LRIT application software on
the IDE (i.e. version number, etc.) (IDE Operator, DC Operator, LRIT
Coordinator);
.8 Query the IDE for the version of the DDP being used (IDE Operator,
DC Operator, LRIT Coordinator);
.9 Enable or disable the DDP version# validity checking function for LRIT
messages from all DCs (IDE Operator);
.10 Configure the time delay feature of the DDP version# checking function
(IDE Operator);
.11 Provide users of the IDE administrative interface with the ability to perform
a technical polygon validation on polygon GML files of the same format
uploaded to the DDP server, as defined in section 4 to the Technical
specifications for the LRIT Data Distribution Plan (IDE operator,
DC operator, LRIT Coordinator);
.12 Query the IDE for Pricing information (IDE operator, DC operator, LRIT
Coordinator):
.1 Pricing file should be downloadable in XML format; and
.2 Pricing history should be selectable by data user;
Annex, page 17
.13 Access general information regarding the LRIT system (IDE operator,
DC operator, LRIT Coordinator) (optional):
.1 IMO hyperlink is available to the IMO Website Home page

(optional);
.2 FAQ information is available for the LRIT system (optional); and
.3 "How To" (help) information is available, including PKI information

(optional);
.14 Access general information regarding the Administrative Interface

(IDE operator, DC operator, LRIT Coordinator):
.1 A means of contacting the IDE Administrative Interface Operator

is available via a "Contact Us" link;
.2 Password administration capabilities are available, including a

resetting password function; and
.3 DDP contacts are able to self administer their login accounts;
.15 Query the IDE for a message count (IDE operator, DC operator,
LRIT Coordinator);
.16 support the functionality described in annex 2 to the annex of

MSC.1/Circ.1294/Rev.2 (Procedures for the notification, reporting and
recording of temporary suspensions of operations or reduction of the
service provided).
3.7 Journal(s)
3.7.1 General
3.7.1.1 In accordance with paragraph 10.3.4 of the Performance standards, the IDE should
automatically maintain Journal(s) containing message header information only, meaning that the
shipborne equipment parameters of messages 1, 2 and 3 as defined in Table 2 of annex 3 on
Technical specifications for communications within the LRIT system should not be stored.
3.7.1.2 The purpose of the Journal(s) is to enable the IDE to trace, record and archive the
identification of all messages routed through the IDE to support:
.1 auditing;
.2 message handling/distribution;
.3 the necessary information required to aid in the resolution of billing

disputes; and
.4 usage and performance statistics.
3.7.1.3 A request for data from the Journal(s) might be made to the IDE Operator by
Contracting Governments, the LRIT Coordinator and DCs.
Annex, page 18
3.7.1.4 The Journal entries should be sent to the requesting entity, specified in paragraph 0,
offline rather than via the LRIT system using standard data storage media (for example CD or
DVD).
3.7.1.5 The requests for Journal information should be actioned by the IDE Operator within 5
working days.
3.7.2 Journal contents
3.7.2.1 The IDE logs all messages relating to the request for LRIT information in a manner
that facilitates the ready identification of individual transactions and provides an audit trail to
identify:
.1 each request message received from individual DCs;
.2 the communications with other DCs; and
.3 the subsequent delivery of the response message to the Requesting DC.
3.7.2.2 In particular, the Journal(s) should include:
.1 TimeStamp of receiving a message;
.2 TimeStamp of transmitting a message; and
.3 The complete message contents except for the Shipborne equipment

parameters of messages 1, 2 and 3 as defined in Table 2 of annex 3 on
Technical specifications for communications within the LRIT system.
3.7.2.3 The format for the Journal is outlined in Table 2.
Table 2
Format for Journal
Parameters Data field

Rx 2 TimeStamp Time 1 of receiving a message
Not available for messages only transmitted by the IDE and not routed
Tx 3 TimeStamp Time 1 of transmitting the message (routeing to the appropriate DC)
Not available for messages only received by the IDE and not routed
Message contents Complete message contents except for the Shipborne equipment
parameters of Messages 1, 2 and 3
Notes:
1
All times should be indicated as Universal Co-ordinated Time (UTC).
2
Receiving.
3
Transmitting.
Annex, page 19
3.7.3 Archiving
3.7.3.1 The IDE should maintain an archive Journal that can accommodate the ready
retrieval of Journal(s) data for at least one year or until such time as the Committee reviews and
accepts the LRIT Coordinator's annual report of the audit of its performance.
3.7.3.2 The archived Journal(s) should provide a complete record of the activities of the IDE
between two consecutive annual audits of its performance.
3.7.3.3 Key requirements for archiving include:
.1 redundancy should include the capability to load balance and cluster

between redundant servers (i.e. hot swap);
.2 resiliency communications should have more than one physical path;
.3 query the data can be retrieved; and
.4 integrity the data is preserved in its original state.
3.8 Diagnostic tools
3.8.1 General
3.8.1.1 Diagnostic tools should be available from the administrator interface of the IDE in
order to allow the testing of the various modules or sub components that make up the IDE.
3.8.2 Diagnostic tool list
3.8.2.1 Network interface check: This test when executed should perform a check on all
network interface connections to verify proper operation. This would include all DC connections,
the IDE administrator interface connection and the DDP connection.
3.8.2.2 Journal storage check: This test should check the read and write function of the
storage space used to hold the Journal.
3.8.2.3 Message handling check: This test should check the message handling function's
ability to properly process different types of messages.
3.8.2.4 General health check: This test should check the general health of IDE
sub-components that are not checked by other tests.
3.8.2.5 Generate LRIT message check: This test should provide the administrative user with
the ability to generate any of the LRIT messages (with the test parameter set to "1") with any
valid parameter value and transmit the message to a connected DC or the DDP server.
Annex, page 20
3.9 Pricing functionality
3.9.1 General
3.9.1.1 The IDE should have the capability of:
.1 receiving pricing files by means of the pricing update message from all
DCs;
.2 compiling a table of all prices and routeing to all DCs; and
.3 archiving to the Journal.
4 IDE system performance
4.1 Overview of IDE system performance
4.1.1 General
4.1.1.1 The IDE should process and handle any input within 30 seconds of the receipt of the
input and should give the appropriate output.
4.1.1.2 The IDE should be capable of receiving and processing at least 100 reports per
second.
4.1.2 Availability and reliability
4.1.2.1 The IDE should provide data to the LRIT system 24 h per day 7 days per week with
better than 99.9% availability measured over a year and better than 95% availability in any one
day.
4.1.3 Maintainability and upgradeability
4.1.3.1 IDE equipment should be so designed that the main units can be replaced readily,
without elaborate re-calibration or readjustment.
4.1.3.2 IDE equipment should be so constructed and installed that it is readily accessible for
inspection and maintenance purposes.
4.1.3.3 IDE software should be capable of being easily upgraded through a standard secure
internet based communication link.
4.1.3.4 The IDE should be designed such that it has the capability to add future features or
functions via software upgrade (for example billing reports managed similar to Internet banking).
5 IDE message handling and processing diagram
5.1 General
5.1.1 Overview
5.1.1.1 Figure 2 provides an illustration of IDE message handling and processing.
Annex, page 21
Figure 2
IDE message handling and processing for received LRIT messages
IDE
received
LRIT message
Compare Archive message but

Build, archive and
Yes DDP version# No do not route received
DDP version# validation transmit
in message DDP version# match? message unless it is
enabled? receipt message to
to IDE a
originating DC
DDP version# SAR message
Yes
No
Look at
Message type `
1 to 3 4 and 5 7 6 8 10 11 12 14 and 15
Process
Process Process Process Process Process Process
Process messages type Process
messages types messages types messages type messages type messages type messages types
messages type 7 6 messages type
1 to 3 4 and 5 8 10 11 14 and 15
Receipt SAR SURPIC 12
LRIT Positional LRIT Request DDP Notification DDP Update System Status Pricing
Message request Journal Message
Messages Messages Message Message Message Messages
Message
Broadcast Check Receive, update

Look at Look at
Look at to all Build and transmit Update System Status Perform and transmit
"LRIT Data User "LRIT Data User
"Destination" connected DCs DDP Request DC IP address list generate warning Journal Functions pricing information
Requestor" Provider"
Message if applicable
Map LRIT ID to
DC IP address
using DDP
Yes DC No
connected to
IDE
Route
Build
message to
Receipt Message
appropriate DC(s)
Route
Receipt Message
to
originating DC
Archive all message header information in the Journal
Annex, page 22
6 IDE handling of DDP notifications and updates
6.1 General
6.1.1 Overview
6.1.1.1 The IDE will function as follows when it receives a DDP notification from the DDP
server:
.1 The IDE verifies that the LRIT ID in the PKI certificate is that of the DDP
server if not, a Receipt, receipt code 7, is generated and no further
processing takes place.
.2 The IDE issues a DDP request to the DDP server for the update.
.3 The IDE forwards the DDP notification to all configured DCs.
.4 The IDE will wait X min for a DDP update to be sent by the DDP server,
where X=15 for an immediate update and X=60 for a regular update.
.5 If no DDP update is received in X min, the IDE will issue another DDP
Request.
.6 The IDE will repeat steps 4 and 5 until within 30 min of when the DDP
version associated with the Notification is to become required. If the DDP
update has not been received by that time, an alarm will be generated to
trigger manual action by the IDE Operator.
.7 The IDE receives the DDP update from the DDP server.
.8 The IDE verifies that the LRIT ID in the PKI certificate is that of the DDP
server if not, a Receipt, receipt code 7, is generated and an alarm will be
generated to trigger manual action by the IDE Operator.
.9 The IDE processes the DDP update, updating its database as required.
6.1.1.2 The process described in paragraph 0 is illustrated in figure 3.
Annex, page 23
Figure 3
IDE handling of DDP notifications and updates flow chart
IDE Receives DDP

Notification
LRIT ID in No
Journal DDP
Certificate matches Send Receipt Journal Receipt
Notification
DDP server?
Yes
Journal DDP
Notification
Send DDP Request

to DDP Server
Journal DDP Request
Forward DDP Notification

to all Data Centres
Journal DDP Notifications

Sent to Data Centres
Wait X minutes
No
DDP No < 30 minutes Yes

Generate Alarm to
Update Until implementation
IDE Operator
Received? deadline?
Yes
Process DDP Update
Journal DDP Update
Annex, page 24
7 DC handling of DDP notifications and updates
7.1 General
7.1.1 Overview
7.1.1.1 The DC will function as follows when it receives a DDP notification from the IDE:
.1 The DC verifies that the LRIT ID in the PKI certificate is that of the IDE if
not, a Receipt, receipt code 7, is generated and no further processing takes
place.
.2 The DC issues a DDP request to the DDP server for the update.
.3 The DC will wait X min for a DDP update to be sent by the DDP server,
where X=15 for an immediate update and X=60 for a regular update.
.4 If no DDP update is received in X min, the DC will issue another DDP

request.
.5 The DC will repeat steps 4 and 5 until within 30 min of when the DDP
version associated with the Notification is to become required. If the DDP
update has not been received by that time, an alarm will be generated to
trigger manual action by the DC Operator.
.6 The DC receives the DDP update from the DDP server.
.7 The DC verifies that the LRIT ID in the PKI certificate is that of the DDP
server if not, a Receipt, receipt code 7, is generated and an alarm will be
generated to trigger manual action by the DC Operator.
.8 The DC processes the DDP update, updating its database as required.
8 IDE handling of pricing update messages
8.1 General
8.1.1 Overview
8.1.1.1 This section provides additional detail with respect to the IDE handling of pricing
update by describing various possible scenarios. The scenarios below describe the processing
logic performed when a pricing update is received by the IDE. In the scenarios, each major tick
mark implies a new day. The price lists have been assigned numbers for the purpose of
identification within the scenarios. These numbers are provided for illustration only and are not
intended to indicate a use of pricing version numbers.
8.1.2 Scenario 1: Price lists become effective at 00:00 UTC of the effective date
8.1.2.1 Price list 1 is issued on 5/1 at 06:00 with an effective date of 5/2. The IDE should
broadcast a pricing notification message (Message 13) to all DCs after processing the pricing
update message (Message 15) successfully. A subsequent pricing request message (Message 14)
received by the IDE should return a pricing update message (Message 15) containing price
lists 0 and 1 along with the current and future pricing lists for all other LRIT Data Users.
Annex, page 25
Figure 4
Scenario 1
P ric e L is t 1
E ff D a te = 5 /2
5 /1 5 /2 5 /3 5 /4 5 /5 5 /6
T im e
PL 0 PL 1
8.1.3 Scenario 2: There can be a maximum of one current and one future price list
per data provider (same effective date as previous price list)
update message (Message 15) successfully.
8.1.3.2 A subsequent pricing request message (Message 14) received by the IDE should
return a pricing update message (Message 15) containing price lists 0 and 2 along with the
current and future price lists for all other LRIT Data Users. Since a maximum of one future price
list is allowed per data provider, price list 2 overrides price list 1. Price list 1 should never
become effective.
Figure 5
Scenario 2
P ric e L is t 2
E ff D a te = 5 /2
5 /1 5 /2 5 /3 5 /4 5 /5 5 /6
T im e
PL 0 PL 2
per data provider (previous future price list is now effective)
current and future price lists for all other LRIT Data Users. Price list 0 is no longer sent because
it is no longer effective. Price list 2 is the current price list and price list 3 is the future price list
for this LRIT Data User.
Annex, page 26
Figure 6
Scenario 3
P ric e L is t 3
E ff D a te = 5 /3
5 /1 5 /2 5 /3 5 /4 5 /5 5 /6
T im e
PL 0 PL 2 PL 3
per data provider (not the same effective date as previous
price list)
current and future price lists for all other LRIT Data Users. Since a maximum of one future price
list is allowed per LRIT Data User, price list 4 overrides price list 3. Price list 3 should never
become effective.
Figure 7
Scenario 4
P ric e L is t 4
E ff D a te = 5 /4
5 /1 5 /2 5 /3 5 /4 5 /5 5 /6
T im e
PL 0 PL 2 PL 4
8.1.6 Scenario 5: Price lists must have an effective date in the future
8.1.6.1 Price list 5 is issued on 5/3 at 06:00 with an effective date of 5/3. Price list 5 should
be rejected by the IDE and a receipt message (Message 7) with a receipt code of 7 should be
sent back to the originator. Price lists take effect at 00:00 UTC of the effective date. 00:00 UTC
of 5/3 is in the past therefore the effective date is invalid. The effective date must be greater
then the current date in order to keep pricing consistent. The pricing notification message
(Message 13) should not be sent to the DCs since the pricing update was rejected.
8.1.6.2 A subsequent pricing request message (Message 14) to the IDE should return a
pricing update message (Message 15) containing price lists 2 and 4 for this LRIT Data User
along with the current and future price lists for all other LRIT Data Users. Price list 0 is no longer
sent since the price list is no longer effective.
Annex, page 27
Figure 8
Scenario 5
P ric e L is t 5
E ff D a te = 5 /3
5 /1 5 /2 5 /3 5 /4 5 /5 5 /6
T im e
PL 0 PL 2 PL 4
Annex, page 28
Annex 2
Technical specifications for the International LRIT Data Centre
(To be updated when an International LRIT Data Centre is to be established)
Annex, page 29
Annex 3
Technical specifications for communications within the LRIT system
1 Overview
1.1 General provisions
1.1.1 General
1.1.1.1 The technical specification described in this annex should always be read together with:
.2 the Revised performance standards and functional requirements for the

long-range identification and tracking of ships;
.3 the Technical specifications for the International LRIT Data Exchange;
.4 the Technical specifications for the LRIT Data Distribution Plan; and
.5 the XML schemas.
2 Communication within the LRIT system
2.1 General
2.1.1 Overview
2.1.1.1 This annex describes communications within the LRIT system.
2.1.2 Message types
2.1.2.1 Communication within the LRIT system is based upon three types of messages
passing between the various LRIT system components: LRIT request messages; LRIT position
report messages; and other system messages.
2.1.2.2 Request messages are those requesting specific LRIT information.
2.1.2.3 LRIT position report messages are those containing LRIT information.
2.1.2.4 Other messages managed by the system include: receipt messages; DDP related
messages, system status messages, Journal related messages and pricing related messages.
2.1.2.5 This annex outlines the parameters associated with each message, as well as the
functional operational flow of the messages within the LRIT system.
2.1.2.6 Each LRIT component (with the exception of the shipborne equipment, which has its
own unique identifier) and each LRIT Data User has its own unique LRIT identifier (LRIT ID) that
enables other components within the LRIT system to identify that particular component or user.
The Organization should manage the list of unique LRIT identifiers (LRIT IDs) and be
responsible for assigning, to the various LRIT system components, their designated LRIT
identifier (LRIT ID) number.
Annex, page 30
2.1.2.7 Figure 1 illustrates the LRIT components (shipborne equipment, CSP Station, CSP,
ASP, DC, Contracting Government, DDP server and the IDE) as well as the various
communications segments (A to F) in the LRIT system. The shaded area represents the
communication paths specified in this annex.
2.1.2.8 The design of communications segments A and B for NDCs and R/CDCs are at the
discretion of the Contracting Governments establishing such DCs. Communication segment A
for the IDC is at the discretion of ASPs and CSPs providing services to the IDC. Section 3 on
Communication protocol strategy provides further detail with respect to the responsibilities of the
various LRIT components with respect to the communications segments.
Figure 1
LRIT communications segments
A D
A A
B NDC C
CSP
CSP(s) ASP
Station(s)
Contracting Government
A A E DDP
A B
C
F IDE
RDC or CDC
CSP E E
CSP(s) ASP
Station(s)
D
C
A IDC
A A B
D
CSP
CSP(s) ASP
Station(s)
2.2 LRIT messaging format summary
2.2.1 Summary of LRIT messages
2.2.1.1 Table 1 provides a summary of all LRIT messages.
Annex, page 31
Table 1
Summary of LRIT messages
Type Name Description/Purpose

LRIT position report messages
1 Periodic position On demand position report1 or pre-scheduled position report2
report containing LRIT information transmitted either at preset intervals3
(i.e. pre-scheduled), or as a result of remote configuration of the
shipborne equipment so as to transmit at an interval other than
the pre-set one (i.e. on demand position report involving remote
configuration), or in response to receipt of a most recent position
request or an archived LRIT information request.
2 Polled position On-demand position report4 containing LRIT information,
report transmitted in response to receipt of a one time poll request, a
most recent position request or an archived LRIT information
request.
3 SAR position report Position report containing LRIT information provided to a SAR
service as a result of a SAR position request or a SAR SURPIC
request.
4 Position request Request by an LRIT Data User (other than SAR service) to: poll
the position of a specific ship (i.e on-demand polling command)5,
request pre-set 6-h reports, change the rate of transmission of
LRIT information by a ship (i.e on demand request to change the
rate of pre-scheduled position reports6), request most recent
position report in the database, request archived LRIT
information or stop or restart receiving LRIT information
transmitted by a given ship.
5 SAR position Request by a SAR service to: poll the position of a specific ship
request (i.e on-demand polling command)5, or request the most recent
position report in the database transmitted by a given ship.
6 SAR SURPIC Request by a SAR service for the provision of the most recent
request position reports already in a DC's database, within a specific
geographical area.
1
Refer to on demand reports as defined in Note (1) in Table 1 of the Performance standards.
2
Refer to pre-scheduled position reports as defined in Note (2) in Table 1 of the Performance standards.
3
Preset intervals are the intervals specified in paragraph 4.4 of the Performance standards.
4
5
6
Annex, page 32
Type Name Description/Purpose

Other messages
7 Receipt Acknowledges receipt of a message that cannot be processed for
some reason
8 DDP notification Advises the IDE and all DCs that a new version of the DDP has
been published and is available for download
9 DDP request Request for a copy of the DDP or for an incremental update
10 DDP update Transmits the requested version of the DDP including archived
ones
11 System status Routine 30-min message from the IDE to all DCs and the DDP
server and from all DCS and the DDP server to the IDE advising
the system status
12 Journal Transmits to the IDE the journals created by an R/CDC or the
IDC when internally routing LRIT information from ships
associated with that R/CDC or the IDC
13 Pricing notification Advises that a new pricing list has been published and is
available for download from the IDE
14 Pricing request Request for a copy of the latest pricing file
15 Update pricing file Transmits the latest pricing file
2.2.1.2 Paragraphs 2.2.2 to 2.2.13 describe each of the LRIT messages. Each message is
presented in tabular format under the following column headings:
.1 Parameter provided by indicates the particular LRIT component that

provides the parameter information contained in the message;
.2 Parameter lists the various parameter names contained within the LRIT
message;
.3 Values lists the potential values of each associated parameter;
.4 Description provides brief information pertaining to each of the various

parameters in the LRIT message;
.5 LRIT segments indicates which of the LRIT communications segments of

Figure 1 contain each parameter; and
.6 Processed format defines the specific format for each parameter.
2.2.1.3 The definition of the various processed formats listed in the Processed format
column of the tables 2 to 13 are provided below. For full schemas for the various processed
formats, reference should be made to annex 6 on XML Schemas.
.1 n - indicates 1 ASCII decimal digit (0-9);
.2 n1nn - indicates 1 to n ASCII decimal digits;
Annex, page 33
.3 c - indicates1 ASCII alphabetic character;
.4 c1cn indicates 1 to n ASCII alphabetic characters;
.5 xs:dateTime - represents a Timestamp: Timestamps used within the LRIT

system are of the XML Schema Datatype dateTime, as defined in
http://www.w3.org/TR/xmlschema-2. The lexical representation of
dateTime consists of finite-length sequences of characters of the form:
'-'? yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)?
Where:
'-'? yyyy is a four-or-more digit optionally negative-signed numeral

that represents the year; if more than four digits, leading zeros are
prohibited, and '0000' is prohibited (note that a plus sign is not
permitted);
the remaining '-'s are separators between parts of the date
portion;
the first mm is a two-digit numeral that represents the month;
dd is a two-digit numeral that represents the day;
'T' is a separator indicating that time-of-day follows;
hh is a two-digit numeral that represents the h; '24' is permitted if
the min and seconds represented are zero, and the dateTime
value so represented is the first instant of the following day (the h
property of a dateTime object in the value space cannot have a
value greater than 23);
':' is a separator between parts of the time-of-day portion;
the second mm is a two-digit numeral that represents the minute;
ss is a two-integer-digit numeral that represents the whole
seconds;
'.' s+ (if present) represents the fractional seconds;
zzzzzz (if present) represents the timezone (as described below).
LRIT timestamps must all be in UTC. An example of a valid timestamp

would be 2009-10-10T12:00:00Z or 2009-10-10T12:00:00.067Z.
.6 TEXT - unformatted alpha numeric text string in the English language.
2.2.1.4 All times in the LRIT system should be indicated as Universal Co-ordinated Time
(UTC) and all time stamps should use UTC with an accuracy of less than or equal to 1 second.
This may be achieved by synchronization with an NTP server (a list of publicly available time
servers can be found on the web site NTP.org) or other technical means.
2.2.1.5 All geographical positions and coordinate points (latitude and longitude) should be
based on the WGS 84 datum.
2.2.1.6 XML data formats will use UTF-8 to encode Unicode characters in the English
language.
2.2.1.7 All DCs should archive all LRIT Messages with the exception of the file attachments
associated with Message 10 (DDP Update) and Message 12 (Journal), in the case or RDC,
CDCs and the IDC, for at least one year and until such time as the Committee reviews and
Annex, page 34
accepts the annual report of the audit of its performance by the LRIT Coordinator. However, the
archived LRIT Messages should provide a complete record of the activities of the centre
between two consecutive annual audits of its performance.
2.2.2 LRIT position report messages (Messages 1, 2 and 3)
2.2.2.1 Table 2 outlines the parameters associated with the LRIT position report messages.
2.2.2.2 NDCs and R/CDCs should format LRIT position reports in a processed format as
specified in table 2 before transmitting them to the IDE. The ship to CSP to ASP to NDC or
R/CDC communication path may transmit LRIT position report messages amongst themselves in
any format that they choose.
2.2.2.3 The ASP to IDC to IDE communication path should transmit LRIT position reports in
a processed format as specified in table 2. The ship to CSP to ASP communication path used
by the IDC may transmit LRIT position report messages amongst themselves in any format that
they choose.
2.2.2.4 The LRIT position messages are intended to provide each of the LRIT Data Users
(other than the SAR service) with the LRIT information pertaining to the ships being tracked by
them and to SAR services related information to enable the search and rescue of persons in
distress at sea.
2.2.2.5 The message header, as stated in the Performance standards, refers to all
parameters with the exception of the parameters provided by the LRIT shipborne equipment
(i.e. the Latitude, Longitude, TimeStamp1, and ShipborneEquipmentId parameters as shown in
Table 2).
2.2.2.6 The parameters provided by the LRIT shipborne equipment include: the Latitude;
Longitude; TimeStamp when the position was generated; and the ShipborneEquipmentId.
2.2.2.7 The processed format of these parameters as outlined in table 2 indicates how the
parameters should be formatted while the information is contained within the message and does
not specify the format of how the shipborne equipment transmits the information.
2.2.2.8 The ASPId parameter is the LRIT ID of the ASP that has received the LRIT
information.
2.2.2.9 The CSPId parameter is the LRIT ID of the CSP that has transmitted the LRIT
information to the ASP. This parameter is optional within the schema.
2.2.2.10 The MessageType parameter indicates the type of the message. LRIT components
such as the DCs should use this parameter to distinguish between the various types of
messages listed in table 1.
2.2.2.11 The MessageId parameter is a unique identification number that LRIT components
should use to identify individual messages within the LRIT system. The MessageId is generated
by linking the LRIT Component ID of the data provider (for segment B from Figure 1, ASPId; for
other segments, Data User ID) the date and time, and a 5 digit unique sequence number
together. An example of a MessageId is 19992007013011552311111 where the LRIT ID of
the LRIT Data User = 1999, year = 2007, month = 01, day = 30, hour = 11, minute = 55,
second = 23, and unique number = 11111.
Annex, page 35
2.2.2.12 The ReferenceId parameter should be either a MessageId of an associated request

message or an empty value. Specifically, for archived requests, the ReferenceId should be the
MessageId of the associated archive request message and not the value as stored. The value is
not populated if the message is not the result of a request message. A valid ReferenceId that is
not an empty value indicates that a request message has initiated the provision of LRIT
information.
2.2.2.13 The IMONum and MMSINum parameters are the IMO ship identification number and
the Maritime Mobile Service Identity (MMSI) of the ship being tracked, respectively.
2.2.2.14 The TimeStamp2 and TimeStamp3 parameters are the date and time associated
with when the ASP received and transmitted the LRIT information message, respectively. Both
TimeStamps should be indicated as Universal Co-ordinated Time (UTC).
2.2.2.15 The DCId parameter is the LRIT ID of the DC receiving the LRIT information.
2.2.2.16 The TimeStamp4 and TimeStamp5 parameters are the date and time associated
with when the DC received and transmitted the LRIT information message, respectively.
2.2.2.17 The ResponseType parameter provides information with respect to why the receiving
LRIT Data User (DataUserRequestor) is receiving the LRIT information. The LRIT Data User's
entitlement to receive the LRIT information is based upon its functioning as: a flag State; a port
State; a coastal State; or a SAR service.
2.2.2.18 The DataUserRequestor parameter is the LRIT ID of the LRIT Data User that is
intended to receive LRIT information as a result of a request message or a standing order. The
IDE should look at this parameter during processing of the message and use it to correctly route
the message to the appropriate DC.
2.2.2.19 The ShipName parameter is the name of the ship in the English language using
UTF-8 encoding and the LATIN-1 character set.
2.2.2.20 The DataUserProvider parameter is the LRIT ID of the LRIT Data User (i.e. the
Administration) associated with that ship.
2.2.2.21 The DDPVersionNum parameter is the version number of the DDP that is being used
by the DC sending the message.
2.2.2.22 The test parameter indicates whether the message is a test message intended for
testing purposes only, or a regular LRIT message.
2.2.2.23 The schemaVersion parameter represents the release number associated with the
set of XML schema files that define the LRIT messages. This parameter is informative only and
no processing action is required by the receiving LRIT component.
Annex, page 36
Table 2
Summary of LRIT position report messages

(Messages 1, 2 and 3)
LRIT system
communication
Parameter segments Processed format
provided by Parameter Values Description (see figure 1) (see paragraph 2.2.1.3)
Shipborne Latitude Latitude GNSS latitude position of ship (based on the B, C, D nn.nn.nn.c
equipment WGS84 datum) in degrees, minutes and
decimal minutes to two decimal places N
(North) /S (South)
Longitude Longitude GNSS longitude position of ship (based on B, C, D nnn.nn.nn.c
the WGS84 datum in degrees, minutes and
decimal minutes to two decimal places E
(East) /W (West)
TimeStamp1 Date and Date and time associated with the GNSS B, C, D xs:dateTime
time position
ShipborneEquipmentId Unique Identifier used by the shipborne equipment B, C, D c1cn
number
ASP 1 or DC ASPId LRIT ID LRIT ID of the ASP that received the LRIT B, C, D nnnn
information
CSPId LRIT ID LRIT ID of the CSP that transmitted the LRIT B, C, D nnnn (optional in the schema)
information
MessageType 1, 2, 3 Message type number: B, C, D nn
1 - Periodic report
2 - Polled report
3 - SAR report
Annex, page 37
LRIT system
communication
MessageId Unique Unique message number generated by using: B, C, D nnnnYYYYMMDDHHmmssnnnnn
number the LRIT Component ID of the data provider
(for segment B from Figure 1, ASPId; for
other segments, Data User ID), date and time
and unique sequence number
ReferenceId Empty, MessageId of associated request message. B, C, D nnnnYYYYMMDDHHmmssnnnnn
MessageId Only valid for a response to a request
message. An empty value indicates the
message is not result of request message
IMONum IMO# IMO ship identification number of the ship B, C, D nnnnnnn
being tracked
MMSINum MMSI# MMSI of the ship being tracked B, C, D nnnnnnnnn
TimeStamp2 Date and Date and time the ASP receives the message B, C, D xs:dateTime
time
TimeStamp3 Date and Date and time the ASP transmits the B, C, D xs:dateTime
time message
DC DCId LRIT ID LRIT ID of the DC receiving the LRIT D, C nnnn
information
TimeStamp4 Date and Date and time when the DC receives the D, C xs:dateTime
time message
TimeStamp5 Date and Date and time when the DC sends the D, C xs:dateTime
time message
ResponseType 1, 2, 3, 4 One of the following values should be added D, C n
by the DC when the message is transmitted:
1 - Coastal
2 - Flag
3 - Port
4 - SAR
Annex, page 38
LRIT system
communication
DataUserRequestor LRIT ID LRIT ID of the LRIT Data User requesting the D, C nnnn
LRIT information as a result of a request
message or a standing order. For a coastal
State the request should be part of the
standing order in the DDP
ShipName Name Name of the ship associated with the LRIT D, C TEXT
information
DataUserProvider LRIT ID LRIT ID of the LRIT Data User (i.e. the D, C nnnn
Administration) associated with that ship
DDPVersionNum Unique DDP version number of the DDP used by a D, C n1...nn:n1...nn
number DC
test 0, 1 Setting indicates if the message is a test D, C n
message or a regular LRIT message:
0 - Regular message
1 - Test message
schemaVersion Decimal The release number of the XML schema D, C n1...nn.n1...nn
number associated with all the LRIT messages
Notes:
1
ASP providing services to the IDC.
Annex, page 39
2.2.3 Position request and SAR position request messages (Messages 4 and 5)
2.2.3.1 Table 3 outlines the parameters associated with the Position request and SAR
position request messages.
2.2.3.2 NDCs and R/CDCs should format Position request and SAR position request
messages as specified in table 3 before transmitting them to the IDE. The LRIT Data User to
NDC or R/CDC communication path may transmit Position request and SAR position request
messages amongst themselves in any format they choose.
2.2.3.3 The LRIT Data User to IDC to IDE communication path should transmit Position
request and SAR position request messages in a processed format as specified in table 3.
2.2.3.4 The LRIT request messages are intended to provide LRIT Data Users with the
ability, inter alia, to poll the position of a specific ships, change the rate of transmission of LRIT
information by a ship, request archived LRIT information or stop receiving LRIT information
transmitted by a given ship.
2.2.3.5 The MessageType parameter indicates the type of the message. The LRIT
components such as the DCs should use this parameter to distinguish between the various
types of messages listed in table 1.
by linking the LRIT ID of the LRIT Data User, the date and time, and a 5 digit unique sequence
number together. The unique sequence number should be generated by the LRIT Data User
and the date and time should be the year, month, day, h, min and second when the parameter
was generated. An example of a MessageId is 19992007013011552322222 where the LRIT ID
of the LRIT Data User = 1999, year = 2007, month = 01, day = 30, h = 11 min = 55, second = 23,
unique sequence number = 22222).
2.2.3.7 The IMONum parameter is the IMO ship identification number of the ship being
tracked.
2.2.3.8 The DataUserProvider parameter is the LRIT ID of the LRIT Data User of the
Administration for that ship. This parameter is used to identify the destination of the request
message. The IDE should look at this parameter during processing of the request message and
use it to correctly route the message to the appropriate DC.
2.2.3.9 The AccessType parameter indicates the requesting LRIT Data User's entitlement to
receive the LRIT information. The LRIT Data User might be requesting the LRIT information as:
a flag State; a port State; a coastal State; or a SAR service. If the AccessType is port State,
then the trigger mechanism should be: a distance from a port, or commence tracking upon
receiving request message, or a specific time. AccessType 0 is used in conjunction with
RequestType 0 in order to restart/reset all previous requests to the referenced ship. The LRIT
Data User issuing the request message with this parameter combination has effectively
cancelled all previous request messages and should only receive LRIT information based upon
standing orders in the DDP for that ship.
2.2.3.10 The Port, PortFacility, or Place parameter should be populated with the UN/LOCODE
code for the port, IMO port facility number of the port facility or a unique code for places under
the jurisdiction of Contracting Governments that the ship is intending to enter. This parameter
should not be present if the request is not a port State request. This parameter is only valid for
AccessTypes 3 and 5.
Annex, page 40
2.2.3.11 The Distance parameter should be the distance in nautical miles from a port or port
facility where the requesting Contracting Government wishes to track the designated ship. This
parameter is only valid when the AccessType parameter is set to 3.
2.2.3.12 The RequestType parameter should indicate whether the request is for: a
restart/reset; a one-time poll; a specified periodic rate ; archived data; most recent position
report; stop tracking; or do not start sending position reports. The do not start sending position
reports message option provides Contracting Governments with the ability to temporarily
override standing orders in the DDP. Consider the scenario where a Contracting Government is
tracking a ship via port State access and does not want to receive LRIT information as a coastal
State. The Contracting Governments could build a request message with coastal for the
"Accesstype parameter and stop / don't start sending for the RequestType. The providing DC,
after receiving such a request message, should not start sending any coastal LRIT information
for the period of time stated in the RequestDuration parameter.
2.2.3.13 The RequestDuration parameter provides information on the start and stop times for
tracking of a ship. If the AccessType is 3, then the RequestDuration and the Distance are both
valid parameters. If the RequestDuration is unspecified, then only the distance from port is valid
for the port State request with distance trigger. The Data User Provider should queue and
continue to process request messages with AccessTypes 3 and 5 and with a valid
RequestDuration until the time expires or the Data User Requester terminates the ship position
request. If the start time is not populated, it will default to the current time. If the stop time is not
populated, it will default to infinity. The start time shall precede the end time. The Request
duration for an archived request should not exceed 30 days.
2.2.3.14 The DataUserRequestor parameter is the LRIT ID of the LRIT Data User originating
the request message. For SAR position requests, the DataUserRequestor parameter should be
populated with an LRIT ID that is associated with a valid SAR service for SAR related messages.
2.2.3.15 The TimeStamp parameter is the date and time associated with the generation of the
message.
by the DC sending the message at the time the message is sent (timestamp5).
testing purposes only or if it is a regular message.
Annex, page 41
Table 3
Summary of Position request and SAR position request messages

(Messages 4 and 5)
LRIT system
Parameter Parameter Value Description communication Processed format
provided by segments (see paragraph 2.2.1.3)
(see figure 1)
LRIT Data MessageType 4, 5 Message type number: B, C, D nn
User 1 4 - Position request
5 - SAR position request
MessageId Unique number Unique message number generated by using: B, C, D nnnnYYYYMMDDHHmmssnnnnn
LRIT ID of the LRIT Data User, date and time and
unique sequence number
IMONum IMO number IMO ship identification number of the ship to be B, C, D nnnnnnn
tracked
DataUserProvider LRIT ID LRIT ID of the LRIT Data User (i.e. the B, C, D nnnn
Administration) associated with that ship
AccessType 0, 1, 2, 3, 4, 5, 6 This parameter should be set based upon the B, C, D n
Data User Requestor's entitlement to receive
LRIT information:
0 - Restart/reset for all entitlements of LRIT
Data User
1 - Coastal
2 - Flag
3 - Port with distance trigger from port or port
facility 2
4 - Reserved for future use
5 - Port with time trigger
6 - SAR (only valid with message type 5)
Annex, page 42
LRIT system
(see figure 1)
Port, PortFacility, or UN/LOCODE, UN/LOCODE code for the port, IMO port B, C, D c1...cn
Place IMO unique port facility number for the port facility, or a unique
facility number, code for places under the jurisdiction of
or place code Contracting Governments that the ship is planning
on entering. Parameter is valid only for
AccessType 3 and 5
Distance nautical miles Distance in nautical miles from the port or port B, C, D nnnn
facility where tracking should commence.
Parameter is only valid for AccessType 3
RequestType 0, 1, 2, 3, 4, 5, Request type5: B, C, D nn
6, 7, 8, 9, 10, 11 0 - Restart/reset 3
1 - One time poll of ship 4
2 - 15 min periodic rate
3 - 30 min periodic rate
4 - 1 h periodic rate
7 - Archived LRIT information request
8 - Stop / don't start sending position reports
9 - Most recent position report
RequestDuration Start time START refers to the time when LRIT position B, C, D xs:dateTime
and/or stop time reports are requested to begin. If not specified, it
defaults to the current time
STOP refers to the end time for receiving LRIT
reports. If not specified, it defaults to infinity
(Contracting Governments might decide to use
repeat polling or periodic rate modification to
obtain variable position report intervals)
Annex, page 43
LRIT system
(see figure 1)
DataUserRequestor LRIT ID LRIT ID of the LRIT Data User originating the B, C, D nnnn
request
TimeStamp Date and time Date and time when an LRIT Data User transmits B, C, D xs:dateTime
the message to its DC
DC DDPVersionNum Unique number DDP version number of the DDP used by the DC D, C n1...nn:n1...nn
test 0, 1 Setting indicates if the message is a test message D, C n
or a regular message
0 - Regular message
1 - Test message
schemaVersion Decimal number The release number of the XML schema D, C n1...nn.n1...nn
associated with all the LRIT messages.
Notes:
1
LRIT Data Users that receive services from the IDC should provide the parameter information listed in the table. The connection between LRIT Data Users
and NDCs or R/CDCs is not specified in this annex and thus the parameter information listed in the table might be provided by the DC.
2
For port with distance trigger (AccessType 3), RequestTypes 1, 7 and 9 are not valid.
3
AccessType 0 and RequestType 0 are only valid with Message 4, and RequestType 0 should only be used with AccessType 0 and vice versa.
4
To make a port State request for a one time poll (RequestType 1), archive LRIT information requests (RequestType 7) or most recent LRIT information
(RequestType 9), AccessType 5 should be used.
5
RequestTypes 1 (one time poll), 7 (archive request) and 9 (most recent position report) are the only valid values for Message 5 (SAR position request).
Annex, page 44
2.2.4 SAR SURPIC request message (Message 6)
2.2.4.1 Table 4 outlines the parameters associated with the SAR SURPIC request message.
2.2.4.2 NDCs and R/CDCs should format the SAR SURPIC message as specified in table 4
before transmitting it to the IDE. The LRIT Data User to NDC or R/CDC communication path
may transmit SAR SURPIC messages amongst themselves in any format that they choose.
2.2.4.3 The LRIT Data User to IDC to IDE communication path should transmit SAR
SURPIC messages in a processed format as specified in table 4.
2.2.4.4 This message requests the most recent LRIT information from the databases within
the DCs. It is intended to provide SAR services with the ability to obtain a picture of the ships in
a given geographical area where search and rescue operations are to be conducted.
by linking the LRIT ID of the LRIT Data User, the date and time, and a 5 digit unique sequence
number together. The unique sequence number should be generated by the LRIT Data User
and the date and time should be the year, month, day, h, min and second when the parameter
was generated. An example of a MessageId is 29992007013021552344444 where the
LRIT ID of the LRIT Data User = 2999, year = 2007, month = 01, day = 30, h = 21, min = 55,
second = 23, and unique sequence number = 44444.
2.2.4.7 The SARCircularArea parameter defines the circular geographical area within which
the SAR service wishes to check for ships. The position of the centre of the circular area should
be indicated by the latitude and longitude on the basis of the WGS 84 datum in degrees and
minutes with North/South (latitude) and East/West (longitude). The radius of the circular area
should be indicated in nautical miles. This parameter is only valid if the parameter is populated
and indicates that the SAR service wishes to perform a search based on a circular area. The
radius of the circular search area should not exceed 999 nautical miles. If a processing DC
encounters a radius of a circular search that is greater than 999 nautical miles then the
processing DC should send a receipt message with receipt code 7 to the requestor.
2.2.4.8 The SARRectangularArea parameter defines the rectangular geographical area

within which the SAR service wishes to check for ships. The rectangular area should be
indicated by the latitude and longitude on the basis of the WGS 84 datum of the southwest
corner of the rectangular area in degrees and minutes with North/South (latitude) and East/West
(longitude), and the north and east offsets are expressed as: degrees.minutes.North and East
from the Southwest corner. This parameter is only valid if the parameter is populated and
indicates that the SAR service wishes to perform a search based on a rectangular area. No side
of the rectangular search area should exceed 2000 nautical miles. If a processing DC
encounters a side of the rectangular area that is greater than 2000 nautical miles then the
processing DC should send a receipt message with receipt code 7 to the requestor.
2.2.4.8.1 If the latitude of the Southwest corner of the rectangular area is 90 degrees North or
South, or if adding the North offset to the latitude of the Southwest corner results in a latitude
of 90 degrees North or South, then the processing DC may, in the course of processing the
request, modify the 90 degree latitude by a maximum of one minute to ensure proper
geospatial processing (i.e. In the maximum allowable modification, the latitude should be set
to 89 degrees 59 minutes).
Annex, page 45
2.2.4.8.2 If adding the North offset to the latitude of the Southwest corner of the rectangular
area results in a latitude of greater than 90 degrees North, then the processing DC should send
a Receipt message with a receipt code of 7 to the requestor. In other words, the rectangular
search area should not cross the North Pole. In situations where a SAR service needs to submit
a SURPIC that crosses either the North Pole or the South Pole, a circular area should be used.
2.2.4.9 The NumberOfPositions parameter defines how many of the most recent position
reports received by a DC during the past 24 h from ships within the requested geographical area
are being requested by the SAR service. The number of positions must be from 1 to 4. Once a
DC has received a SAR SURPIC request message, it should check the last position report it has
on every ship registered to that DC. If the timestamp associated with that position report is
within the past 24 h and the position report is within the geographical area established by the
SAR SURPIC message, then the DC should send the last N position reports associated with the
ship that are within the past 24-h window and in the geographical area. Thus all the position
reports that are sent to the requesting DC should have timestamps that are within the past 24-h
window as well as location co-ordinates that are within the geographical area.
2.2.4.10 The DataUserRequestor parameter is the LRIT Data User originating the request
message. The DataUserRequestor parameter should be populated with an LRIT ID that is
associated with a valid SAR service for SAR related messages.
message.
by the DC sending the message to the IDE for broadcast to all DCs.
Annex, page 46
Table 4
Summary of SAR SURPIC request

(Message 6)
LRIT system
communication
provided by Parameter Value Description (see figure 1) (see paragraph 2.2.1.3)
LRIT Data MessageType 6 Message type number: C, D nn
User 1 6 - SAR SURPIC request
MessageId Unique Unique message number generated by using: C, D nnnnYYYYMMDDHHmmssnnnnn
number LRIT ID of the LRIT Data User, date and time
and unique sequence number
SARCircularArea Centre:Radius Centre of the circular area should be indicated C, D nn.nn.c:nnn.nn.c:nnn
by the latitude and longitude on the basis of
the WGS 84 datum in degrees and minutes
with North/South (latitude) and East / West
(longitude). Radius is the radius of the circle
in nautical miles
SARRectangularArea SouthWest:Off The rectangular area should be indicated by C, D nn.nn.c:nnn.nn.c: nn.nn.N:nnn.nn.E
set the latitude and longitude on the basis of the
WGS 84 datum of the southwest corner of the
rectangular area in degrees and minutes with
North/South (latitude) and East/West
(longitude) and the north and east offsets are
expressed as: degrees.minutes.North and
East from the Southwest corner
NumberOfPositions 1, 2 ,3, 4 The number of position reports received from C, D n
ships within the area during the past 24 h that
the SAR service wishes to receive
DataUserRequestor LRIT ID LRIT ID of the LRIT Data User originating the C, D nnnn
request
Annex, page 47
LRIT system
communication
TimeStamp Date and time Date and time when the LRIT Data User C, D xs:dateTime
transmits the message to the DC
DC DDPVersionNum Unique DDP version number of the DDP used by the C, D n1..nn:n1..nn
number DC
test 0, 1 Setting indicates if the message is a test C, D n
message or a regular message
0 - Regular message
1 - Test message
schemaVersion Decimal The release number of the XML schema C, D n1...nn.n1...nn
Notes:
1
LRIT Data Users that receive services from the IDC should provide the parameter information listed in the table. The connection between LRIT Data Users
and NDCs or R/CDCs is not specified in this annex and thus the parameter information listed in the table might be provided by the DC.
Annex, page 48
2.2.5 Receipt message (Message 7)
2.2.5.1 Table 5 outlines the parameters associated with the Receipt message.
2.2.5.2 The Receipt message should be sent in order to acknowledge the receipt of a
message that cannot be processed for some reason. When an LRIT component receives a
message it should process the message and either send the requested information or send a
Receipt message with the appropriate Receipt code informing the originating LRIT component
why the message could not be processed.
by linking the LRIT ID of the LRIT Component generating the receipt message, the date and
time, and a 5 digit unique sequence number together. An example of a MessageId
is 39992007013012552377777 where the LRIT ID of the LRIT Component = 3999, year = 2007,
month = 01, day = 30, h =12, min = 55, second = 23, unique sequence number = 77777.
2.2.5.5 The ReferenceId parameter is the MessageId of an associated message.
2.2.5.6 The ReceiptCode parameter provides information with respect to the specific Receipt
message that has been generated. In particular:
.1 ReceiptCode 0 Not entitled to data Receipt message should be

generated by a DC when it determines that the requesting LRIT Data User
is not entitled to receive the LRIT information it has requested;
.2 ReceiptCode 1 No ship in SAR SURPIC area should be generated in

response to a SAR SURPIC request message if a DC that is processing a
SAR SURPIC request message determines that there are no ships within
the geographical area specified in the SAR SURPIC request message;
.3 ReceiptCode 2 IDE not available should be generated when the IDE is

not available for any reason. The Receipt message should typically be
generated by a DC in order to indicate that the IDE is off line. A DC is able
to detect this type of error by using the System status message transmitted
from the IDE;
.4 ReceiptCode 3 DC not available should be generated when a DC is not

available. The IDE should be responsible for determining if all DCs are on
line, as indicated by the System status message;
.5 ReceiptCode 4 CSP not available should be generated when a DC has

determined a CSP is off line. The DC is responsible for detecting when the
CSP is not available;
.6 ReceiptCode 5 Ship not responding should be generated by a DC if a

ship that transmits to that DC is not responding. All DCs should be
detecting if ships associated with that DC are transmitting LRIT information
at the preset time intervals. If a LRIT Data User requests LRIT information
from a ship that is not responding, then the DC to which the ship transmits
Annex, page 49
should generate a Receipt message with text content stating how long the
ship has not been responding;
.7 ReceiptCode 6 Ship not available should be generated by a DC when a

request has been made for LRIT information associated with a ship that
should be transmitting to that DC but which has never transmitted
information to the DC;
.8 ReceiptCode 7 System fault should be generated when a fault occurs in

the system that is not covered by the other Receipt Codes;
.9 ReceiptCode 8 Could not load DDP should be generated when a DC or

the IDE is unable to process the received DDP. The message should be
sent to the DDP server; and
.10 ReceiptCode 9 Incorrect DDP version, message discarded should be

generated by the IDE when the DDPVersionNum parameter contained
within the message does not match the DDPVersionNum being used by the
IDE. The IDE should discard the message and build a Receipt message
with the ReferenceId populated with the MessageId of the discarded
message.
2.2.5.7 The Destination parameter is the LRIT ID associated with the LRIT component to
which the receipt message is destined. The value of this parameter should be determined by the
message type of the referenced message (the message indicated by the Reference Id
parameter) as follows:
Type Name Destination parameter

1-3 Position reports LRIT Data User provider
4-5 Position requests LRIT Data User requestor
6 SAR SURPIC request LRIT Data User requestor
7 Receipt Originator
8 DDP notification Destination should always be the DDP server LRIT ID
9 DDP request Originator
10 DDP update Destination should always be the DDP server LRIT ID
11 System Status Originator
12 Journal message Originator
13 Pricing Notification Destination should always be the IDE LRIT ID
14 Pricing Request Originator
15 Pricing Update If the referenced Pricing Update was sent from a DC
to the IDE, the DC's LRIT ID should be used. If the
referenced Pricing Update was sent from the IDE to a
DC, the IDE's LRIT ID should be used.
Annex, page 50
2.2.5.8 The Originator parameter is the LRIT ID of the LRIT component generating the
message. This parameter should be used to identify where the message originated.
2.2.5.9 The Message parameter should contain text providing information in relation to the
nature of the Receipt message.
message.
by the DC sending the message.
Annex, page 51
Table 5
Summary of Receipt message

(Message 7)
LRIT system
communication
DC, IDC MessageType 7 Message type number: B, C, D, E, F nn
ASP, IDE, 7 - Receipt message
DDP server,
LRIT Data MessageId Unique Unique message number generated by using: B, C, D, E, F nnnnYYYYMMDDHHmmssnnnnn
User number LRIT ID of the LRIT component, date and
time and unique sequence number
ReferenceId MessageId MessageId of the associated message that B, C, D, E, F nnnnYYYYMMDDHHmmssnnnnn
of the has been received
associated
message
ReceiptCode 0, 1, 2, 3, 4, 0 - Not entitled to data B, C, D, E, F nn
5, 6, 7, 8, 9 1 - No ships in SAR SURPIC area
2 - IDE not available
3 - DC not available
4 - CSP not available
5 - Ship not responding
6 - Ship not available
7 - System fault
8 - Could not load DDP
9 - Incorrect DDP version, message
discarded
Destination LRIT ID LRIT ID of the intended recipient of the B, C, D, E, F nnnn
message
Originator LRIT ID LRIT ID of the LRIT component generating B, C, D, E, F nnnn
the mesage
Annex, page 52
LRIT system
communication
Message Text Text message indicating the nature of the B, C, D, E, F TEXT
message
TimeStamp Date and Date and time when the LRIT component B, C, D, E, F xs:dateTime
time transmits the message
DDPVersionNum Unique DDP version number of the DDP used by the B, C, D, E, F n1..nn:n1..nn
number LRIT component 1
test 0, 1 Setting indicates if the message is a test B, C, D, E, F n
0 - Regular message
1 - Test message
schemaVersion Decimal The release number of the XML schema B, C, D, E, F n1...nn.n1...nn
Notes:
1
IDE should only add this information if it is the original LRIT component that has built the message.
Annex, page 53
2.2.6 DDP notification message (Message 8)
2.2.6.1 Table 6 outlines the DDP notification message.
2.2.6.2 The DDP notification message should be sent by the DDP server to the IDE, which in
turn should broadcast the message to all DCs. The message is intended to inform the IDE and
all DCs that a new version of the DDP has been published and is available for download.
by linking the LRIT ID of the DDP server, the date and time, and a 5 digit unique sequence
number together. An example of a MessageId is 00012007013012552322222 where the LRIT
ID of the DDP server = 0001, year = 2007, month = 01, day = 30, h = 12, min = 55, second = 23,
and unique sequence number = 22222.
2.2.6.5 The UpdateType parameter indicates the nature of the DDP available on the DDP
server. A value of 0 indicates that a new version of the DDP has been published with updates to
"regular" information in the DDP. A value of 1 indicates that a new version of the DDP has been
published with updates to "immediate" information in the DDP. Further details relating to the
scheduling and priority of implementing the particular DDP available on the server is found in the
Technical specifications for the LRIT Data Distribution Plan.
2.2.6.6 The Message parameter should contain text providing information in relation to the
nature of the message. It may, for example, state that certain Contracting Governments have
updated their standing orders in the DDP and this is the reason why a new DDP is available.
2.2.6.7 The TimeStamp parameter is the date and time when the DDP server transmits the
message.
2.2.6.8 The NewVersionNum parameter is either the regular version number (if UpdateType
is 0) or the immediate version number (if UpdateType is 1) of the new version that is available for
download.
Annex, page 54
Table 6
Summary of DDP notification message

(Message 8)
LRIT system
communication
DDP Server MessageType 8 Message type number: D, F nn
8 - DDP notification
MessageId Unique Unique number generated by using: LRIT ID of D, F nnnnYYYYMMDDHHmmssnnnnn
number the DDP server, date and time and unique
sequence number
UpdateType 0, 1 0 - Regular update D, F n
1 - Immediate update
Message Text Text message indicating the nature of message D, F TEXT
TimeStamp Date and Date and time when the message is transmitted D, F xs:dateTime
time
NewVersionNum Unique Version that is available for download D, F n1...nn
number If UpdateType is 0, the regular version number
of the new version is available for download
If UpdateType is 1, the immediate version
number of the new version is available for
download
test 0, 1 Setting indicates if the message is a test D, F n
0 - Regular message
1 - Test message
schemaVersion Decimal The release number of the XML schema D, F n1...nn.n1...nn
Annex, page 55
2.2.7 DDP request message (Message 9)
2.2.7.1 Table 7 outlines the parameters associated with the DDP request message.
2.2.7.2 The DDP request message should be sent by the IDE and DCs to the DDP server.
The message is intended to inform the DDP server that the LRIT component (IDE or DC)
sending the message is requesting either the full DDP or an incremental update to the DDP.
by linking the LRIT ID of the LRIT Component (IDE or DC), the date and time, and a 5 digit
unique sequence number together. An example of a MessageId is 39992007013023552344444
where the LRIT ID of the LRIT Data Centre = 3999, year = 2007, month = 01, day = 30, h = 23,
min = 55, second = 23, and unique sequence number = 44444.
2.2.7.5 The UpdateType parameter indicates the representation of the DDP being
requested. If the value of UpdateType is 0, the request is for an incremental regular update. If
the value is 1, the request is for an incremental immediate update. If the value is 2, the request
is for all incremental updates. If the value is 3, the current full DDP is requested. If the value
is 4, an archived full DDP is requested. Further details relating to the scheduling and priority of
implementing the particular DDP file available on the server is found in the Technical
specifications for the LRIT Data Distribution Plan.
2.2.7.6 The ArchivedDDPVersionNum parameter indicates the requested archived DDP

version number. This parameter is only used when an archived DDP is being requested (update
type 4). If the ArchivedDDPVersionNum parameter is specified, the ArchivedDDPTimeStamp
should be ignored.
2.2.7.7 The ArchivedDDPTimeStamp parameter is the date and time associated with the full
DDP version that was implemented within the LRIT system at that time. This parameter is only
used when an archived DDP is being requested (UpdateType 4). If the
ArchivedDDPVersionNum is specified, the ArchivedDDPTimeStamp should be ignored
2.2.7.8 The Originator parameter is the LRIT ID number associated with the LRIT
component generating the DDP request message. This parameter is used to identify where the
DDP request message originated.
message.
by the DC or IDE issuing the request for a new DDP.
2.2.7.12 The ReferenceId indicates the MessageId associated with the DDP notification
message that caused the DDP request message to be generated.
Annex, page 56
Table 7
Summary of DDP request message

(Message 9)
LRIT system
communication
IDE or DC MessageType 9 Message type number: E, F nn
9 - DDP request
MessageId Unique Unique message number generated by using: E, F nnnnYYYYMMDDHHmmssnnnnn
number LRIT ID of the LRIT component, date and
time, and unique sequence number
UpdateType 0, 1, 2, 3, 4 0 - Incremental regular update E, F n
1 - Incremental immediate update
2 - All incremental updates (regular and
immediate)
3 - Full DDP
4 - Archived DDP
ArchivedDDP Unique The DDP version number being requested E, F n1nn:n1nn
VersionNum number
Archived Date and The date and time of the version of the E, F xs:dateTime
DDPTimeStamp time archived DDP requested
Originator LRIT ID LRIT ID of the LRIT component generating E, F nnnn
the message
ReferenceId Unique MessageId of the DDP notification message E, F nnnnYYYYMMDDHHmmssnnnnn
number
TimeStamp Date and Date and time when the originator transmits E, F xs:dateTime
time the message
Annex, page 57
LRIT system
communication
DDPVersionNum Unique DDP version number of the DDP used by the E, F n1nn:n1nn
number LRIT component
test 0, 1 Setting indicates if the message is a test E, F n
0 - Regular message
1 - Test message
schemaVersion Decimal The release number of the XML schema E, F n1...nn.n1...nn
Annex, page 58
2.2.8 DDP update message (Message 10)
2.2.8.1 Table 8 outlines the parameters associated with the DDP update message.
2.2.8.2 The DDP update message is sent by the DDP server to the IDE and/or DCs. The
message should contain the requested version of the DDP.
by linking the LRIT ID of the DDP server, the date and time, and a 5 digit unique sequence
number together. An example of a MessageId is 00012007013002552322222 where the LRIT
ID of the DDP server = 0001, year = 2007, month = 01, day = 30, h = 02, min = 55, second = 23,
and unique sequence number = 22222.
2.2.8.5 The ReferenceId indicates the MessageId associated with the DDP request message
that caused the DDP update to be generated.
2.2.8.6 The UpdateType parameter indicates the representation of the DDP being
downloaded. If the value of UpdateType is 0, the update is an incremental regular update. If the
value is 1, the update is an incremental immediate update. If the value is 2, the update contains
all incremental updates. If the value is 3, the current full DDP is provided. If the value is 4, an
archived full DDP is provided. Further details relating to the scheduling and priority of
implementing the particular DDP file available on the server is found in the Technical
specifications for the LRIT Data Distribution Plan.
2.2.8.7 The Message parameter is for the provision of text providing information in relation to
the nature of the message.
2.2.8.8 The TimeStamp parameter is the date and time when the originator transmits the
message.
2.2.8.9 The DDPFile parameter is a file attachment containing either the full DDP or an
incremental update.
2.2.8.10 The DDPFileVersionNum parameter is the version number of the DDP that is being
used by the DDP server.
testing purposes only or if it is a regular LRIT message.
Annex, page 59
Table 8
Summary of DDP update message

(Message 10)
LRIT system
(see figure 1)
DDP server MessageType 10 Message type number: E, F nn
10 - DDP update
MessageId Unique Unique number generated by using: LRIT ID E, F nnnnYYYYMMDDHHmmssnnnnn
number of the DDP server, date and time and unique
sequence number
ReferenceId Unique Unique number generated by using E, F nnnnYYYYMMDDHHmmssnnnnn
number MessageId of the DDP request message
UpdateType 0, 1, 2, 3, 4 0 - Incremental regular update E, F n
1 - Incremental immediate update
2 - All incremental updates (regular and
immediate)
3 - Full DDP
4 - Archived DDP
Message Text Text message indicating the nature of the E, F TEXT
message
TimeStamp Date and Date and time when the message is E, F xs:dateTime
time transmitted
DDPFileVersionNum Unique DDP version number used by the DDP server E, F n1..nn or n1..nn:n1..nn
number
DDPFile attachment Full DDP or an incremental update E, F Refer to DDP schema
Annex, page 60
LRIT system
(see figure 1)
test 0, 1 Setting indicates if the message is a test E, F n
0 - Regular message
1 - Test message
schemaVersion Decimal The release number of the XML schema E, F n1...nn.n1...nn
Annex, page 61
2.2.9 System status message (Message 11)
2.2.9.1 Table 9 outlines the parameters associated with the System status message.
2.2.9..2 The System status message is sent by the IDE to all DCs and the DDP server in
order to provide them with information pertaining to the operational status of the IDE, while the
System status message sent by the DCs or the DDP server to the IDE provide similar
information to the IDE.
by linking the LRIT ID of the LRIT Component (IDE, DC, or DDP server) , the date and time, and
a 5 digit unique sequence number together. An example of a MessageId
is 39992007013015552311111 where the LRIT ID of the LRIT Component = 3999, year = 2007,
month = 01, day = 30, h = 15, min = 55, second = 23, and unique sequence number = 11111.
message.
2.2.9.6 The SystemStatus parameter provides information pertaining to the operational

status of the LRIT component (i.e. the IDE, DC or the DDP server) that transmitted the message.
If the value is 0, then the LRIT component is functioning normally, while a value of 1 indicates
that the component is not adhering to the Performance standards and/or the technical
specifications.
2.2.9.7 The Message parameter is for the provision of text providing information in relation to
the message. It might, for example, state that the IDE Operator has turned off the DDP version
validation function of the IDE due to a catastrophic failure of the DDP server.
message. This parameter is used to identify where the message originated.
by the LRIT component.
Annex, page 62
Table 9
Summary of system status message

(Message 11)
LRIT system
Parameter Parameter Value Description communicatio Processed format
provided by n segments (see paragraph 2.2.1.3)
(see figure 1)
IDE, DC or MessageType 11 Message type number: D, F nn
the DDP 11 - System status
server
MessageId Unique Unique message number generated by using: LRIT ID D, F nnnnYYYYMMDDHHmmssnnnnn
number of the LRIT component, date and time and unique
sequence number
TimeStamp Date and Date and time when the system status message is D, F xs:dateTime
time transmitted
DDPVersionNum Unique DDP version number of the DDP used by the LRIT D, F n1nn:n1nn
number component
SystemStatus 0 or 1 0 - Normal function; D, F n
1 - Not able to provide functionality as described in
the Performance standards and/or the technical
specifications
Message Text Text message indicating the nature of the message D, F TEXT
Originator LRIT ID LRIT ID of the LRIT component D, F nnnn
test 0, 1 Setting indicates if message is a test message or a D, F n
regular message
0 - Regular message
1 - Test message
schemaVersion Decimal The release number of the XML schema associated D, F n1...nn.n1...nn
number with all the LRIT messages
Annex, page 63
2.2.10 Journal message (Message 12)
2.2.10.1 Table 10 outlines the parameters associated with the Journal message.
2.2.10.2 Subject to the provisions of the Performance standards, if the IDC or an R/CDC is
internally routeing LRIT information transmitted to them by ships whose Administration has
determined that they should transmit LRIT information to the IDC or the R/CDC concerned, it
should be creating internal journals for all such transactions, which should then be transmitted
via a Journal message on a defined schedule as agreed upon by the IDE and the IDC and
R/CDCs issuing the Journal message. The frequency of Journal messages should be one of the
following: monthly, biweekly, weekly or daily. Each message should contain a file attachment of
the journals for all of the internally routed LRIT information.
by linking the LRIT ID of the LRIT Data Centre, the date and time, and a 5 digit unique sequence
number together. An example of a MessageId is 39992007013016552333333 where the
LRIT ID of the LRIT Data Centre = 3999, year = 2007, month = 01, day = 30, h = 16, min = 55,
2.2.10.5 The Message parameter is for the provision of text containing information in relation
to the nature of the message.
2.2.10.6 The TimeStamp parameter is the date and time when the originator generated the
message.
message. This parameter should be used to identify where the message originated.
2.2.10.8 The JournalFile parameter is a file attachment containing the journal created by the
DC sending the message.
by the DC.
Annex, page 64
Table 10
Summary of Journal message

(Message 12)
LRIT system
communication
R/CDC or MessageType 12 Message type number: D nn
IDC 12 - Journal
MessageId Unique Unique message number generated by using: D nnnnYYYYMMDDHHmmssnnnnn
number LRIT ID of the DC, date and time, and unique
sequence number
Message Text Text message indicating the nature of the D TEXT
message
TimeStamp Date and Date and time when the message is D xs:dateTime
time transmitted
Orginator LRIT ID LRIT ID of the DC D nnnn
JournalFile attachment File attachment containing the journal created D See paragraph 2.3.10
by the DC
DDPVersionNum Unique DDP version number of the DDP used by the D n1nn:n1nn
number DC
test 0, 1 Setting indicates if message is test message D n
or regular LRIT message
0 - Regular message
1 - Test message
schemaVersion Decimal The release number of the XML schema D n1...nn.n1...nn
Annex, page 65
2.2.11 Pricing notification message (Message 13)
2.2.11.1 Table 11 outlines the parameters associated with the Pricing notification message.
2.2.11.2 The Pricing notification message should be sent from the IDE to all the DCs. The
message is to inform all DCs that a new version of the pricing list has been published and is
available for download.
by linking the LRIT ID of the IDE, the date and time, and a 5 digit unique sequence number
together. An example of a MessageId is 00022007013012552322222 where the LRIT ID of the
IDE = 0002, year = 2007, month = 01, day = 30, h = 12, min = 55, second = 23, and unique
sequence number = 22222.
to the nature of the message. It might, for example, state that a certain DC has updated its
pricing policy and this is the reason why a new pricing list is available for download.
2.2.11.6 The TimeStamp parameter is the date and time when the IDE transmits the
message.
by the IDE.
Annex, page 66
Table 11
Summary of Pricing notification message

(Message 13)
LRIT system
communication
IDE MessageType 13 Message type number: D nn
13 - Pricing notification
number LRIT ID of the IDE, date and time, and unique
sequence number
message
time transmitted
DDPVersionNum Unique DDP version number of the DDP used by the D n1...nn:n1...nn
number IDE
or regular message
0 - Regular message
1 - Test message
Annex, page 67
2.2.12 Pricing request message (Message 14)
2.2.12.1 Table 12 outlines the parameters associated with the Pricing request message.
2.2.12.2 The Pricing request message is sent by a DC to the IDE. The message is intended
to inform the IDE that the DC sending the message is requesting a copy of the latest pricing file.
by linking the LRIT ID of the LRIT Data Centre, the date and time, and a 5 digit unique sequence
number together. An example of a MessageId is 39992007013023552344444 where the
LRIT ID of the LRIT Data Centre = 3999, year = 2007, month = 01, day = 30, h = 23, min = 55,
2.2.12.5 The Originator parameter is the LRIT ID of the DC generating the message. This
parameter is used to identify where the message originated.
message.
by the DC.
2.2.12.9 The ReferenceId parameter indicates the MessageId associated with the pricing
notification message that caused the pricing request message to be generated.
Annex, page 68
Table 12
Summary of pricing request message

(Message 14)
LRIT system
communication
DC MessageType 14 Message type number: D nn
14 - Pricing request
number LRIT ID of the DC, date and time, and unique
sequence number
Originator LRIT ID LRIT ID of the DC D nnnn
time transmitted
DDPVersionNum Unique Current version number of the DDP used by D n1nn:n1nn
number the DC
or regular message
0 - Regular message
1 - Test message
ReferenceId Unique MessageId of the pricing notification D nnnnYYYYMMDDHHmmssnnnnn
number message
number associated with all the LRIT messages.
Annex, page 69
2.2.13 Update pricing file message (Message 15)
2.2.13.1 Table 13 outlines the Update pricing file message.
2.2.13.2 The Update pricing file message is sent directly by the IDE to the DCs or by the DCs
to the IDE. The message should contain the pricing file and should be used by the IDE and DCs
to update their local copies of the pricing file.
by linking the LRIT ID of the LRIT Component (DC or IDE), the date and time, and a 5 digit
unique sequence number together. An example of a MessageId is 39992007013002552322222
where the LRIT ID of the LRIT Component (DC or IDE) = 3999, year = 2007, month = 01,
day = 30, h = 02, min = 55, second = 23, and unique sequence number = 22222.
to the nature of the message.
message.
2.2.13.7 The PricingFile parameter is a file attachment containing either a pricing file from a
DC or the pricing file from the IDE.
by the DC or the IDE.
2.2.13.11 The ReferenceId parameter indicates the MessageId associated with the pricing
request message that caused the pricing update message to be generated.
Annex, page 70
Table 13
Summary of pricing update message

(Message 15)
LRIT system
communication
IDE or DC MessageType 15 Message type number: D nn
15 - Pricing update
number LRIT ID of the IDE or DC, date and time, and
unique sequence number

update message
time transmitted
DDPVersionNum Unique DDP version number of the DDP used by the D n1...nn:n1...nn
number DC or the IDE
PricingFile attachment Updated pricing file D See XML Schemas
test 0, 1 Setting indicates if the message is a test D n
message or a regular message.
0 - Regular message
1 - Test message
number associated with all the LRIT messages.
ReferenceId Unique MessageId of the pricing request message D nnnnYYYYMMDDHHmmssnnnnn
number
Annex, page 71
2.3 Message processing
2.3.1 General
2.3.1.1 All DCs and LRIT components within the LRIT system should process all request
messages and file attachments as described in this section.
2.3.1.2 DCs that receive any LRIT message with the test parameter set to 1 can choose to
either not process the message or perform unique processing in relation to a unique test case
previously agreed with the DC sending the LRIT message.
2.3.1.3 DCs should disregard the DDPVersionNum parameter field when processing any
LRIT message. DDP version number checking is done by the IDE.
2.3.1.4 The IDE should perform schema validation only on messages addressed to the IDE.
If a message fails schema validation then the receiving component should generate and send
either a SOAP fault or a receipt message with receipt code of 7 to the LRIT component that
transmitted the LRIT message with a schema error.
2.3.1.5 All DCs and the DDP server should perform schema validation on all received LRIT
messages. If a message fails schema validation, then the receiving component should generate
and send either a SOAP fault or a receipt message with receipt code of 7 to the LRIT component
that transmitted the LRIT message with a schema error.
2.3.2 DC DDP processing
2.3.2.1 If a DC cannot properly process a DDP file as the result of DDP polygons not being
conformant to the technical specification, then the DC should take the following actions:
.1 Send a receipt message to the DDP server with receipt code 8 (could not
load DDP) as well as a descriptive text message describing the problem.
.2 Contact the IMO Secretariat off line in order to discuss the steps required to
fix the problem.
.3 Perform processing based upon the DDP file but exclude/ignore all
polygons (Custom coastal areas, internal waters, territorial seas, 1000Nm)
of the Contracting Government whose entry contained the error as well as
any of its coastal State standing orders contained in that DDP file.
.4 Update the DDP version number in all messages at the appropriate time
and continue to process as normal.
2.3.2.2 If a DC cannot properly process a DDP file as the result of problems not related to
DDP polygons not being conformant to the technical specification, then the DC should take the
following actions:
load DDP) as well as a descriptive text message describing the problem;
fix the problem. Both the IMO Secretariat and applicable DC should work
to fix the problem as soon as possible;
Annex, page 72
.3 Perform processing based upon the DDP file to the extent possible given
the nature of the problem;
.4 If the DDP update can be processed to the extent that the new DDP
version number can be determined, update the DDP version number in all
messages at the appropriate time and continue to process as normal; and
.5 It is recommended that DC request a Full DDP version after the DDP file
has been corrected.
2.3.2A IDE DDP Processing
2.3.2A.1 If the IDE cannot properly process a DDP file for any reason (recognizing that the
IDE does not validate polygon data beyond XML schema compliance), then the IDE should take
the following actions:
load DDP) as well as a descriptive text message describing the problem;
fix the problem;
.3 Perform processing based upon the DDP file to the extent possible given
the nature of the problem; and
.4 If the DDP update can be processed to the extent that the new DDP
version number can be determined, update the DDP version number in all
messages at the appropriate time and continue to process as normal.
2.3.3 LRIT position report message processing
2.3.3.1 All LRIT position reports received by a DC from ships entitled to fly the flags of a
Contracting Government(s) utilizing that DC (See Figure 1, Communications Segment B) should
be checked against all coastal geographical polygons contained within the DDP in order to
determine if a particular Contracting Government associated with a coastal polygon is entitled to
receive the position report. While checking the entitlement of Contracting Governments to
receive a particular LRIT information, DCs should either use timestamp1 or timestamp4
parameters to determine the DDP version to be utilized.
2.3.3.2 DCs providing a stream of LRIT position reports to another DC at a specific rate may
provide two subsequent position reports that are not spaced in time at the desired reporting rate
(but within the rate) if the ship being tracked by the providing DC is also being tracked by other
LRIT Data Users at different rates. This should be considered normal operation.
2.3.3.3 Figure 2 provides an example where a providing DC is providing another DC with a

stream of position reports that are not all spaced in time at the intended tracking rate due to the
ship being tracked by multiple LRIT Data Users at different rates. The flag, DC C and DC D are
tracking the ship at the default rate of 6 h, while DC A is tracking the ship at a rate of 1 h. The
position report at time 2 1/6 is determined to be within the coastal geographical polygon of
Contracting Government B. Contracting Government B receives this position report and its
second position report is received at time 6 1/6 even though it is intended to receive position
reports at a rate of 6 h.
Annex, page 73
Figure 2
Example of a DC providing another DC with position reports

not all aligned to a given reporting rate
Position report is within
coastal geographical Second position report
First position report provided to DC B (not
polygon of contracting
government B provided to DC B spaced at rate of 6 hrs)
DC B Tracking:
Flag, DC C, DC D
Tracking :
DC A Tracking:
Time: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
2.3.4 Processing of request messages in the context of the DDP polygons
2.3.4.1 All DCs should use the coastal State standing order information contained within the
DDP to determine when to start and stop tracking of a ship in the absence of any specific LRIT
request message. The providing DC establishes entitlement of an LRIT Data User to receive
position reports by performing the following tasks:
.1 check all coastal State standing orders polygons contained in the DDP to
determine if the ship is located within the geographical areas established
by the polygon;
.2 verify that the ship is not located within the internal waters of another
Contracting Government (including non-metropolitan territories or special
administrative regions listed in the DDP under the requesting Contracting
Government) by checking all of the internal waters polygons contained
within the DDP; and
.3 verify that the ship is not located in the territorial sea of the Contracting
Government (including non-metropolitan territories or special administrative
regions listed in the DDP under the requesting Contracting Government)
whose flag the ship is entitled to fly by checking the territorial seas polygon
in the DDP.
2.3.4.2 A providing DC, after receiving a request message with access type set to coastal
and a request type other than type 0 (restart/reset) or 8 (stop/don't start sending), should
perform the following tasks to ensure that the requesting LRIT Data User is entitled to and
should receive the requested information:
.1 verify that V/19-1.9.1 has not been exercised for this coastal state;
.2 check the seaward area of 1000 nm, territorial seas, or internal waters
polygon(s) associated with the requesting LRIT Data User contained in the
DDP to determine if the ship is located within the polygon(s);
.3 verify that the ship associated with the request is not located within the
internal waters of another Contracting Government (including non-
metropolitan territories or special administrative regions listed in the DDP
under the requesting Contracting Government) by checking all of the
internal waters polygons contained within the DDP; and
Annex, page 74
.4 verify that the ship is not located in the territorial sea of the Contracting
Government (including non-metropolitan territories or special administrative
regions listed in the DDP under the requesting Contracting Government)
whose flag the ship is entitled to fly by checking the territorial seas polygon
in the DDP.
2.3.4.3 A request message with access type set to coastal will override the coastal State
standing orders associated with the custom coastal State areas polygon in the DDP. Example:
Contracting Government A has started receiving position reports associated with ship X as a
result of coastal State standing orders in the DDP (custom coastal State area polygon).
Contracting Government A sends the providing DC a request message with access type set to
coastal, reporting rate of 1 h and a request duration equivalent to 2 days. The providing DC
should send Contracting Government A position reports associated with the ship for the
specified request duration of 2 days at a 1 h rate as long as the ship is within Contracting
Government A's seaward area of 1000 nm, territorial seas, or internal waters polygons.
2.3.4.4 A providing DC, after receiving a request for archived information, should perform the
same tasks as designated for the request message with access type set to coastal in order to
determine if the requestor is entitled to receive the information. However, the providing DC
should use the seaward area of 1000 nm polygons, internal waters polygons, and territorial seas
polygons associated with the DDP that was active during the time the position reports were
transmitted in order to determine if a requesting LRIT Data User is entitled to receive the
archived information.
2.3.4.5 A providing DC, after receiving a request message with access type set to port,
should check all the internal waters polygons (including internal waters polygons associated with
non-metropolitan territories or special administrative regions listed in the DDP under the
requesting Contracting Government) in the DDP to verify that the ship being tracked is not in the
internal waters of another Contracting Government (or non-metropolitan territory or special
administrative region even if they are listed, in the DDP, under the requesting Contract
Government) before sending the position reports to the requesting LRIT Data User. Refer to
table 15 for additional details. The port state request message is suspended while the ship is
located in the internal waters of another contracting government. When the ship exits the
internal waters, the providing DC will reactivate sending position reports to the requestor at a rate
that is the same or less frequent than the reporting rate specified by the port state request message.
The requestor may have to send another port state request message in order to receive position
reports at the reporting rate specified by the original port State request message.
2.3.4.6 When comparing the location of the ship against geographical polygons and other
locations contained within the DDP, DCs should use an industry-standard GIS software
application, or a custom-coded solution that implements well-established computational
geometric algorithms. These different industry standard GIS tools include, but are not limited to,
Oracle Spatial, SQL Server Spatial, PostGIS, ESRI, etc., and/or custom-coded solutions which
utilize different computational geometric algorithms/methodologies. The most commonly used
methodologies/algorithms that exist are Great Circle, Ellipsoidal and Rhumb line. For example
Oracle Spatial uses Ellipsoidal methodology which is similar to Great Circle, with one significant
difference. Rather than assuming a spherical Earth, ellipsoidal logic is based on a Reference
Ellipsoid (a mathematical model of the Earth that takes into account the flattening that occurs at
the Poles).
2.3.4.7 Given the different geometric algorithms/methodologies, when DCs process LRIT
position reports there may on occasion be legitimate technical differences between LRIT
components when determining which Contracting Governments are entitled to a particular ship
position.
Annex, page 75
2.3.5 General processing of position request (Message type 4), SAR position
request (Message type 5) and SAR SURPIC message (Message type 6)
2.3.5.1 DCs should respond to position request messages (Message type 4), SAR position
request messages (Message type 5) and SAR SURPIC messages (Message type 6) with valid
LRIT position report messages (Message types 1, 2 and 3) as listed in table 14.
Table 14
Operational scenarios that terminate, suspend or modify a request message
Position Request SAR Position Request SAR

Message Message SURPIC Coastal
MT 4 MT 5 MT 6 State
Access Type Access Type - Standing
1 3-5 6 1 3-5 6 Order
-
Coastal Port SAR Coastal Port SAR
1 Not Not Not Not Not Not
VALID1 VALID
Coastal valid valid valid valid valid valid
MT 3 Not Not Not Not Not Not Not valid
VALID2
valid valid valid valid valid valid
LRIT Position Report Message
1 Port
4 Not Not Not Not Not Not Not Not valid
SAR valid valid valid valid valid valid valid
Response Type
1 Not Not Not Not Not Not Not valid

VALID3
Coastal valid valid valid valid valid valid
MT 3 Not Not Not Not Not Not Not valid
VALID4
2 Port valid valid valid valid valid valid
SAR valid valid valid valid valid valid valid
Coastal valid valid valid valid valid valid valid
MT 3 Not Not Not Not Not Not Not Not valid
3 Port valid valid valid valid valid valid valid
4 Not Not Not Not Not Not valid
VALID5 VALID
SAR valid valid valid valid valid
1
Only valid for Position Request Message with Access Type 1 and Request Type parameter 2-7, 9,
10 or 11.
2
Only valid for Position Request Message with Access Type 3-5 and Request Type parameter 2-7, 9,
10 or 11.
3
Only valid for Position Request Message with Access Type 1 and Request Type parameter 1, 7 or 9.
4
Only valid for Position Request Message with Access Type 3-5 and Request Type parameter 1, 7 or 9.
5
Only valid for SAR Position Request with Access Type 6 and Request Type parameters 1 and 9.
2.3.5.2 DCs that are complying with an existing LRIT request message for LRIT information
on a particular ship should terminate the existing request message or suspend sending position
report messages to the requestor if certain operational scenarios occur. Table 15 provides
details on the events that would result in a processing DC terminating an existing request
message or suspending of position reports. It also stipulates if a receipt message should be
generated as well as indicating the particular receipt code that is required when a receipt
message is necessary.
Annex, page 76
Table 15
Operational scenarios that terminate, suspend or modify a request message
Existing request Receipt Receipt

message Event Action by processing DC message code
DC is complying with The current processing time matches or is later than the Existing request message terminates. No N/A
a request message "stop" field associated with the "request duration" parameter Return to coastal State standing orders
with the following in the existing request message (request expires) reporting
parameters:
Message Type: 4 Ship reports a location that is NOT within the area of coastal Existing request message terminates. Yes 0
Access Type: 1 State entitlement of the requesting Contracting Government Return to coastal State standing orders (not entitled
Request Types: (1000 nm, territorial seas, or internal waters) at some point in reporting to data)
2, 3, 4, 5, 6, 10 time during the request duration period
or 11. Ship reports a location that is within the area of coastal State Existing request message terminates. Yes 0
entitlement of the requesting Contracting Government (1000 Return to coastal State standing orders (not entitled
(coastal State nm, territorial seas, or internal waters) but is located within reporting to data)
request with periodic the internal waters of another Contracting Government, or
reporting) within the territorial sea of the Contracting Government
whose flag the ship is entitled to fly
Requesting Contracting Government sends a new request Existing request message terminates. No N/A
message (Message Type 4, Access Type 1, Request Type Return to coastal State standing orders
8) for the same ship associated with the existing request reporting
message
message (Message Type 4, Access Type 1, Request Type New request message starts with
2, 3, 4, 5, 6, 10, or 11) for the same ship associated with the desired reporting rate
existing request message (A single Contracting Government can
only have one active coastal State request
on each ship at a time)
message (Message Type 4, Access Type 0, Request Type 0) Return to coastal State standing orders
for the same ship associated with the existing request reporting
message
Annex, page 77

DC is complying with The current processing time matches or is later than the Existing "stop" request message No
a request message "stop" field associated with the "request duration" parameter terminates
with the following in the existing request message (request expires) Return to coastal State standing orders
parameters: reporting
Message Type 4,
Access Type 1, Requesting Contracting Government sends a new request Existing "stop" request message No
Request Type 8 message (Message Type 4, Access Type 0, Request terminates
(coastal state Type 0) for the same ship associated with the existing Return to coastal State standing orders
request for request message reporting
"stop/don't start Requesting Contracting Government sends a new request Existing "stop" request message No
sending positions") message (Message Type 4, Access Type 1, Request terminates
Type 2, 3, 4, 5, 6, 10 or 11) ) for the same ship associated New request message starts with
with the existing request message desired reporting rate
Requesting Contracting Government sends a new request The Existing "Stop Request" message No
(message type 4, Access type 1, Request type 8) for the terminates
same ship associated with the existing request message The new request becomes the valid
one
DC is complying with The current processing time matches or is later than the Existing request message terminates No N/A
a request message "stop" field associated with the "request duration" parameter
with the following in the existing request message (request expires)
parameters:
Message Type 4, Requesting Contracting Government sends a new request Existing request message terminates No N/A
Access Type 3, message (Message Type 4, Access Type 0, Request
Request Types: 2, Type 0) for the same ship associated with the existing
3, 4, 5, 6, 10 or 11 request message
Requesting Contracting Government sends a new request Existing request message terminates No N/A
(port State request message (Message Type 4, Access Type 3 or 5, the same New request message starts with
with distance trigger port, port facility, or place and Request Type 2,3,4,5,6,10, desired reporting rate
with periodic or 11) for the same ship associated with the existing request (A single Contracting Government can
reporting) message only have one active port State request
per port, port facility or place on each ship
at a time)
Annex, page 78

message (Message Type 4, Access Type 3 or 5, the same
port, port facility, or place and Request Type 8) for the same
ship associated with the existing request message
Ship reports a location that is within the internal waters of a Reporting is temporarily suspended for Yes (only one 0
Contracting Government other than the one that sent the existing request until the ship leaves receipt message (not entitled
request the internal waters of the other at the beginning to data)
Contracting Government of the temporary
May choose to adjust the reporting rate suspension
of the ship's terminal period)
During a period in which reporting has been temporarily Reporting is reactivated with a reporting No N/A
suspended for the existing request, the ship reports a rate that is the same or less frequent
location that is not within the internal waters of the other than the reporting rate specified by the
Contracting Government port state request message
DC is complying with The current processing time matches or is later than the Existing request message terminates No N/A
a request message "stop" field associated with the "request duration" parameter
with the following in the existing request message (request expires)
parameters:
Message Type 4, Requesting Contracting Government sends a new request Existing request message terminates No N/A
Access Type 5, message (Message Type 4, Access Type 0, Request
Request Types: 2, Type 0) for the same ship associated with the existing
3, 4, 5, 6, 10 or 11 request message
(port State Request Requesting Contracting Government sends a new request Existing request message terminates No N/A
with time trigger with message (Message Type 4, Access Type 3 or 5, the same New request message starts with
periodic reporting) port, port facility, or place and Request Type 2,3,4,5,6,10, desired reporting rate
or 11) for the same ship associated with the existing request (A single Contracting Government can
message only have one active port State request
per port, port facility or place on each ship
at a time)
Annex, page 79

message (Message Type 4, Access Type 3 or 5, the same
port, port facility, or place and Request Type 8) for the same
ship associated with the existing request message
Ship reports a location that is within the internal waters of a Reporting is temporarily suspended for Yes (only one 0
Contracting Government other than the one that sent the existing request until the ship leaves receipt message (not entitled
request the internal waters of the other at the beginning to data)
Contracting Government of the temporary
May choose to adjust the reporting rate suspension
of the ship's terminal. period)
During a period in which reporting has been temporarily Reporting is reactivated with a reporting No N/A
suspended for the existing request, the ship reports a rate that is the same or less frequent
location that is not within the internal waters of the other than the reporting rate specified by the
Contracting Government port state request message
Annex, page 80
2.3.5.3 DCs have the option of processing the DataUserRequestor parameter of the SAR
Position Request message in order to determine if the requestor is a SAR service entitled to
receive the information requested. If a DC chooses to check the validity of a requestor than it
should check the LRIT ID contained in the DataUserRequestor parameter against SAR service
LRIT IDs in the DDP. If a DC chooses to reject a SAR Position request message based upon
the LRIT ID in the DataUserRequestor parameter than the DC should send a receipt message
with receipt code 0 (not entitled to data) to the requestor.
2.3.5.4 The SARCircularArea and SARRectangularArea parameters should not be

populated in the same SAR SURPIC request message. If both parameters are populated, then
the providing DC should ignore the contents of the SARRectangularArea parameter and use the
contents of the SARCircularArea parameter in responding to the SAR SURPIC request
message.
2.3.5.5 DCs have the option of processing the DataUserRequestor parameter of the SAR
SURPIC message in order to determine if the requestor is a SAR service entitled to receive the
information requested. If a DC chooses to check the validity of a requestor then it should check
the LRIT ID contained in the DataUserRequestor parameter against the SAR service LRIT IDs in
the DDP. If a DC chooses to reject a SAR SURPIC message based upon the LRIT ID in the
DataUserRequestor parameter than the DC should send a receipt message with receipt code 0
(not entitled to data) to the requestor.
2.3.6 Processing of multiple requests to change the shipborne equipment

transmitting interval
2.3.6.1 The requirements specified in this section are applicable to requests directed
towards ship terminals that are programmed to transmit only one stream of positional information
to their DC. Requests that are directed towards ship terminals that are programmed to transmit
an asynchronous stream of data for each LRIT request may choose not to follow the
requirements listed in this section if they ensure that the first position report associated with the
stream of data is within the specified reporting rate plus 30 min and all position reports within the
stream of data supplied to the requestor are spaced at the desired reporting time (i.e. all
subsequent position reports are spaced at the time specified by the reporting rate).
2.3.6.2 DCs receiving multiple request messages from different requestors requiring the
shipborne equipment to be programmed at different transmission intervals should set the
shipborne equipment transmitting interval to the fastest requested periodic rate. For example, if
Contracting Government A has transmitted a coastal State request with a reporting rate of 3 h for
ship X, while Contracting Government B has issued a port State request for the same ship X with
a reporting rate of 1 h, then the DC (ASP function) associated with ship X should set the
transmission interval of ship X's shipborne equipment to 1 h.
2.3.6.3 DCs should handle requests for changing a ship's transmission interval based upon
when the DC receives the request. If, for example, a DC receives a request from LRIT Data
User A at 01:00, followed by a second request from LRIT Data User B at 02:00 and a third
request from LRIT Data User C at 02:30, the order of processing for requests should be: LRIT
Data User A, LRIT Data User B and LRIT Data User C. All position reports provided to each
LRIT Data user should be synchronized with each other.
2.3.6.4 DCs4 should ensure that the first request message should establish the time base
line for position reports relating to all subsequent request messages. Essentially, the position
reports sent by the providing DC to all requesting DCs should be time synchronized to the
4
DC may delegate its responsibility to its ASP.
Annex, page 81
position reports associated with the first request message. Thus, the default flag rate would
establish the time base.
2.3.6.5 The providing DC should send a receipt message (receipt code 7) to any requesting
DC if the providing DC cannot send the first position report within the requested duration time
plus 30 min. The 30 min time requirement is required due to latency issues with the terminal.
Under normal circumstances, the DC will always be able to send the first position to the
requesting DC within the time frame; however, if for whatever reason, the providing DC can not
send the first position report within the time frame, then it should send a receipt message
(receipt code 7) to the requiring DC. If, for example, a requesting DC has issued a request that
stipulates the shipborne equipment should be set to a reporting rate of 1 h, then the providing
DC should send a receipt message to the requesting DC if the first position report provided does
not occur within 1 h and 30 min of the request being received. The request message will not be
further processed after the receipt message is issued.
2.3.6.6 The providing DC should maintain the desired time interval amongst all data position
reports when sending LRIT position reports in response to a request for LRIT information at a
desired rate. If the providing DC cannot provide some of the position reports on time or some of
the reports are missing, it should continue to send the LRIT position reports without sending any
receipt message. It should also take the appropriate steps necessary in order to correct the
problem. If, for example, a providing DC is sending LRIT position report messages at a rate of
once an h but the 5th and 6th messages are late while the 10th position report is missing then the
providing DC should continue to send the messages to the requestor at a rate as close to the
desired one h rate without sending any receipt messages.
2.3.6.7 Figure 3 provides an example of a DC receiving two requests from two different DCs
that require a transmission interval change to the LRIT shipborne equipment of a ship entitled to
fly the flag of a Contracting Government utilizing the DC that receives the requests. The first
request associated with DC A has a higher frequency transmission interval than that of the DC B
request. The processing DC associated with the ship should process the requests as follows:
.1 the DC to which the ship is transmitting LRIT information receives ship

position information at time point -5 5/6;
.2 the processing DC sets the requested shipborne equipment to 1 h as

required by the request received from DC A. This request has taken place
at time point -4/6;
.3 DC B should receive its first position report at time 3 1/6 (Synchronized

with 6 hr reports and 1 hr reports). Since the first position report is within
the time frame associated with the request (3 h), a receipt message is not
sent to DC B;
.4 the processing DC, through its ASP, should set the shipborne equipment to
a transmission interval of 3 h at time 9 1/6 since DC A's request has
expired; and
.5 the processing DC should set the shipborne equipment back to a

transmission interval of 6 h after DC B's request has expired at time
point 12 1/6. The following transmission of LRIT information by the ship will
occur at time point 18 1/6.
Annex, page 82
Figure 3
Example of request for decrease in ship's transmission interval

DC A Request DC B Request
message message DC B's 1st report (Synchronized
received received with 3hr & 6 hrs reports)
flag State DC:
DC B:
DC A:
Time: -6 -5 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 13
shipborne equipment shipborne equipment shipborne equipment

Notes: reprogrammed to support DC A reprogamed reprogamed
request to support DC B request to support default flag State
tracking at 6 h interval
Represents LRIT information Represents LRIT information Represents request message Represents request message
provided to DC B provided to DC A received from DC B received from DC A
Represents LRIT information

provided to flag State DC
2.3.6.8 Figure 4 provides an example of a DC receiving two requests from two different DCs
that require a transmission interval change to the shipborne equipment of a ship entitled to fly
the flag of a Contracting Government utilizing the DC that receives the requests. The first
request associated with DC A has a lower frequency transmission interval rate than that of
DC B's request. The processing DC associated with the ship should process the requests as
follows:
.1 the DC to which the ship is transmitting LRIT information receives ship

position information at time point -5 5/6;
.2 the processing DC sets the requested shipborne equipment to 3 h as

required by the request received from DC A. This request has taken place
at time point -4/6;
.3 the processing DC, after receiving a request from DC B at time 3 5/6, will
configure the shipborne equipment to begin transmitting information at an
interval of 1 h beginning at time 4 1/6. The terminal has to wait until
time 4 1/6 to send its first position report, as opposed to sending a position
report at time 3 5/6, in order to ensure that the requestor (i.e. the first
request) receives all of its position reports on schedule. No receipt
message should be sent to DC B since the first position report would be
within the 1 1/2 h request duration message; and
.4 the processing DC should set the shipborne equipment back to the

default 6 h transmission interval after DC B's request expires at 11 1/6 and
DC A's request expires at 9 1/6. The next flag's position report occurs at
time point 12 1/6.
Annex, page 83
Figure 4
Example of request for increase in ship's transmission interval
DC A request DC B request
message received message received
flag State DC :
DC B:
DC A:
Time: -6 -5 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 13
shipborne equipment reprogrammed shipborne equipment reprogrammed

shipborne equipment reprogrammed
to 3 h intervals as requested by DC A to 1 h intervals as requested by DC B
Notes: to default 6 h intervals as required by
flag State
Represents LRIT information Represents LRIT information Represents LRIT information Represents request message
provided to provided to DC B provided to provided to DC B provided to DC A from DC B.
Represents request message

from DC A
2.3.7 Processing of port State requests (AccessType 3) within Message 4
2.3.7.1 DCs that receive a request message with a valid time field populated in the request
duration field and the AccessType set to 3 with a request type set to a value of 2, 3, 4, 5, 6, 10,
or 11 should logically AND5 the Distance and Time parameters. Essentially, the DC should not
start sending port State position reports until the ship associated with the request is within the
distance stated in the distance field and the start time in the request duration is current.
2.3.8 Processing of Port State Request Messages in the Context of Special

Administrative Regions and non-metropolitan territories
2.3.8.1 DCs that receive a port State request message should check to ensure that the port
listed in the port parameter of the request message is a valid port associated with the
Contracting Government specified by the DataUserRequestor parameter of the request
message. Port validation for Contracting Governments should be achieved by checking the
DDP for ports associated with the requesting Contracting Government.
2.3.8.2 The port should be considered a valid port for the requesting Contracting
Government if, within the context of the DDP, the port is directly listed under the Contracting
Government or if the port is listed under a special administrative region or non-metropolitan
territory associated with the Contracting Government.
2.3.8.3 A port State request message transmitted by a special administrative region or non-
metropolitan territory with the port parameter of the request message populated with a port
directly listed under the Contracting Government associated with the special administrative
region or the non-metropolitan territory should be considered not valid. A receipt message
(receipt code 0) should be sent to the requestor indicating that the requestor is not entitled to the
data.
5
AND indicates a logical operation.
Annex, page 84
2.3.9 Valid message parameter combinations for Messages 4 and 5
2.3.9.1 Table 16 provides information on message parameter combinations for LRIT position
request messages (Messages 4 and 5). Parameters, grouped into AccessType and
RequestType combinations, are classified as one of the following: required, optional or not valid.
2.3.9.2 DCs should disregard the contents of all fields that are indicated in Table 16 as
having not valid parameters when processing a Position request or SAR position request
message from another DC.
2.3.9.3 The following message parameters are required for all possible message parameter
combinations:
.1 MessageType;
.2 MessageId;
.3 IMONum;
.4 DataUserProvider;
.5 DataUserRequestor;
.6 TimeStamp;
.7 DDPVersionNum; and
.8 Test.
Annex, page 85
Table 16
Clarification of valid message parameter combinations for Messages 4 and 5
Access Request Port or port Request

Type Type facility Distance Duration Note
0 0 Not valid Not valid Not valid
1 Not valid Not valid Not valid This message combination (Access type 0, Request type 1) is not valid.
1 0 Not valid Not valid Not valid This message combination (Access type 1, Request type 0) is not valid.
1 Not valid Not valid Not valid Request duration is not valid since ship will be polled immediately.
2 Not valid Not valid Required
Annex, page 86

8 Not valid Not valid Optional
9 Not valid Not valid Not valid Request duration is not valid since most recent ship position will be sent.
1 Not valid Not valid Not valid Request duration is not valid since ship will be polled immediately.
8 Not valid Not valid Optional
9 Not valid Not valid Not valid Request duration is not valid since most recent ship position will be sent.
2 Required Required Optional
Annex, page 87

4 This access type number reserved for possible future use
1 Required Not valid Not valid Request duration is not valid since ship will be polled immediately.
2 Required Not valid Required
8 Required Not valid Optional
9 Required Not valid Not valid Request duration is not valid since most recent ship position will be sent.
Annex, page 88

1 Not valid Not valid Not valid Only valid for message type 5.
Annex, page 89
2.3.10 Processing Journal messages
2.3.10.1 The Journal message should be routinely transmitted on a defined schedule as

agreed upon by the R/CDC and IDC issuing the Journal message and the IDE. The frequency
of Journal messages should be one of the following: monthly, biweekly, weekly or daily.
2.3.10.2 The properties of the Journal file should feature the following:
.1 binary attachment to the Journal message (Message 12);
.2 data compressed ZIP file containing XML files according with the following
schema:
LritMessageLog.xsd
<xs:schema version="1.0" targetNamespace="http://gisis.imo.org/XML/LRIT/2008"

xmlns="http://gisis.imo.org/XML/LRIT/2008" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:posrep="http://gisis.imo.org/XML/LRIT/positionReport/2008"
xmlns:posreq="http://gisis.imo.org/XML/LRIT/positionRequest/2008"
xmlns:surpic="http://gisis.imo.org/XML/LRIT/sarSurpicRequest/2008"
xmlns:receipt="http://gisis.imo.org/XML/LRIT/receipt/2008"
xmlns:systemStatus="http://gisis.imo.org/XML/LRIT/systemStatus/2008"
xmlns:journalReport="http://gisis.imo.org/XML/LRIT/journalReport/2008"
xmlns:pricingNotification="http://gisis.imo.org/XML/LRIT/pricingNotification/2008"
xmlns:pricingRequest="http://gisis.imo.org/XML/LRIT/pricingRequest/2008"
xmlns:pricingUpdate="http://gisis.imo.org/XML/LRIT/pricingUpdate/2008"
xmlns:ddpNotification="http://gisis.imo.org/XML/LRIT/ddpNotification/2008"
xmlns:ddpRequest="http://gisis.imo.org/XML/LRIT/ddpRequest/2008"
xmlns:ddpUpdate="http://gisis.imo.org/XML/LRIT/ddpUpdate/2008"
xmlns:xmime="http://www.w3.org/2005/05/xmlmime" elementFormDefault="qualified">
<xs:import namespace="http://gisis.imo.org/XML/LRIT/journalReport/2008"
schemaLocation="JournalReport.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/positionReport/2008"
schemaLocation="ShipPositionReport.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/positionRequest/2008"
schemaLocation="ShipPositionRequest.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/sarSurpicRequest/2008"
schemaLocation="SARSURPICRequest.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/receipt/2008"
schemaLocation="Receipt.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/systemStatus/2008"
schemaLocation="SystemStatus.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/pricingNotification/2008"
schemaLocation="PricingNotification.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/pricingRequest/2008"
schemaLocation="PricingRequest.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/pricingUpdate/2008"
schemaLocation="PricingUpdate.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/ddpNotification/2008"
schemaLocation="DDPNotification.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/ddpRequest/2008"
schemaLocation="DDPRequest.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/ddpUpdate/2008"
schemaLocation="DDPUpdate.xsd"/>
Annex, page 90
<xs:complexType name="PositionReportLogType">
<xs:sequence>
<xs:element ref="posrep:ShipPositionReport"/>
</xs:sequence>
<xs:attribute name="positionSent" type="xs:boolean" use="required"/>
</xs:complexType>
<xs:complexType name="LritMessageType">
<xs:sequence>
<xs:element name="ReceivedTimestamp" type="xs:dateTime" minOccurs="0"/>
<xs:element name="SentTimestamp" type="xs:dateTime" minOccurs="0"/>
<xs:choice minOccurs="1" maxOccurs="1">
<xs:element name="PositionReport" type="PositionReportLogType"/>
<xs:element ref="posreq:ShipPositionRequest"/>
<xs:element ref="surpic:SARSURPICRequest"/>
<xs:element ref="receipt:Receipt"/>
<xs:element ref="systemStatus:SystemStatus"/>
<xs:element ref="journalReport:JournalReport"/>
<xs:element ref="pricingNotification:PricingNotification"/>
<xs:element ref="pricingRequest:PricingRequest"/>
<xs:element ref="pricingUpdate:PricingUpdate"/>
<xs:element ref="ddpUpdate:DDPUpdate"/>
<xs:element ref="ddpRequest:DDPRequest"/>
<xs:element ref="ddpNotification:DDPNotification"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
<xs:complexType name="MessageLogType">
<xs:sequence>
<xs:element name="LritMessage" type="LritMessageType" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="LritMessageLog" type="MessageLogType"/>
</xs:schema>
2.3.10.3 The contents of the Journal file should:
.1 include all messages internally routed within an R/CDC or the IDC; this
should include messages exchanged between two LRIT Data Users of the
R/CDC or the IDC;
.2 not include any LRIT information contained within the LRIT position reports.
The shipborne equipment parameter fields of a LRIT position report should
be populated with dummy values;
.3 include the element ReceivedTimestamp for each message to be populated

with the time when the message was received by the R/CDC;
.4 include the element SentTimestamp for each message to be populated with

the time when the message was sent by the R/CDC; and
Annex, page 91
.5 include the attribute positionSent for the Position Report message set to
"true".
2.3.10.4 The IDE should process received Journal messages as follows:
.1 store the Journal message (Message 12) as a single message in the IDE
Journal;
.2 open the attached ZIP file and extract all of the LRIT messages contained
within; and
.3 store all the messages contained in the ZIP file in the IDE Journal in a
similar manner as other LRIT messages traversing through the IDE.
2.3.11 Processing pricing file information
2.3.11.1 The update pricing file message should be transmitted as determined by the DC
issuing the pricing message and the IDE.
2.3.11.2 R/CDCs and the IDC have the option of sending an update pricing file message
containing a price breakdown that is different for each LRIT Data User associated with the DC,
or a single price breakdown that is the same for all LRIT Data Users of the associated DC.
2.3.11.3 An R/CDC should not issue an update pricing file message that contains a cost
breakdown for single LRIT Data Users as well as for a group of LRIT Data Users (i.e. a choice of
either a single cost breakdown for each individual LRIT Data User or a cost breakdown for all
LRIT Data Users but not a combination of the two choices).
2.3.11.4 The properties of the pricing file attachment should feature the following:
.1 binary attachment to the pricing update message (Message 15);
.2 data compressed ZIP file containing XML file with file name
DataUserPriceYYYYMMDD_XXXX.xml contained in the ZIP file. XXXX
indicates the LRIT ID of the Contracting Government associated with the
XML pricing file when issued by an NDC. XXXX represents either the LRIT
ID of the Contracting Government associated with the XML pricing file or
the LRIT ID of the issuing DC when issued by either an R/CDC or the IDC.
XML files with LRIT IDs representing a DC contain a single pricing
breakdown for all LRIT Data Users.
2.3.11.5 The parameter definitions for the pricing file are:
.1 PositionReport: The charges for providing LRIT information transmitted by

the shipborne equipment at preset intervals6 7;
.2 Poll: The charges for providing LRIT information transmitted by the

shipborne equipment on demand8;
6
7
8
Annex, page 92
.3 PeriodicRateChange: The charges for the remote configuration of the

shipborne equipment so as to transmit at intervals other than the preset9
ones (i.e. those requested by the LRIT Data User other than a SAR
service) and the charges for resetting the shipborne equipment to transmit
at preset interval;
.4 ArchivePositionReport: The charge for providing archived LRIT information

(i.e. all LRIT position reports received from a ship other than the last one);
.5 Currency: The ISO 4217:2001 alphabetic code of the currency associated

with each of the charges. DCs should only populate two currencies
(Special Drawing Rights (SDR) and a currency decided by the Contracting
Government) within this parameter. If more than two currencies are
populated then DCs are only obligated to process the first two currencies
within the currency parameter;
.6 DataCentreID: The LRIT ID of the DC that issued the pricing list;
.7 DataProviderID: The LRIT ID of the Contracting Government from whose

ships LRIT information originate;
.8 IssueDate: The date of issue of the pricing list; and
.9 EffectDate: The date on which the list of charges takes effect.
2.3.12 DCs providing services to a Contracting Government(s) other than that

establishing the centre
2.3.12.1 Any NDC providing services to a Contracting Government(s) other than that
establishing the centre should comply, and operate in accordance, with the requirements of the
Performance standards and of the technical specifications for the LRIT system as a CDC (i.e. for
all intent and purposes but not in name the NDC in question should be considered as a CDC)
and should:
.1 only internally route, if it decides to do so, LRIT information transmitted by

ships entitled to fly the flag of the Contracting Government which has
established it or is using its services. In such cases it should automatically
maintain journal(s) for all of the internally routed LRIT information and
should transmit such journals to the IDE at regular intervals in order to be
combined with the journal(s) maintained by the IDE; or
.2 refrain from internally routeing any LRIT information, including those

transmitted by ships entitled to fly the flag of the Contracting Government
which has established it or is using its services in case it decides not to
automatically maintain journal(s) and transmit these to the IDE. In such
cases it should route all LRIT messages stemming from requests
originating from the Contracting Governments, which established it or were
using the services of the NDC through the IDE.
9
Annex, page 93
2.3.12.2 Any RDC or CDC providing services to a Contracting Government(s) other than
those establishing the centre, should comply, and operate in accordance, with the requirements
of the Performance standards and the technical specifications for the LRIT system as an RDC or
CDC (i.e. for all intent and purposes the RDC or CDC in question continue to be an RDC or
CDC) and in this respect it should consider the Contracting Government(s) to which it provides
services as one of those establishing the centre.
3 Communication protocol strategy
3.1 General
3.1.1 Overview
3.1.1.1 An illustration of the various communications links in the LRIT system is shown in
Figure 5. LRIT messages flow through the LRIT system and along each communication link.
Communication protocols ensure that the messages are securely transported from one LRIT
component to the next.
3.1.1.2 All communications links should comply with the functional description as identified in
the Performance standards while the specific communications protocols stated in the
subsequent sections apply only to certain links as summarized in table 17. Communications
links 1, 2, 3, 4 and 6 do not have to implement the specific communications protocols detailed in
the subsequent sections.
Table 17
Summary of LRIT communications links
Adhere to specific
Communications communications
link LRIT components connected protocols
Link Type 1 Ship to CSP land terminal No
Link Type 2 CSP land terminal to CSP No
Link Type 3 CSP to ASP No
Link Type 4 ASP to NDC or R/CDC No
Link Type 5 ASP to IDC Yes
Link Type 6 Contracting Government to NDC or No
R/CDC
Link Type 7 Contracting Government to IDC Yes
Link Type 8 Any DC to IDE Yes
Link Type 9 DDP Server to IDE Yes
Link Type 10 Any DC to DDP Server Yes
Annex, page 94
Figure 5
LRIT communication links
Link Type 1 Link Type 2 Link Type 3 Link Type 8
Link Type 10
Link Type 4 Link Type 6
CSP
CSP(s) ASP
Station(s) NDC
Link Type 1 Link Type 2 Link Type 3

Link Type 4 DDP
Link Type 6
IDE
RDC or CDC
Contracting Government Link Type 9
CSP Link Type 10
CSP(s) ASP
Station(s)
Link Type 8
Link Type 7
Link Type 1 Link Type 2 Link Type 3
Link Type 5
IDC
Link Type 10
Link Type 8
CSP
CSP(s) ASP
Station(s)
Annex, page 95
3.2 Specific communications protocols
3.2.1 General
3.2.1.1 The communications protocols specified herein are standards based on the
functional description of the communication strategy outlined in the Performance standards.
3.2.2 Physical layer
3.2.2.1 The physical medium that the LRIT messages transverse and the associated
physical layer standards are not limited to one specific type or protocol. Thus, many different
low-level mediums such as fibre optics, copper lines, microwave and their associated physical
layer standard such as sonnet, OC192, T1, E1 are applicable.
3.2.3 Data link layer
3.2.3.1 The data link layer that sits on top of the physical layer is also not limited to one
single standard. There are numerous data link layer protocols that are acceptable and might be
used in the implementation of data communication between the various LRIT network
components. Some examples of applicable standards are: Ethernet, ATM, ISDN and 802.X.
3.2.4 Network layer
3.2.4.1 The network layer should be based upon version 4 (IPv4) of the Internet Protocol
specification. Later versions of the Internet Protocol should be reviewed for compliance prior to
implementation. Each component (e.g., IDE, DCs) in the LRIT network should have its own
unique URL/URI.
3.2.5 Transport layer
3.2.5.1 The transport layer should be based upon the Transmission Control Protocol (TCP).
3.2.6 Application layer
3.2.6.1 The application layer should use Transport Layer Security (TLS version 1.1 or later)
subsequently referred to as TLS and should communicate via XML-based SOAP messages
between the various LRIT components. The SOAP messages are exchanged between SOAP
nodes by binding to the HTTPS protocol as defined by SOAP 1.2.
3.3 Simple Object Access Protocol (SOAP) Overview
3.3.1 General
3.3.1.1 The application layer for exchanging LRIT messages amongst the LRIT components
should be based upon version 1.2 of the SOAP (Simple Object Access Protocol) as defined by
the World Wide Web consortium (W3C). SOAP is an application layer protocol that allows
communications between nodes without requiring any specific communications network,
operating system or programming language. SOAP Version 1.2 specification was available is
http://www.w3.org/TR/soap12.
3.3.1.2 As detailed under the SOAP Binding section below, SOAP messages travel using
HTTP as the underlying protocol. Although HTTP by definition is a request/response
communication mechanism, it is suggested that designers and implementers adopt
asynchronous patterns and reliable non-blocking mechanisms to receive the HTTP response
Annex, page 96
message to ensure an optimum performance. From the application implementation perspective,

messages travel one-way.
3.3.2 SOAP nodes
3.3.2.1 The LRIT components following the communications protocol strategy referenced in
this section functionally operate as SOAP nodes. Two asynchronous one-way message
connections are established between each connecting node. The LRIT messages as defined
earlier flow between SOAP nodes across the communication links illustrated in figure 5.
3.3.2.2 There should only be two nodes associated with the relaying of any SOAP message:
the initial sender and the ultimate receiver. Thus, there should be zero intermediary SOAP
nodes in the routeing path of any SOAP message.
3.3.2.3 SOAP messages should have the role attribute omitted or set to
"http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver" to indicate that messages are
sent to ultimate receivers and no intermediates.
3.3.2.4 SOAP forwarding mechanism is not used given that there are no intermediate nodes
involved. Whenever a received SOAP message content is to be sent to a different location, a
new SOAP message is to be constructed and sent via a SOAP node acting as initial sender.
Any possible association or correlation that might be established between an inbound SOAP
message and an outbound one is to be established and maintained at the application level by
the Software application modules.
3.3.3 SOAP processing
3.3.3.1 Software application modules operating on LRIT components that must follow the
communications protocol strategy should process SOAP messages as outlined in version 1.2 of
the SOAP specification. As mentioned above, LRIT Software modules act as ultimate receivers
and as such they should process the SOAP messages.
3.3.4 SOAP binding
3.3.4.1 SOAP messages should be exchanged between SOAP nodes by binding to the
HTTP(s) protocol as defined by SOAP 1.2.
3.3.4.2 SOAP messages should be sent using the HTTP POST web method only. The body
of an HTTP POST message should contain the message parameters embedded within a SOAP
message structure.
3.3.4.3 The following is an example of an HTTP header. Note that SOAP 1.2 message
bound to HTTP should have the Content-Type set to "application/soap+xml" (without quotes).
POST /LRITSample/Service HTTP/1.1

Host: localhost
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length
Annex, page 97
3.3.4.4 SOAP messages containing file attachments should be prepared by:
.1 zipping the file attachment; and
.2 constructing and transmitting the SOAP message, with zipped attachment

file, using the SOAP Message Transmission Optimization Mechanism
(MTOM) as described at http://www.w3.org/TR/soap12-mtom/.
3.3.5 Additional considerations and other aspects
3.3.5.1 Data security (e.g., encryption), authentication and authorization are out of the scope
of this sub-section and are to be managed by other layers.
3.3.5.2 In order to minimize complexity without jeopardizing security, data security should be
accomplished by securing the channel of communication.
4 Data security within the LRIT network
4.1 General
4.1.1 Adherence to the Performance standards
4.1.1.1 Data security for LRIT information exchanged between the various LRIT components
should be based upon the performance and functional requirements outlined in section 12 of the
4.1.1.2 Authorization, identification, authentication, confidentiality and integrity are the key
functional concepts with respect to data security for the LRIT system. LRIT system availability
should be addressed via conformance to the Performance standards.
4.1.2 Authorization
4.1.2.1 All LRIT information existing in the LRIT system should not be made accessible to all
LRIT Data Users. Data authorization to LRIT Data Users should comply with the Regulation and
the Performance standards. Each LRIT component within the network should ensure that the
component with which it is communicating is authorized to receive the information being
transmitted in accordance with the DDP.
4.1.3 Identification and authentication
4.1.3.1 The various LRIT components in the LRIT system should perform identification and
authentication of each component before exchanging information using a standard
authentication process.
4.1.4 Confidentiality
4.1.4.1 The data exchanged between LRIT components should be encrypted for protection
and should not be disclosed to unauthorized entities during transit across the LRIT network.
This should be accomplished by using standard digital cryptography techniques featuring an
encryption strength equivalent to or better than 128 bits.
Annex, page 98
4.1.5 Integrity
4.1.5.1 The data exchanged between LRIT components should not be altered by any entity
during transit across the LRIT system. Native TLS features providing integrity checks of the data
transport should be used. This should be accomplished by using standard digital cryptography
techniques featuring an encryption strength equivalent to or better than 128 bits.
4.2 Point to point data security strategy and protocol options
4.2.1 General
4.2.1.1 LRIT components within the LRIT system should communicate with one another
through secure point to point communication links.
4.2.2 Application layer security
4.2.2.1 Each LRIT component that forms a point to point communications link should use
Transport Layer Security (TLS version 1.1 or later) when exchanging LRIT information. The TLS
specification is defined by the Internet Engineering Task Force in RFC 4346.
4.2.2.2 The TLS protocol provides communications security over the Internet. The protocol
allows client/server applications to communicate in a way that is designed to prevent
eavesdropping, tampering, or message forgery and addresses the security requirements for
confidentiality and integrity.
4.2.3 Data confidentiality and integrity
4.2.3.1 Confidentiality and integrity is achieved via 128 bit (minimum) TLS encryption using a
cryptographic Hash Message Authentication Code (HMAC) symmetric algorithm. The HMAC
value protects both a message's integrity as well as its authenticity, by allowing verifiers (who
also possess the secret key) to detect any changes to the message content. HMAC can be
used with a variety of different hash algorithms.
4.2.3.2 Each LRIT component should use Key Hashing for Message Authentication Code
(HMAC) when communicating across a TLS secured link. HMAC should ensure that data is not
altered during transit and the data integrity is maintained.
4.2.3.3 HMAC can be used with a variety of different hash algorithms. TLS uses it in the
handshake with two different algorithms, MD5 and SHA-1, denoting these as HMAC_MD5
(secret, data) and HMAC_SHA (secret, data). Additional hash algorithms can be defined by
cipher suites and used to protect record data, but MD5 and SHA-1 are hard coded into the
description of the handshaking for this version of the protocol.
4.2.4 Identification and authentication
4.2.4.1 Public - Private Key Cryptography - Before exchanging LRIT information, LRIT
components connecting over the TLS link should use an industry standard, public - private
(asymmetric) key infrastructure strategy to ensure positive identification and authentication of the
LRIT components. The global industry standard public key infrastructure (PKI) certificate should
be issued by a trusted party to ensure the vetting of, and authentication of, user identities. The
Organization should ensure that the LRIT IDs are populated in the PKI certificate.
4.2.4.2 If either component detects an issue with the other LRIT component's PKI certificate,
then exchange of data information should not occur.
Annex, page 99
5 Web Service Description Language (WSDL) documents
5.1 General
5.1.1 WSDL definitions for the IDE and DCs
5.1.1.1 The Web Service Description Language (WSDL) definitions for the IDE and DCs are
contained in annex 6.
6 Message flow
6.1 Message flow diagrams
6.1.1 General
6.1.1.1 Various message flows are illustrated in Figures 6, 7 and 8.
Annex, page 100
Figure 6
Message flow example

Periodic position report (Message 1)
Ship flying the flag of

Contracting Government A
200 nm off the coast of
Contracting Government B
Shipborne equipment
automatically transmit unique
identification number, position LRIT Data User
and associated date and time Contracting Government A
LRIT ID = 0777
ASP A
builds Position report message:
ASP ID = 0005 Contracting Government A
CSP A NDC
. . . (others parameters)
LRIT ID = 0006 (DC A)
(optional) LRIT ID = 3999
ASP A
LRIT ID = 0005
DC A check polygons in DDP:

Polygon match for standing orders (Coastal) of Contracting
Government C
DC A builds Periodic position report message
Message Type = 1
DC ID = 3999
Response Type = 1
LRIT ID Data User Requestor = 0779
LRIT ID Data User Provider = 0777
and
route to IDE
IDE IDE
process Periodic position report message: LRIT ID = 0002
look at
"LRIT ID Data User Requestor"
and
route to LRIT ID = 0779's DC
Contracting Government C Contracting Government B

NDC NDC
(DC C) (DC B)
LRIT ID = 4999 LRIT ID = 5999
DC C
process Periodic position report
message
and route to LRIT Data User 0779
LRIT Data User LRIT Data User

Annex, page 101
Figure 7

Position request (Message 4)
and Polled position report (Message 2)
DC A
process Polled position report message:
look at
"LRIT ID Data User Requestor"
and
LRIT Data User route to LRIT ID = 0777
LRIT ID = 0777
LRIT Data User

builds Position request message
Message Type = 4
Message ID = 07772008121508050012345
LRIT ID Data User Requestor= 0777
IMO number = 0000001 Contracting Government A
LRIT ID Data User Provider = 0779 NDC
Access Type = 5 (DC A)
Request Type = 1 LRIT ID = 3999
DC A
process Position request message IDE
and process Polled position report message:
route to IDE look at
LRIT ID Data User Requestor
and
route to LRIT ID = 0777's DC
IDE
LRIT ID = 0002
IDE
process Position request message:
look at
LRIT ID Data User Provider
and DC C
route to LRIT ID = 0779's DC add others message parameters:
LRIT ID Data User Requestor = 0777
and
route to IDE
Contracting Government C
NDC
(DC C) ASP C
LRIT ID = 4999 builds Polled position report message:
Reference ID = 07772008121508050012345
Message Type = 2
DC C
process Position request
message:
look at
Access Type, Request Type ASP C
and process Position request
LRIT Data User CSP C
route to ASP C message:
Contracting Government C LRIT ID = 0004
ASP C look at Request Type
LRIT ID = 0779 (optional)
LRIT ID = 0003 and
route command to CSP C
Annex, page 102
Figure 8

SAR SURPIC request (Message 6),
Receipt (Message 7) and SAR position report (Message 3)
Ships at sea

CSP
Satellite
LRIT Data User
SAR service of Contracting Government A
LRIT ID = 5454
(subject to MSC.1/Circ1297, paragraph 3)
Ship in distress
SAR region is the responsibility of
SAR SURPIC Cirular area LRIT Data User A

builds SAR SURPIC request message:
Message type= 6 DC A process DC A process
Message ID = 54542008121508250011111 Receipt Message: SAR position report message:
SAR Circular Area = 51.42.N:018.33.W:050 look at look at
Number of positions = 4 Destination LRIT ID Data User Requestor
LRIT ID Data User Requestor = 5454 and and
. . . (others parameters) route to LRIT Data User route to LRIT Data User
and
route to DC
CSP C NDC
LRIT ID = 0006 (DC A)
(optional) ASP A LRIT ID = 3999
LRIT ID = 0005
DC A IDE IDE
process SAR SURPIC request
` process Receipt Message: process SAR position report:
message look at look at
and Destination LRIT ID Data User Requestor
route to IDE and and
route to LRIT ID = 5454's DC route to LRIT ID = 5454's DC
IDE
LRIT ID = 0002
DC C
process SAR SURPIC request message
and build Receipt Message: DC B
Contracting Government C registered ships not process SAR SURPIC request message and
in circular area build SAR position report message:
Message type= 7 Contracting Government B registered ships
IDE
Reference ID = 54542008121508250011111 located in circular area
process SAR SURPIC request
Receipt code = 1 Message type = 3
message and
Destination = 5454 LRIT ID Data User Requestor = 5454
route to all connected DCs
Originator = 4999 LRIT ID Data User Provider = 0780
. . . (others parameters) Reference ID = 54542008121508250011111
and . . . (others parameters)
route to IDE and route to IDE

NDC NDC
(DC C) (DC B)
LRIT Data User
Contracting Government C
LRIT ID =0779
CSP C CSP B
LRIT ID = 0004 ASP C LRIT ID = 0057 ASP B LRIT Data User
(optional) LRIT ID = 0003 (optional) LRIT ID = 0055 Contracting Governement B
LRIT ID =0780
Annex, page 103
Annex 4
Technical specification for the LRIT Data Distribution Plan
Part I
Technical specifications
1 Introduction
1.1 This document presents the design and functionality of the LRIT Data Distribution
Plan (DDP) implementation, and should always be read together with:
.2 the Revised performance standards and functional requirements for the

Long-range identification and tracking of ships;
.3 the Technical specifications for the International LRIT Data Exchange;
.4 the Technical specifications for communications within the LRIT system; and
.5 the XML schemas.
1.2 Unless expressly provided otherwise:
.1 Recipient components means the LRIT Data Centres (DCs) and the
International LRIT Data Exchange (IDE);
.2 DDP server means the DDP module of the Global Integrated Shipping
Information System (GISIS), including both the web-based human interface
to DDP information and the SOAP Web service interface for recipient
components as described in section 6;
.3 DDP information means data required to be contained in the DDP by either

regulation V/19-1 or the Performance standards and to be communicated
to all recipient components;
.4 Publishing means generating a new version of the DDP in response to

changes to DDP information by Contracting Governments or other parties.
DDP versions and publishing schedules are described in detail in section 2;
.5 Any reference to a Contracting Government automatically includes

non-metropolitan areas to which the Contracting Government concerned
has notified the Organization that it has extended the application of
the 1974 SOLAS Convention;
.6 Any reference to non-metropolitan area(s) applies only as far as the

non-metropolitan area(s) to which the Contracting Government concerned
has extended the application of the 1974 SOLAS Convention.
1.3 The following notations are used in this document:
.1 <ElemName> refers to an XML element named "ElemName";
.2 @attrName refers to an XML attribute named "attrName".
Annex, page 104
1.4 The following sections of this document cover issues relating to:
.1 the publishing and versioning of the DDP (section 2);
.2 the format of the XML representations of DDP information (section 3);
.3 the GML format for uploading geographical areas to the DDP (section 4);
.4 constraints on polygons of geographical areas contained in the DDP

(section 5);
.5 the DDP server and its external interfaces (section 6).
2 DDP content, versioning and publishing
2.1 The information to be included in the DDP is specified in section 11.2 of the
Types of DDP information
2.2 Each item of DDP information is categorized into one of two types: regular or
immediate.
2.2.1 The categorization distinguishes between DDP information that requires urgent
implementation (immediate) from those which for technical reasons require a longer period of
time to be implemented by recipient components or which can be processed in batches in order
to increase the efficiency of the system (regular).
2.3 Items of DDP information categorized as regular are:
.1 Contracting Governments, including non-metropolitan areas to which the

application of the Convention has been extended;
.2 Contact points (National, SAR Services, ASP, DC, IDE, DDP server, and
LRIT Coordinator);
.3 Geographical areas (internal waters, territorial sea, seaward outer

boundary of 1,000 NM, custom coastal State areas for standing orders);
.4 Ports under the under the jurisdiction of Contracting Governments;
.5 Port facilities under the jurisdiction of Contracting Governments;
.6 Places under the jurisdiction of Contracting Governments;
.7 SAR Services of Contracting Governments;
.8 ASP-related information;
.9 LRIT ID of the Data Centre used by a Contracting Government; and
.10 LRIT Coordinator-related information.
Annex, page 105
2.4 Items of DDP information categorized as immediate are:
.1 Exclusion orders pursuant to the provisions of regulation V/19-19.1;
.2 Operational information relating to LRIT Data Centres (web service

endpoint (URL/URI) or contact details of the DC);
.3 Coastal State standing orders, where the geographical areas to be

monitored have already been implemented by DCs. (Note that
geographical areas, including custom coastal State areas, are regular DDP
information, and generally take 24 h10 after publishing to be implemented
by recipient components.);
.4 Information relating to the IDE; and
.5 Information relating to the DDP server.
Versions of the DDP
2.5 Version numbers are used to uniquely identify the set of information contained within
the DDP at a particular point in time.
2.6 The set of regular items of DDP information and the set of immediate items of
DDP information are versioned independently of each other.
2.7 The term regular version is used when referring to a set of all regular DDP
information, and has a unique regular version number associated with it. The term immediate
version is used when referring to a set of all immediate DDP information, and has a unique
immediate version number associated with it.
2.7.1 The regular version number and the immediate version number are each
represented by a single integer number, starting with 1 for the first version and incrementing with
each new version of the DDP resulting from changes to regular information and to immediate
information respectively.
2.8 A DDP version number is composed of a regular version number and an immediate
version number, forming the unique identifier of the complete set of all DDP information as
implemented by all LRIT system components at a particular point in time.
2.8.1 A DDP version number has the following format:
<Regular version number><colon><Immediate version number>
An example of a DDP version number is 22:67, indicating the version of the DDP implemented at
a particular point in time which consists of the set of regular information at version 22, and the
set of immediate information at version 67.
Publishing and implementation times
2.9 Changes to regular DDP information result in the publishing of a new regular version
of the DDP.
10
Publishing and implementation times of the DDP for recipient components are specified below.
Annex, page 106
2.9.1 Changes to regular information are batched daily, and published in a new regular
version at 00:00 UTC on the day following that in which they were made.
2.10 Changes to immediate DDP information result in the publishing of a new immediate
version of the DDP.
2.10.1 Changes to immediate information are published in a new immediate version of the
DDP at the time the change is made within the DDP.
2.11 The specific time of publishing of a new regular version or immediate version of the
DDP, and the corresponding time at which it should be implemented by all recipient components,
are specified within the message transmitted by the DDP server (described in detail in section 3).
2.11.1 In general, a newly-published regular version of the DDP is implemented by all

recipient components at 00:00 UTC on the day following the time of publishing of the regular
version.
2.11.2 In general, a newly-published immediate version of the DDP is implemented by all

recipient components one h following the time of publishing of the immediate version.
Illustration of publishing and implementation times of the DDP
2.12 Figure I-1 provides an illustrative sample of publishing and implementation times of
new versions of the DDP.
2.12.1 The upper-level11 markers indicate the time of publishing of new regular versions
(indicated in the figure by a single-lined border) and immediate versions (double-lined border) of
the DDP, along with their associated version numbers.
2.12.2 The lower-level markers12 indicate the time at which the published versions are
implemented by DCs and the IDE within the LRIT system, along with the associated
DDP version number in effect from that point in time.
2.12.3 In the example, the version of the DDP implemented within the LRIT system
at 00:57 UTC on 2 June 2009 is 81:65 that is, regular version 81 and immediate version 65 of
the DDP is implemented within the LRIT system at that time.
2.12.4 Note that the immediate version number is incremented each time an immediate
version of the DDP is published, which happens at the time a change is made to any immediate
DDP information. The regular version number is incremented each time a regular version of the
DDP is published, which happens at 00:00 UTC on the day following that in which a change is
made to any regular DDP information.
2.12.5 No regular version is published on 00:00 UTC on 3 June 2009, meaning that no
changes were made to regular DDP information during 2 June 2009.
2.12.6 Figure I-1 illustrates how changes to regular and immediate DDP information are
published and implemented independently of each other, together forming the DDP version
number of the DDP which is implemented within the LRIT system at a particular point in time.
11
Coloured yellow and orange, respectively, in the electronic version of this document.
12
Coloured blue in the electronic version of this document.
Annex, page 107
Figure I-1
New DDP versions and implementation times

(for explanations refer to paragraph 2.12 and table I-5)

Regular
version number
Publish time
65 82 66 67 68 69 70 71 83
time = 23:57 time = 00:00 time = 05:14 time= 09:33 time = 10:00 time= 23:00 time = 01:14 time = 23:05 time = 00:00
Immediate
version number
Publish time
... ...
00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 ... 09:00 10:00 11:00 12:00 13:00 ... 22:00 23:00 00:00 01:00 02:00 03:00 ... 23:00 00:00 01:00 02:00 03:00

2 June 2009 3 June 2009 4 June 2009
DDP version number 81:65 81:66 81:67 81:68 82:69 82:70 82:71
time = 10:33 time = 11:00 time = 00:00 time = 02:14 time = 00:05
time = 00:57 time = 06:14
Implementation time
Annex, page 108
3 XML representations of DDP information
3.1 Information contained within the DDP and changes to this information are
communicated by the DDP server to recipient components in defined XML formats. XML data
formats should use UTF-8 to encode Unicode characters in the English language.
3.2 The Communications specifications gives the complete XML Schema definition
applicable to the DDP, in the file DDP.xsd.
3.3 The two representations of DDP information are:
.1 Full DDP, which contains all DDP information at a specific DDP version
number which is implemented within the LRIT system; and
.2 Incremental update, which details the changes resulting from the insertion,
amendment or deletion of specific DDP information by Contracting
Governments and other parties.
Datatypes used in the full DDP and incremental updates
3.4 In addition to primitive XML datatypes, several custom datatypes for representing
DDP information are defined within the XML Schema for the DDP.
3.5 The following sub-paragraphs describe custom datatypes and the formats of their
key values for representing DDP information within the full DDP and in incremental updates.
3.5.1 Geographical coordinates of points given within geographical polygons and

positional elements (e.g., <Polygon> and <Position>) are given as follows:
.1 Coordinate order of longitude followed by latitude;
.2 Negative values indicate south or west cardinal directions and positive

values indicate north or east, for latitudes and longitudes respectively; and
.3 All values are in decimal degrees, to two decimal places.
3.5.2 Datatypes representing unique identifiers:
.1 @locode of <Port> A globally unique code for ports belonging to

Contracting Governments, from the UN/LOCODE database. The code is a
five-character string, where the first two characters form the ISO 3166-1:1997
Alpha-2 code for the Contracting Government or non metropolitan territory
where the port is located. The subsequent three characters are usually
three letters, but may contain digits where a temporary code has been
assigned by the Organization pending formal assignment of a code by the
UN ECE13 (who maintain UN/LOCODE);
.2 @placeCode of <Place> A globally unique code for places under the

jurisdiction of Contracting Governments. This is a six-character string
where the first three letters are the ISO 3166-1:1997 Alpha-3 code of the
Contracting Government or non metropolitan territory where the place is
located, followed by 3 digits; and
13
The UN/LOCODE website is at http://www.unece.org/locode.
Annex, page 109
.3 @imoPortFacilityNumber of <PortFacility> The "IMO Port Facility Number"

of the port facility, which is a globally unique identifier assigned by the
Maritime Security module of GISIS to port facilities declared by Contracting
Governments. This value is the concatenation of the UN/LOCODE of the
port containing the facility and four digits, separated by a hyphen.
3.5.3 Datatypes relating to Contracting Governments and non-metropolitan territories

(represented with <ContractingGovernment> and <Territory> respectively):
.1 @isoCode of <Name> The ISO 3166-1:1997 Alpha-3 code of the

Contracting Government or non-metropolitan territory. Where ISO-assigned
codes are unavailable, codes have been assigned within the reserved
codespace for custom applications and are as defined for use within GISIS;
.2 The elements <InternalWaters>, <TerritorialSea>,

<SeawardAreaOf1000NM> and <CustomCoastalAreas> contain 0 or more
elements of this type each describing a closed polygonal geographical
area, subject to the restrictions set out in section 5. Each of these
elements has an @areaID attribute uniquely identifying the area within the
DDP. (Table I-1 sets out the format of the values of this attribute.)
.3 A <StandingOrder> for a Contracting Government within

<CoastalStateStandingOrders> lists the areaID values of polygons defined
in either the <InternalWaters>, <TerritorialSea>,
<SeawardAreaOf1000NM> or <CustomCoastalAreas> of that Contracting
Government, which should be monitored by DCs as the areas for which the
coastal State standing order is in effect; and
.4 <DataCentreID> specifies the LRIT ID of the Data Centre serving the

Contracting Government. The Data Centre specified is defined in
<DataCentre> with the corresponding value of @lritID within
<DataCentres>.
3.5.4 Datatypes for information about DCs, the IDE, and the DDP server:
.1 <DataCentre>:
.1 @lritID is the LRIT ID of the Data Centre;
.2 <IDEInterfaceWebServiceLocation> is the URI14 of the SOAP

endpoint for connections by the IDE; and
.3 <DDPInterfaceWebServiceLocation> is the URI14 of the SOAP

endpoint for connections from the DDP server.
.2 <IDE>:
.1 @lritID is the LRIT ID of the IDE;
.2 <DCInterfaceWebServiceLocation> is the URI15 of the SOAP

endpoint for connections by Data Centres; and
14
The hostname (fully-qualified domain name) part of the URI specified for <IDEInterfaceWebServiceLocation>
must exactly match the hostname part of the URI specified for <DDPInterfaceWebServiceLocation>.
Annex, page 110
.3 <DDPInterfaceWebServiceLocation> is the URI15 of the SOAP

endpoint for connections by the DDP server.
.3 <DDPServer>:
.1 @lritId is the LRIT ID of the DDP server; and
.2 <WebServiceLocation> is the URI of the SOAP endpoint for

connections by the IDE and by Data Centres.
Full DDP
3.6 The full DDP is represented in a single XML file, with root element
<DataDistributionPlan>. It contains all DDP information as implemented within the LRIT system
at a particular point in time, and is identified by its unique DDP version number.
3.7 The following attributes in the root element of the full DDP specify the
DDP version number and publishing and implementation times of the DDP being represented:
.1 @versionNum: The DDP version number of the full DDP represented

(e.g., 45:210), as described in paragraph 2.8;
.2 @regularVersionPublishedAt: The time of publishing of the regular

DDP information in this version of the DDP;
.3 @regularVersionImplementationAt: The time of implementation of the

regular DDP information in this version of the DDP within the LRIT system;
.4 @immediateVersionPublishedAt: The time of publishing of the immediate

DDP information in this version of the DDP; and
.5 @immediateVersionImplementationAt: The time of implementation of the

immediate DDP information in this version of the DDP within the LRIT
system.
Incremental update
3.8 An incremental update details the changes to DDP information between two specific
versions of the DDP which are or have been implemented within the LRIT system, specified in
an XML file with root element <DataDistributionPlan-IncrementalUpdate>.
3.9 An incremental update is applied to an initial version of the DDP (the base version)
transforming it into a version of the DDP consolidating the changes contained within the update
(the target version).
3.9.1 The following attributes in the root element of an incremental update indicate the
base version of the DDP to which the updates must be applied, and resulting (target) version the
DDP once all updates have been applied:
.1 @baseRegularVersionNum: The regular version number of the full DDP to

which this update should be applied;
15
The hostname (fully-qualified domain name) part of the URI specified for <DCInterfaceWebServiceLocation>
must exactly match the hostname part of the URI specified for <DDPInterfaceWebServiceLocation>.
Annex, page 111
.2 @targetRegularVersionNum: The regular version number of the resulting

full DDP after this update has been applied;
.3 @baseImmediateVersionNum: The immediate version number of the full

DDP to which this update should be applied; and
.4 @targetImmediateVersionNum: The immediate version number of the

resulting full DDP after this update has been applied.
3.9.2 The @baseRegularVersionNum and @targetRegularVersionNum attributes are

present only if the update contains information regarding changes to regular DDP information.
The @baseImmediateVersionNum and @targetImmediateVersionNum attributes are present
only if the update contains information regarding changes to immediate DDP information.
3.10 The root element of an incremental update contains a series of zero or more
<Regular> and <Immediate> elements, each of which details changes between two consecutive
versions of the DDP.
3.11 The root element will contain no child elements if there are no changes applicable to
the base and target versions specified for the incremental update.
3.12 A <Regular> element represents changes between one regular version of the DDP,
and the regular version following it. Similarly, an <Immediate> element represents changes
between one immediate version of the DDP and the immediate version following it.
3.12.1 Therefore, for incremental updates spanning multiple regular versions or multiple
immediate versions, multiple <Regular> or <Immediate> elements are present, each one
separately enumerating the changes between two consecutive versions, starting at the base
version and ending with the target version of the incremental update.
3.13 The following attributes of the <Regular> and <Immediate> elements indicate the
base and target version numbers before and after applying the changes detailed within them:
.1 @baseRegularVersionNum (in <Regular> elements only): The regular

version number of the DDP to which the changes in this element should be
applied;
.2 @baseImmediateVersionNum (in <Immediate> elements only): The

immediate version number of the DDP to which the changes in this element
should be applied;
.3 @targetRegularVersionNum (in <Regular> elements only): The regular

version number of the resulting DDP after the changes in this element have
been applied;
.4 @targetImmediateVersionNum (in <Immediate> elements only): The

immediate version number of the resulting DDP after the changes in this
element have been applied;
.5 @targetPublishedAt: The time of publishing of the version represented by

@targetRegularVersionNum or @targetImmediateVersionNum; and
.6 @targetImplementationAt: The time of implementation of

the version represented by @targetRegularVersionNum or
@targetImmediateVersionNum.
Annex, page 112
3.14 The child elements of <Regular> and <Immediate> elements represent the operation
to be performed on the specified item of DDP information:
.1 <Insert> for the insertion of new information into the DDP;
.2 <Update> for updates to existing information within the DDP; and
.3 <Delete> for the deletion from the DDP of an element of information.
3.15 The order of operations listed within in an incremental update is significant, and
should be applied sequentially from the top downwards when updating existing DDP information.
3.15.1 It should not be assumed that the operations exactly represent atomic transactions
on the DDP server.
@xPath attribute in incremental update elements
3.16 The value of @xPath is an XML Path Language16 value indicating the location of the
item of DDP information within the full DDP of the specified base version where the change has
occurred.
3.16.1 @xPath gives an absolute reference to an element within the full DDP. Thus, it
always begins with "/DataDistributionPlan".
3.17 Usage and processing of the @xPath value is optional for implementers of recipient
components, depending on their preferred methods for identifying the items of DDP information
within their own systems which are affected by an incremental update.
3.18 For each of the operations, the value of @xPath is as follows:
.1 <Insert>: the node in the base full DDP under which the data has been
inserted;
.2 <Update>: the node in the base full DDP whose contents have been
changed; and
.3 <Delete>: the node in the base full DDP which has been deleted.
Incrementable datatypes
3.19 Tables I-1 and I-2 list the datatypes, defined in the XML Schema for the full DDP,
which can be present within the insert, update and delete operations enumerated within an
incremental update.
3.19.1 Table I-1 lists the datatypes corresponding to regular DDP information, which are the
only datatypes that may be present within <Regular> elements of an incremental update.
3.19.2 Table I-2 lists the datatypes representing immediate DDP information, which are the
only datatypes that may be present within <Immediate> elements of an incremental update.
3.20 The tables also specify unique identifiers for each of these datatypes, and the format
of their values. These identifiers uniquely identify the corresponding item of DDP information
within the full DDP.
16
The official W3C site describing this language is at http://www.w3.org/TR/xpath.
Annex, page 113
Table I-1
Regular Datatypes
Incrementable datatype Identifier attribute Parent element in Full DDP Identifier format
contractingGovernmentType lritID DataDistributionPlan <CG LRIT ID>
contactPointType contactID SARService CPSAR<SAR LRIT ID>_<pk>
NationalPointsOfContact CPN<CG LRIT ID>_<pk>
ASPInfo CPASPINF<ASP LRIT ID>_<pk>
DataCentreInfo CPDCINF<CG LRIT ID>_<pk>
DataCentre CPDC<DC LRIT ID>_<pk>
IDE CPIDE<IDE LRIT ID>_<pk>
DDPServer CPDDP<DDP LRIT ID>_<pk>
LRITCoordinator CPLC<LC LRIT ID>_<pk>
lrit: polygonType areaID InternalWaters GAIW<CG LRIT ID>_<pk>
TerritorialSea GATS<CG LRIT ID>_<pk>
SeawardAreaOf1000NM GAOT<CG LRIT ID>_<pk>
CustomCoastalAreas GACA<CG LRIT ID>_<pk>
portType locode Ports <LOCODE>
portFacilityType imoPortFacilityNumber PortFacilities <IMOPortFacilityNumber>
placeType placeCode Places <PlaceCode>
sarServiceType lritID SARServices <SAR LRIT ID>
aspInfoType aspInfoID ContractingGovernment ASPINF<CG LRIT ID>_<pk>
dataCentreInfoType dcInfoID ContractingGovernment DCINF<CG LRIT ID>
aspType lritID ASPs <ASP LRIT ID>
lritCoordinatorType lritID DataDistributionPlan <LC LRIT ID>
Annex, page 114
Table I-2
Immediate Datatypes
Incrementable datatype Identifier attribute Parent element in Full DDP Identifier format
exclusionType exclusionID Exclusions EXCL<CG LRIT ID>_<pk>
dataCentreType lritID DataCentres <DC LRIT ID>
coastalStateStandingOrderType contractingGovernmentID CoastalStateStandingOrders <CG LRIT ID>
ideType lritID DataDistributionPlan <IDE LRIT ID>
ddpserverType lritID DataDistributionPlan <DDP LRIT ID>
Explanatory note on the symbols used in Tables I-1 and I-2:
<pk>: A positive integer

<CG LRIT ID>: LRIT ID of Contracting Government
<SAR LRIT ID>: LRIT ID of SAR Service
<ASP LRIT ID>: LRIT ID of ASP
<DC LRIT ID>: LRIT ID of Data Centre
<IDE LRIT ID>: LRIT ID of the International LRIT Data Exchange
<DDP LRIT ID>: LRIT ID of the Data Distribution Plan server
<LC LRIT ID>: LRIT ID of the LRIT Coordinator
<LOCODE>: UN/LOCODE of the port
<IMOPortFacilityNumber>: IMO Port Facility Number of the port facility
<PlaceCode>: Code for the place under the jurisdiction of a Contracting Government
Annex, page 115
4 Uploading information on geographical areas
4.1 DDP information on geographical areas may be uploaded by each Contracting

Government to the DDP server, as polygons representing: (1) the water landward of baselines
(referred to as InternalWaters); (2) the territorial sea (referred to as TerritorialSea);
(3) 1,000 nautical miles area (referred to as SeawardAreaOf1000NM); and (4) other custom
definitions of geographical areas within the 1,000 nautical miles area (referred to as
CustomCoastalAreas), which may be used for the purposes of the coastal State standing order.
4.2 The file to be uploaded must conform to the specifications given in this section in
order to be successfully accepted and processed by the DDP server.
Upload file format
4.3 The uploaded file must be a valid GML17 document, whose root node is of the
gml:MultiSurface datatype.
4.4 Coordinate values representing polygons given within <gml:posList> must conform to
the conventions described in paragraph 3.5.1, which are reproduced here:
.1 Coordinate order of longitude followed by latitude;
.2 Negative values indicate south or west cardinal directions and positive

values indicate north or east, for latitudes and longitudes respectively; and
.3 All values are in decimal degrees, to two decimal places.
4.5 The @gml:id attribute of the root node must have one of the following values
corresponding to the type of boundary information being uploaded:
.1 "InternalWaters";
.2 "TerritorialSea";
.3 "SeawardAreaOf1000NM"; or
.4 "CustomCoastalAreas"
4.6 The root node may contain any number of child elements of the GML Polygon
datatype, each of which must be specified in accordance with the constraints given section 5.
4.7 The DDP server does not perform any validation of the geographical areas covered
by the polygons defined within the uploaded file.
4.7.1 The DDP server only checks uploaded polygons against the constraints given in
section 5 with respect to:
.1 Polygons being closed (i.e. first vertex matching the last);
.2 Precision of 2 decimal places in the decimal degree value of a coordinate;
17
Geography Markup Language.
Annex, page 116
.3 Latitudinal and longitudinal components of a coordinate being within the

valid range of integer values for latitudes and longitudes respectively;
.4 The total number of polygons for each type of boundary; and
.5 The total number of vertices per polygon, depending on type of boundary.
4.8 The @gml:id attributes of these polygons may, optionally, be formed according to the
formats set out in Table I-1 for the lrit:polygonType datatype.
4.8.1 If the @gml:id attribute of a polygon correctly matches the format defined for the type
of boundary it defines, it will be processed by the DDP server as part of the upload process.
Otherwise, the @gml:id of the polygon is ignored.
4.9 Each polygon may optionally include a @gml:description attribute, which is

processed by the DDP server as the caption for that polygon (represented in an <lrit:Caption>).
Sample GML upload file
4.10 The text following paragraph 4.10.1 constitutes a sample GML file representing the
internal waters areas for Contracting Government with LRIT ID '1234' which may be uploaded to
the DDP server.
4.10.1 This example is purely to illustrate the format of the expected upload file, and should
not be considered as demonstrating a valid geographical area or polygon definition with regards
to the <gml:posList> values used:
<?xml version="1.0" encoding="utf-8"?>

<gml:MultiSurface
xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" xsi:schemaLocation="http://www.opengis.net/gml/3.2
http://schemas.opengis.net/gml/3.2.1/gml.xsd" gml:id="InternalWaters">
<gml:surfaceMembers>
<gml:Polygon gml:id="GAIW1234_1">
<gml:description>Area 1</gml:description>
<gml:exterior>
<gml:LinearRing>
<gml:posList>7.25 53.32 7.19 53.31 7.01 53.33 6.97
53.37 6.91 53.43 6.88 53.45 6.81 53.49 6.77 53.51 6.74 53.53 6.68 53.55 6.61 53.58 6.55 53.61 6.64
53.62 6.72 53.65 6.8 53.67 6.83 53.67 7.05 53.69 7.16 53.72 7.32 53.73 7.35 53.73 7.4 53.74 7.61
53.76 7.69 53.78 7.76 53.78 7.81 53.79 8.34 53.96 8.57 54.3 7.25 53.32</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
<gml:Polygon gml:id="GAIW1234_2">
<gml:description>Area 2</gml:description>
<gml:exterior>
<gml:LinearRing>
<gml:posList>7.25 53.32 7.19 53.31 7.01 53.33 6.97
53.37 6.91 53.43 6.88 53.45 6.81 53.49 6.77 53.51 6.74 53.53 6.68 53.55 6.61 53.58 6.55 53.61 6.64
53.62 6.72 53.65 6.8 53.67 6.83 53.67 7.05 53.69 7.16 53.72 7.32 53.73 7.35 53.73 7.4 53.74 7.61
53.76 7.69 53.78 7.76 53.78 7.81 53.79 8.34 53.96 8.57 54.3 7.25 53.32</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMembers>
</gml:MultiSurface>
Annex, page 117
5 Constraints on polygons of geographical areas18
5.1 The following constraints, in addition to others specified in this section, should be
adhered to when defining geographical areas within the DDP for a particular Contracting
Government:
.1 InternalWaters polygons:
.1 The geographical coordinate points of all vertices should be in

degrees and decimal degrees to 2 decimal places;
.2 The average separation between adjacent vertices should not

be less than 6 nautical miles. For Contracting Governments
which are also Small Island Developing States19, the average
separation between adjacent vertices could be reduced to less
than 6 nautical miles, however it should not be reduced to less
than 2 nautical miles;
.3 The total number of vertices for all polygons should not be more
than 10,000 vertices; and
.4 The total number of polygons should not be more than 1,000

polygons.
.2 TerritorialSeas polygons:

degrees and decimal degrees to 2 decimal places;
.2 The average separation between adjacent vertices should not

be less than 6 nautical miles. For Contracting Governments
which are also Small Island Developing States20, the average
separation between adjacent vertices could be reduced to less
than 6 nautical miles, however it should not be reduced to less
than 2 nautical miles;
18
The Committee, at its eighty-sixth session, agreed that:
.1 Contracting Governments which are State Parties to either the United Nations Convention on the Law
of the Sea or the Convention on the Territorial Sea and the Contiguous Zone are expected to define the
geographical areas for the internal waters and the territorial seas for which they wish to see included in
the LRIT Data Distribution Plan in accordance with the provisions of the international treaty they are
party to;
.2 Contracting Governments which are neither State Parties to the United Nations Convention on the Law
of the Sea nor to the Convention on the Territorial Sea and the Contiguous Zone are expected to define
the geographical areas for the internal waters and the territorial seas for which they wish to see included
in the LRIT Data Distribution Plan in accordance with the provisions of international customary law as
agreed during MSC 84;
.3 Contracting Governments, if they so wish, have the option to advise the Organization and all other
Contracting Governments that they do not wish to provide geographical coordinates for either internal
waters and/or territorial seas and as a result they allow the other Contracting Governments to receive
LRIT information transmitted by all ships when within their internal waters and from ships entitled to fly
their flag when located within their territorial waters; and
.4 regulation V/19-1.13 already provides that Contracting Governments may report to the Organization any
case where they consider that provisions of this regulation or of any other related requirements
established by the Organization have not been or are not being observed or adhered to.
19
The Small Islands Developing States are listed by the United Nations at the following web address:
http://www.un.org/special-rep/ohrlls/sid/list.htm.
20
The Small Islands Developing States are listed by the United Nations at the following web address:
http://www.un.org/special-rep/ohrlls/sid/list.htm.
Annex, page 118
.4 The total number of polygons should not be more than 1,000

polygons.
.3 SeawardAreaOf1000NM polygons;

degrees and decimal degrees to two decimal places;
.2 The minimum separation between adjacent vertices should not be

less than 6 nautical miles (1% error rate) or the overall minimum
average (mean) distance between adjacent vertices should not be
less than 40 nautical miles;
.4 The total number of polygons should not be more than 10

polygons.
.4 CustomCoastalAreas polygon:

degrees and decimal degrees to two decimal places;
.2 The average separation between adjacent vertices should not be

less than 600 m;
.3 The total number of vertices for each polygon should not be more
than 100 vertices;
.4 The total number of polygons should not be more than 100

polygons; and
.5 All polygons should be entirely within the area covered by the

SeawardAreaOf1000NM and InternalWaters polygons.
5.2 In case any one of the geographical areas to be represented by the polygons
referred to in paragraph 5.1 straddles the meridian of 180 degrees longitude, the geographical
area in question should be represented by two polygons having a common boundary along
the 180 degrees longitude.
5.3 All polygons within each set of InternalWaters, TerritorialSeas,

SeawardAreaOf1000NM and CustomCoastalAreas should be disjoint (i.e. no overlap between
polygons within each set).
5.3.1 This constraint should be understood as not preventing adjacent polygons to have a
common boundary defined by the same geographical coordinate points, provided the
geographical area represented by the two polygons do not overlap.
Annex, page 119
5.4 All polygons should be technically valid, simple polygons (i.e. a simple polygon is
closed polygonal chain of line segments that do not cross each other). For any single polygon to
be a technically valid simple polygon, the following should be true:
.1 The polygon should be continuous and closed (i.e. the first and last vertices
should be identical), and should not contain any interior rings;
.2 The polygon should have at least four total vertices and three distinct
vertices (i.e. the first and last vertices are identical);
.3 The sides of the polygon should not intersect. In other words, the polygon
should not be self-intersecting; and
.4 The polygon should not contain duplicate vertices with the exception of the
first and last vertices being identical.
5.5 Contracting Governments claiming archipelagic State status should define polygons
in a manner that conforms with the purpose and the objectives of regulation V/19-1 and so as to
allow Contracting Governments, in a port or coastal State capacity and in accordance with the
provisions of regulation V/19-1, to request and be able to receive LRIT information transmitted
by ships when located within waters which they might be claiming in an archipelagic State
capacity.
6 The DDP server
6.1 The DDP server is the LRIT system component which holds all DDP information and
provides the following two interfaces:
.1 secure, web-based access (the web interface) to Contracting Governments

and other authorized users to view, insert, update and delete information,
as appropriate; and
.2 a Web service interface in compliance with the standards specified within

the Communications specifications, for the exchange of LRIT messages
with the IDE and DCs.
6.2 The DDP server is implemented as module of the Global Integrated Shipping
Information System (GISIS). With regards to LRIT and the DDP information, it integrates with
GISIS in the following respects:
.1 The IMO Web Accounts21 system is used for securing user access to the
system via a login and password, issued to authorized users with the
appropriate roles assigned;
.2 Common coding systems from GISIS are used where applicable, in

particular for country codes (based on ISO 3166 1:1997), ports (based on
UN/LOCODE) and port facilities;
21
Information on the IMO Web Accounts system is given in Circular letter No.2892.
Annex, page 120
.3 Data from other GISIS modules relevant to the DDP are sourced directly
from those modules. Specifically, this refers to information on port facilities
from the Maritime Security module, and information on SAR services from
the COMSAR module.
6.3 The users of the DDP module with respect to its web interface and the rights of
access of each type of user are specified in Table I-3 below.
Table I-3
Users of the LRIT Data Distribution Plan web interface
User Enter View Print Download Implement

Contracting Government Yes(1) Yes Yes Yes No
LRIT Data Centre Yes(2) Yes Yes Yes Yes
International LRIT Data Yes(2) Yes Yes Yes Yes
Exchange
LRIT Coordinator Yes(2) Yes Yes Yes(3) Yes(4)
Application Service Provider Yes(2) Yes Yes No No
Secretariat Yes Yes Yes Yes ---
Explanatory notes of terms used in Table I-1:
Enter means making, and amending existing, entries manually and making and
amending existing entries by uploading files or data.
View means viewing the data contained in the DDP.
Print means printing in a paper or file format the data contained in the DDP.
Download means downloading the data contained in the DDP in an XML22 format.
Implement means implementing the information provided by the data contained in

the DDP in the functioning of an LRIT Data Centre (DC) or the International LRIT
Data Exchange (IDE).
Yes(1) indicates that the right is restricted to information and data relating to the
Contracting Government concerned.
Yes(2) indicates that the right is restricted to information of administrative nature

relating to the DC, the IDE, the LRIT Coordinator or the Application Service Provider
as the case may be.
Yes(3) indicates that the right is restricted to purposes relating to the functions to be
performed by the LRIT Coordinator for example the performance review and audit of
a DC or the IDE or in relation to matters relating to the provisions of regulation
V/19-8.1 or V/19-1.9.
22
Extensible Markup Language (XML).
Annex, page 121
Yes(4) indicates that the LRIT Coordinator applies the information contained in the
DDP in connection with the functions it performs which is different from the
implementation of the DDP done by a DC or IDE.
6.4 Users authorized to access the web interface of DDP module of GISIS log in using
the established procedures, via the Members' Area of GISIS, in order to access and/or modify
DDP information as appropriate.
6.4.1 Additional procedures23, other than those applicable to the administration of user
accounts by the IMO Web Accounts administrator, apply in the case of authorization of users for
access to the web interface of the DDP module.
6.5 In the case of DDP information contained within other GISIS modules, such as with
the Maritime Security and COMSAR modules, users will need to have the appropriate
authorizations for those modules in order to perform the necessary actions.
6.5.1 Authorizations to other GISIS modules are granted in accordance with existing
procedures that have been established for them.
Communications within the LRIT system
6.6 The DDP server sends and receives LRIT SOAP messages, as defined in the
Communications specifications, from the IDE and DCs directly. Messages to and from DCs are
not relayed via the IDE.
6.7 The DDP server sends and/or accepts the following messages from recipient
components:
.1 SystemStatus (sent and received) A SystemStatus message is

transmitted to the IDE every 30 min, indicating the "health" of the DDP
server. In addition, upon receipt of a SystemStatus from a DC, the DDP
server will respond by sending a SystemStatus message back to the DC.
.2 Receipt (sent and received) Receipt messages are sent to any recipient
component in the event of an error being encountered by the DDP server,
as defined within the Technical specifications for communications within the
LRIT system. The DDP server will accept Receipt messages from any
recipient component, with any further processing.
.3 DDPNotification (sent only) DDPNotification messages are sent by the

DDP server upon the publishing either of a regular version or of an
immediate version of the DDP.
Upon receipt of DDPNotification, recipient components should send a

DDPRequest message to the DDP server the with the appropriate
parameters in order to be sent an incremental update identifying the
changes in DDP information.
23
Details to be issued under a separate cover.
Annex, page 122
.4 DDPRequest (received only) DDPRequest messages may be sent by

recipient components at any time in order to request either a full DDP at a
particular version, current or archived, or an incremental update relative to
the version they are currently implementing (see paragraph 6.7).
Recipient components should send a DDPRequest message upon, or

shortly after, receipt of a DDPNotification message from the DDP server.
.5 DDPUpdate (sent only) This message is sent by the DDP server (only)
upon receipt of a DDPRequest message from recipient components. It
contains as an attachment either a full DDP or an incremental update,
depending on the parameters specified in the received DDPRequest.
6.8 When requesting incremental updates, the following values for the UpdateType
parameter of the message may be specified:
.1 Regular Incremental updates a request for changes to regular DDP

information only, made between the most recently published regular
version of the DDP and the regular version currently implemented by the
requesting component (as specified in the request message);
.2 Immediate Incremental updates a request for changes to immediate

DDP information only, made between the most recently published
immediate version and the immediate version currently implemented by the
requesting component (as specified in the request message); and
.3 All Incremental updates a request for all changes to both regular and
immediate DDP information made between the most recently published
regular versions and immediate version respectively, and the DDP version
currently implemented by the requesting component (as specified in the
request message).
6.9 With reference to the example timeline given in Figure I-1 of section 2, Table I-4,
below, illustrates the contents of the incremental update sent by the DDP server in response to a
DDPRequest message from a recipient component, depending on the version of the DDP it has
implemented and the type(s) of update it is requesting:
Table I-4
Illustrative example of the contents of the Incremental Update

(in relation to the information provided in figure I-1)
Versions returned in
DDP version Time of Incremental Update
implemented request Requested
Example by requestor (on 2 June) Update Type Regular Immediate
1 81:66 10:12 Immediate - 67, 68
2 81:65 05:15 Regular 82 -
3 81:65 05:15 Immediate - 66
4 81:65 05:15 All updates 82 66
5 80:64 13:00 All updates 81, 82 65, 66, 67, 68
Annex, page 123
Part II
Timeline for DDP activation, population and implementation
1 Establishment of the LRIT system
1.1 The LRIT system is to be established and should be operational at 00:00 UTC
on 31 December 2008.
1.2 All Contracting Governments, pursuant to the provisions of regulation V/19-1.8.2 and
taking the related provisions of the Performance standards, should communicate to the
Organization and enter into the DDP all required information in order to enable the establishment
of the LRIT system in a timely manner.
1.3 DCs and the IDE should download and implement the contents of the DDP in a
timely manner before the LRIT system is scheduled to become operational.
1.4 Section 2 outlines the proposed timeline to be adopted with regards to the initial
population of the DDP before the system becomes operational, and the timely downloading and
implementation of the first version of the DDP by DCs and the IDE.
2 Timeline for the initial population and implementation of the DDP
2.1 The DDP will be made available for data population by Contracting Governments
on 1 November 2008.
2.2 Contracting Governments should enter into the DDP all required information
by 12:00 UTC on 19 December 2008.
2.3 The DDP web interface will not be available for Contracting Governments to insert or
amend any information between 12:01 UTC on 19 December 2008 and 12:00 UTC
on 5 January 2009.
2.3.1 This is to provide DCs and the IDE with a stable version of the DDP to download and
implement by 00:00 UTC on 31 December 2008.
2.4 DCs and the IDE should download the version of the DDP which is current at 00:00
UTC on 20 December 2008.
2.5 By 00:00 UTC on 31 December 2008, the latest version (the one current at 00:00
UTC on 20 December 2008) of the DDP should be implemented by DCs and the IDE.
2.6 At 12:00 UTC on 5 January 2009, the DDP web interface will be made available
again for Contracting Governments to insert or amend information in the DDP.
2.7 Subject to the provisions of paragraph 2.3, the LRIT system, including the DDP
server, will be fully operational from 00:00 UTC on 31 December 2008. From this point in time,
notifications of updates to the DDP (immediate and regular) will be transmitted as specified in
this document.
Figure illustrating the implementation timeline
2.8 Figure II-1, below, illustrates the timeline described above.
Annex, page 124
Figure II-1
DDP Implementation Timeline
DDP version number

x:y
y+1 x+1
time = 00:00 Sample Regular and Immediate updates
after 5 January 2009 12:00 UTC time = 17:24 time = 00:00
... ...
( DDP web interface available ( DDP web interface available
00:00 until 12:00 UTC) 12:00 ( DDP web interface
not available) 00:00 ( DDP web interface
not available)00:00 ( DDP web interface
not available) 12:00 after 12:00 UTC) 00:00
19 December 2008 20 - 30 December 2008 31 December 2008 1 - 4 January 2009 5 January 2009 6 January 2009
x:y
time = 00:00
Sample implementation times corresponding
to sample Regular and Immediate updates x:y+1
time = 18:24
Annex, page 125
3 Implementation of the DDP as from 12:00 UTC on 5 January 2009
3.1 Table II-1 below sets out guidelines with regards to the implementation of the DDP
by DCs and the IDE as from 12:00 UTC on 5 January 2009:
Annex, page 126
Table II-1
Elements of the DDP and related cut-off and implementation times

for new entries or amendments to existing ones
Note: The table below sets out in the column headed "Case" only the elements of the DDP which have an impact on the functioning of the LRIT
system. Elements of the DDP which are of administrative or informative nature are not cited as they do not affect the functioning of the LRIT
system.
Cut off time

for including new entries and
for amending existing ones
__________ IDE and all DCs
should implement the
Publishing time of the resulting new version
No. Case new version of the DDP of the DDP at Comments
1 Contracting Government enters information 23:59 UTC daily 00:00 UTC the day after The functioning of the LRIT system should
on any of its geographical areas (polygons _______ publishing not be affected due to the failure of a
defined as Internal Waters, Territorial Sea, Contracting Government to discharge its
Seaward Outer Boundary of 1000NM, or 00:00 UTC daily obligations under regulation V/19-1.8.2 in a
Custom Coastal Areas), or amends or timely manner
deletes such entries
Annex, page 127
Cut off time

2 Administration exercises it rights pursuant Not applicable One h after the time of Regulation V/19-1.9.1 states that an
to the provision of regulation V/19-1.9.1, or _______ publishing. Administration is able to exercise the right at
amends or withdraws its decision to any time.
suspend the provision of LRIT information An Immediate Version of the DDP
to the requesting DCs affected by its will be published by the DDP server The obligation to comply becomes binding
decision. as soon as the Administration (or the on all DCs as from the time the Organization
Secretariat, in case of informs Contracting Governments of receipt
(The Administration, if the circumstance so communications sent to the of such communication or as from a later
warrant, may direct the DC to which ships Organization) makes the related time if such time is specified in the
entitled to fly its flag transmit LRIT entry in the DDP. communication received by the
information to suspend the provision of Organization.
LRIT information to the requesting DCs
affected by its decision prior to DCs other than the DC serving the
communicating its decision to the Administration are not affected.
Organization (or making the necessary
entry in the DDP). In such a case the Regulation V/19-1.9.1 should not be read as
Administration should communicate its allowing an Administration to reduce the
decision to the Organization (or make the 1,000 nautical miles distance and when
necessary entry in the DDP) within one h as invoked it entails the suspension of the
from the time it has directed so the DC provisions of LRIT information pursuant to
concerned.) regulation V/19-1.8.1.3.
The DDP server should also notify (by

e-mail) the LRIT Coordinator.
3 A State becoming a Contracting 23:59 UTC daily 00:00 UTC the day after The Convention enters into force with
Government. _______ publishing. respect to that State three months after the
deposit of the instrument of accession. The
00:00 UTC daily State may provide the information well in
advance.
Annex, page 128
Cut off time

4 Contracting Government extends the 23:59 UTC daily 00:00 UTC the day after The Convention enters into force with
application of the Convention to a _______ publishing. respect to the non-metropolitan area as from
non-metropolitan area where it did not the time of deposit of the declaration or as
previously apply, or terminates the 00:00 UTC daily from the time stated in such declaration.
application of the Convention to a Contracting Governments should time the
non-metropolitan area where it previously deposit of such declarations accordingly.
applied. Alternatively, the Committee may agree that
such declarations become effective at
12:00 UTC of the second day following the
deposit of the declaration if they do not
specify a later time.
5 Contracting Government establishes new 23:59 UTC daily 00:00 UTC the day after As case 1
search and rescue services or makes _______ publishing.
amendments to existing search and rescue
services. 00:00 UTC daily
Annex, page 129
Cut off time

6 Contracting Government as a coastal State Not applicable One h after the time of Contracting Governments may select from
makes a change to the list of areas _______ publishing. their defined geographical areas (of Internal
constituting its standing order, either to add Waters, Territorial Sea, Seaward Outer
or remove areas within which the An Immediate Version of the DDP Boundary of 1000NM and Custom Coastal
Contracting Government is seeking the will be published by the DDP server Areas) the set of areas which constitute their
provision of LRIT information pursuant to as soon as the Administration makes coastal State standing order.
the provisions of regulation V/19-1.8.1.3. the related entry in the DDP.
Only geographical areas which are
implemented within the LRIT system at a
particular time may be selected as part of a
standing order at that time.
If a new definition of a geographical area is

to be introduced, the provisions of case 1
apply, and the new area may be selected as
part of the standing order only after the
corresponding published DDP version has
been implemented by the IDE and all DCs.
7 Contracting Government recognizes new 23:59 UTC daily 00:00 UTC the day after As case 1
ASPs or withdraws the recognition from _______ publishing.
previously recognized ASPs.
00:00 UTC daily
Annex, page 130
Cut off time

8 Contracting Government establishes new Not applicable 00:00 UTC the day after As case 1
LRIT Data Centre or changes the LRIT Data _______ publishing.
Centre from which it requests and receives
LRIT information. A Regular Version of the DDP will be
published by the DDP server at
00:00 UTC following the day in which
the Secretariat, upon receipt of
communications from the
Administration with information on
the new arrangements relating to its
Data Centre, enters this information
into the DDP.
9 Contracting Government changes Not applicable One h after the time of -
particulars relating to its established Data _______ publishing.
Centre (e.g., its web service endpoint URI).
An Immediate Version of the DDP
will be published by the DDP server
as soon as the Administration makes
the related entry in the DDP.
10 Contracting Government is including 23:59 UTC daily 00:00 UTC the day after As case 1
information on ports and port facilities _______ publishing.
located within its territory and on places
under its jurisdiction to which ships which 00:00 UTC daily
are required to comply with the provisions of
regulation V/19-1 may enter or proceed to,
or amend such information.
Annex, page 131
Annex 5
Criteria for the location of the

International LRIT Data Centre and the International LRIT Data Exchange
Physical location
1 The physical location of the IDC and IDE should be such so as to ensure that the
IDC and IDE meet the availability requirements and provide the expected quality of service.
2 The physical location of the IDC and IDE, including any backup sites should be
accessible to the LRIT Co-ordinator.
3 The IDC and IDE should have a disaster recovery site accessible every day of the
year 24 h a day.
4 The IDC and IDE should have adequate physical security including protection from,
inter alia, vandalism, environmental disasters and fire.
Communications infrastructure
5 The IDC should have access to reliable and adequate communication networks so
as to have the needed links with Application Service Providers(s), Communications Service
Provider(s), the IDE, other DCs and the DDP.
6 The IDE should have access to reliable and adequate communication networks so
as to have the needed links with the IDC, other DCs and the DDP.
7 The IDC and IDE should have access to reliable and adequate communication
networks to enable the LRIT Co-ordinator to have remote access to the IDC and the IDE.
8 The IDC and IDE should be able to accommodate multiple internet service providers
(ISP).
9 The ISP links should be, if possible, fibre optic with satellite communications for
back up. However, terrestrial microwave communications may also serve in a back up capacity.
10 The IDC and IDE should have the required redundant firewalls to ensure the required
data integrity.
11 Although it is expected that communications links with the IDC and IDE will likely be
over the internet, leased lines may also be used however, in no case should broadcast
connections be used for any links within the LRIT system.
12 All communications links should have adequate and scaleable data bandwidth.
Supply of power
13 The IDC and IDE should be provided with an adequate power from a main,
transitional and emergency power source so as to ensure their uninterrupted functioning and in
order to meet the availability requirements.
Annex, page 132
Equipment and spare parts
14 The IDC and IDE should have local backup servers with seamless switch-over
between servers locally.
15 The IDC and IDE should also have remote backup servers which should have close
to seamless switch-over.
16 The IDC and IDE should have redundancy in IDC and IDE equipment.
17 The main and backup equipments and systems of the IDC and IDE should be
geographically distributed to the extent that is practically and reasonably possible.
18 The IDC and IDE should be provided with an adequate supply of spare parts or
should have arrangements in place which ensure the prompt and timely delivery of any needed
spare parts.
Availability
19 The IDC and IDE should operate 24 h a day 7 days a week with an availability
of 99.9% over the year and 95% over any day.
Observation
20 The above criteria, although they have been developed in relation to location of the
IDC and IDE, should be considered as applying equally to all DCs and the DDP.
Annex, page 133
Annex 6
XML schemas
LRIT XML Resources ReadMe file

===============================
Release Version: 1.3
Release Date: 07 December 2010
===============================
XSDs
--------
File Version Date
------------------------------------------------------------------------------------
DDP.xsd 1.2 24 Oct 2008
DDPNotification.xsd 1.0 22 Aug 2008
DDPRequest.xsd 1.1 24 Oct 2008
DDPUpdate.xsd 1.1 24 Sept 2008
JournalReport.xsd 1.0 22 Aug 2008
PricingFile.xsd 1.0 22 Aug 2008
PricingNotification.xsd 1.0 22 Aug 2008
PricingRequest.xsd 1.1 24 Oct 2008
PricingUpdate.xsd 1.1 24 Oct 2008
Receipt.xsd 1.0 22 Aug 2008
SARSURPICRequest.xsd 1.1 24 Oct 2008
ShipPositionReport.xsd 1.1 24 Oct 2008
ShipPositionRequest.xsd 1.0 22 Aug 2008
SystemStatus.xsd 1.0 22 Aug 2008
Types.xsd 1.2 07 Dec 2010
WSDLs
-----------
File Version Date
------------------------------------------------------------------------------------
DC.wsdl 1.0 22 Aug 2008
DDP.wsdl 1.0 22 Aug 2008
IDE-DC.wsdl 1.0 22 Aug 2008
IDE-DDP.wsdl 1.0 22 Aug 2008
Note:
Release Version is incremented if any file within this set is updated. This is the number that
should be placed in the schemaVersion attribute of all LRIT SOAP messages.
Each file in this set has its own Version number to track changes to that file, independently of
other files within the set. This number is not used in any LRIT SOAP message.
Changelog
-------------
22 Aug 2008 - Release Version 1.0

--------------------------------------------
* First versioned release of the LRIT XML files.
Annex, page 134
24 Sept 2008 - Release Version 1.1

--------------------------------------------
* Updated DDP.xsd to:
- Remove Exclusion as a Regular datatype
- Add DDPServer and IDE as Immediate datatypes, and LRITCoordinator as Regular
- Remove "minOccurs = 0" on names of ports, facilities and places
* Updated DDPUpdate.xsd to:

- Add ReferenceId element with reference message ID
24 Oct 2008 - Release Version 1.2

-------------------------------------------
* Updated DDP.xsd to:
- Add "minOccurs=0" for Data Centre contact points
- Add Internal Waters to coastalStateStandingOrderAreasIDType
* Updated DDPRequest.xsd to:
- Add ReferenceId element with optional reference message ID
* Updated PricingRequest.xsd to:
- Add ReferenceId element with optional reference message ID
* Updated PricingUpdate.xsd to:
- Add ReferenceId element with reference message ID
* Updated SARSURPICRequest.xsd to:
- Restrict maximum number of positions to 4
- Corrected coordinate patterns for circular and rectangular areas
* Updated ShipPositionReport.xsd to:
- Restore CSPID parameter
* Updated Types.xsd to:
- Define CSP LRIT ID type for update to ShipPositionReport.xsd
07 Dec 2010 - Release Version 1.3

-------------------------------------------
* Updated Types.xsd to:
- Changed percentageValueType restriction to "<xs:pattern value="[0-9]+(\.[0-
9]{1,2})?"/>"
- Changed priceValueType restriction to "<xs:pattern value="[0-9]+(\.[0-9]{1,4})?"/>"
Annex, page 135
XSD files
DDP.xsd file

<xs:schema version="1.0" targetNamespace="http://gisis.imo.org/XML/LRIT/ddp/2008" xmlns="http://gisis.imo.org/XML/LRIT/ddp/2008"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:lrit="http://gisis.imo.org/XML/LRIT/types/2008" elementFormDefault="qualified">
<xs:import namespace="http://gisis.imo.org/XML/LRIT/types/2008" schemaLocation="Types.xsd"/>


<xs:simpleType name="iso3166-1Alpha3CodeType">
<xs:restriction base="xs:string">
<xs:pattern value="[A-Z]{3}"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="mmsiType">
<xs:pattern value="[0-9]{9}"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="contactIDType">
<xs:pattern value="CPN1[0-9]{3}_[0-9]+"/>
<xs:pattern value="CPDCINF1[0-9]{3}_[0-9]+"/>
<xs:pattern value="CPASPINF1[0-9]{3}_[0-9]+"/>
<xs:pattern value="CPSAR2[0-9]{3}_[0-9]+"/>
<xs:pattern value="CPDC3[0-9]{3}_[0-9]+"/>
<xs:pattern value="CPASP4[0-9]{3}_[0-9]+"/>
<xs:pattern value="CPDDP0001_[0-9]+"/>
<xs:pattern value="CPIDE0002_[0-9]+"/>
<xs:pattern value="CPLC0003_[0-9]+"/>
</xs:restriction>
Annex, page 136
</xs:simpleType>
<xs:simpleType name="dcInfoIDType">
<xs:pattern value="DCINF1[0-9]{3}"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="aspInfoIDType">
<xs:pattern value="ASPINF1[0-9]{3}_[0-9]+"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="exclusionIDType">
<xs:pattern value="EXCL1[0-9]{3}_[0-9]+"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="coastalStateStandingOrderAreasIDType">
<xs:pattern value="GA(IW|TS|OT|CA)1[0-9]{3}_[0-9]+"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="coastalStateStandingOrderAreasIDListType">
<xs:list itemType="coastalStateStandingOrderAreasIDType"/>
</xs:simpleType>
<xs:simpleType name="sarFacilityTypeType">
<xs:enumeration value="RB"/>
<xs:enumeration value="RV"/>
<xs:enumeration value="SRG"/>
<xs:enumeration value="MRG"/>
<xs:enumeration value="LRG"/>
<xs:enumeration value="VLR"/>
<xs:enumeration value="ELR"/>
<xs:enumeration value="HEL-L"/>
<xs:enumeration value="HEL-M"/>
<xs:enumeration value="HEL-H"/>
<xs:enumeration value="GSU"/>
<xs:enumeration value="MAU"/>
Annex, page 137
<xs:enumeration value="UIU"/>
<xs:enumeration value="DUIU"/>
<xs:enumeration value="FFU"/>
<xs:enumeration value="IRU"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="sarFacilityTypeListType">
<xs:list itemType="sarFacilityTypeType"/>
</xs:simpleType>

<xs:complexType name="contactPointType">
<xs:sequence>
<xs:element name="Type">
<xs:simpleType>
<xs:enumeration value="Primary"/>
<xs:enumeration value="Alternate"/>
<xs:enumeration value="Operational"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="Title" type="xs:string" minOccurs="0"/>
<xs:element name="FirstName" type="xs:string" minOccurs="0"/>
<xs:element name="LastName" type="xs:string" minOccurs="0"/>
<xs:element name="Department" type="xs:string" minOccurs="0"/>
<xs:element name="Position" type="xs:string" minOccurs="0"/>
<xs:element name="AddressLine1" type="xs:string" minOccurs="0"/>
<xs:element name="AddressCity" type="xs:string" minOccurs="0"/>
<xs:element name="AddressPostcode" type="xs:string" minOccurs="0"/>
<xs:element name="AddressState" type="xs:string" minOccurs="0"/>
<xs:element name="AddressCountry" type="xs:string" minOccurs="0"/>
<xs:element name="Telephone" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="Fax" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="Email" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="Website" type="xs:anyURI" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
Annex, page 138
<xs:attribute name="contactID" type="contactIDType" use="required"/>

</xs:complexType>
<xs:complexType name="dataCentreType">
<xs:sequence>
<xs:element name="Type">
<xs:simpleType>
<xs:enumeration value="International"/>
<xs:enumeration value="National"/>
<xs:enumeration value="Regional"/>
<xs:enumeration value="Cooperative"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="Name" type="xs:string"/>
<xs:element name="IDEInterfaceWebServiceLocation" type="xs:anyURI"/>
<xs:element name="DDPInterfaceWebServiceLocation" type="xs:anyURI"/>
<xs:element name="ContactPoint" type="contactPointType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="AdditionalInformation" type="xs:string" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="lritID" type="lrit:dataCentreLRITIDType"/>
</xs:complexType>
<xs:complexType name="aspType">
<xs:sequence>
</xs:sequence>
<xs:attribute name="lritID" type="lrit:aspLRITIDType"/>
</xs:complexType>
<xs:complexType name="dataCentreInfoType">
<xs:sequence>
<xs:element name="DataCentreID" type="lrit:dataCentreLRITIDType"/>
</xs:sequence>
<xs:attribute name="dcInfoID" type="dcInfoIDType" use="required"/>
</xs:complexType>
<xs:complexType name="sarServiceType">
<xs:sequence>
Annex, page 139
<xs:element name="MMSI" type="mmsiType" minOccurs="0"/>

<xs:element name="CallSign" type="xs:string" minOccurs="0"/>
<xs:element name="VHFVoiceCallSign" type="xs:string" minOccurs="0"/>
<xs:element name="Telephone" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="Fax" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="Email" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="Telex" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="OtherLandlineComms" type="xs:string" minOccurs="0"/>
<xs:element name="AvailableFacilities" type="sarFacilityTypeListType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="lritID" type="lrit:sarServiceLRITIDType" use="required"/>
</xs:complexType>
<xs:complexType name="aspInfoType">
<xs:sequence>
<xs:element name="ASPID" type="lrit:aspLRITIDType"/>
<xs:element name="Conditions" type="xs:string" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="aspInfoID" type="aspInfoIDType" use="required"/>
</xs:complexType>
<xs:complexType name="placeType">
<xs:sequence>
<xs:element name="Position" type="lrit:posType"/>
</xs:sequence>
<xs:attribute name="placeCode" type="lrit:placeCodeType" use="required"/>
</xs:complexType>
<xs:complexType name="portFacilityType">
<xs:sequence>
</xs:sequence>
<xs:attribute name="imoPortFacilityNumber" type="lrit:imoPortFacilityNumberType" use="required"/>
</xs:complexType>
<xs:complexType name="portType">
<xs:sequence>
Annex, page 140

</xs:sequence>
<xs:attribute name="locode" type="lrit:locodeType" use="required"/>
</xs:complexType>
<xs:complexType name="exclusionType">
<xs:sequence>
<xs:element name="ExcludedContractingGovernmentID" type="lrit:contractingGovernmentLRITIDType"/>
<xs:element name="From" type="xs:dateTime" minOccurs="0"/>
<xs:element name="Until" type="xs:dateTime" minOccurs="0"/>
<xs:element name="Reason" type="xs:string" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="contractingGovernmentID" type="lrit:contractingGovernmentLRITIDType"
use="required"/>
<xs:attribute name="exclusionID" type="exclusionIDType" use="required"/>
</xs:complexType>
<xs:complexType name="coastalStateStandingOrderType">
<xs:simpleContent>
<xs:extension base="coastalStateStandingOrderAreasIDListType">
use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="ddpServerType">
<xs:sequence>
<xs:element name="WebServiceLocation" type="xs:anyURI"/>
<xs:element name="ContactPoint" type="contactPointType" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="lritID" type="lrit:ddpServerLRITIDType"/>
</xs:complexType>
<xs:complexType name="ideType">
<xs:sequence>
<xs:element name="DCInterfaceWebServiceLocation" type="xs:anyURI"/>
<xs:element name="DDPInterfaceWebServiceLocation" type="xs:anyURI"/>
Annex, page 141

</xs:sequence>
<xs:attribute name="lritID" type="lrit:ideLRITIDType"/>
</xs:complexType>
<xs:complexType name="lritCoordinatorType">
<xs:sequence>
</xs:sequence>
<xs:attribute name="lritID" type="lrit:lritCoordinatorLRITIDType"/>
</xs:complexType>

<xs:complexType name="regularIncrementableType">
<xs:choice>
<xs:element name="ContractingGovernment" type="contractingGovernmentType"/>
<xs:element name="Territory" type="territoryType"/>
<xs:element name="ContactPoint" type="contactPointType"/>
<xs:element name="ASPInfo" type="aspInfoType"/>
<xs:element name="SARService" type="sarServiceType"/>
<xs:element name="Port" type="portType"/>
<xs:element name="PortFacility" type="portFacilityType"/>
<xs:element name="Place" type="placeType"/>
<xs:element name="Polygon" type="lrit:polygonType"/>
<xs:element name="DataCentreInfo" type="dataCentreInfoType"/>
<xs:element name="ASP" type="aspType"/>
</xs:choice>
<xs:attribute name="xPath" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="immediateIncrementableType">
<xs:choice>
<xs:element name="StandingOrder" type="coastalStateStandingOrderType"/>
<xs:element name="Exclusion" type="exclusionType"/>
<xs:element name="DataCentre" type="dataCentreType"/>
</xs:choice>
<xs:attribute name="xPath" type="xs:string" use="required"/>
</xs:complexType>

Annex, page 142
<xs:complexType name="contractingGovernmentType">
<xs:sequence>
<xs:element name="Name">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="isoCode" type="iso3166-1Alpha3CodeType"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="NationalPointsOfContact">
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="DataCentreInfo" type="dataCentreInfoType"/>
<xs:element name="ASPInfo" type="aspInfoType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="SARServices">
<xs:complexType>
<xs:sequence>
<xs:element name="SARService" type="sarServiceType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Ports">
<xs:complexType>
<xs:sequence>
<xs:element name="Port" type="portType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="PortFacilities">
<xs:complexType>
<xs:sequence>
<xs:element name="PortFacility" type="portFacilityType" minOccurs="0" maxOccurs="unbounded"/>
Annex, page 143
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Places">
<xs:complexType>
<xs:sequence>
<xs:element name="Place" type="placeType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="InternalWaters">
<xs:complexType>
<xs:sequence>
<xs:element name="Polygon" type="lrit:polygonType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="TerritorialSea">
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="SeawardAreaOf1000NM">
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="CustomCoastalAreas">
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
Annex, page 144
</xs:sequence>
<xs:attribute name="lritID" type="lrit:contractingGovernmentLRITIDType" use="required"/>
</xs:complexType>
<xs:complexType name="territoryType">
<xs:complexContent>
<xs:extension base="contractingGovernmentType">
use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>

<xs:element name="DataDistributionPlan">
<xs:complexType>
<xs:sequence>
<xs:element name="ContractingGovernment" type="contractingGovernmentType" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="Territory" type="territoryType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="CoastalStateStandingOrders">
<xs:complexType>
<xs:sequence>
<xs:element name="StandingOrder" type="coastalStateStandingOrderType" minOccurs="0"
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Exclusions">
<xs:complexType>
<xs:sequence>
<xs:element name="Exclusion" type="exclusionType" minOccurs="0"
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="DataCentres">
<xs:complexType>
<xs:sequence>
Annex, page 145
<xs:element name="DataCentre" type="dataCentreType" minOccurs="0"

</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ASPs">
<xs:complexType>
<xs:sequence>
<xs:element name="ASP" type="aspType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="DDPServer" type="ddpServerType"/>
<xs:element name="IDE" type="ideType"/>
<xs:element name="LRITCoordinator" type="lritCoordinatorType"/>
</xs:sequence>
<xs:attribute name="versionNum" type="lrit:ddpVersionNumType" use="required"/>
<xs:attribute name="regularVersionPublishedAt" type="xs:dateTime" use="required"/>
<xs:attribute name="regularVersionImplementationAt" type="xs:dateTime"
use="required"/>
<xs:attribute name="immediateVersionPublishedAt" type="xs:dateTime" use="required"/>
<xs:attribute name="immediateVersionImplementationAt" type="xs:dateTime" use="required"/>
<xs:attribute name="schemaVersion" type="xs:decimal" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="DataDistributionPlan-IncrementalUpdate">
<xs:complexType>
<xs:sequence>
<xs:element name="Regular" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="Delete" type="regularIncrementableType"/>
<xs:element name="Insert" type="regularIncrementableType"/>
<xs:element name="Update" type="regularIncrementableType"/>
</xs:choice>
<xs:attribute name="baseRegularVersionNum" type="xs:int" use="required"/>
<xs:attribute name="targetRegularVersionNum" type="xs:int" use="required"/>
<xs:attribute name="targetPublishedAt" type="xs:dateTime" use="required"/>
Annex, page 146
<xs:attribute name="targetImplementationAt" type="xs:dateTime" use="required"/>

</xs:complexType>
</xs:element>
<xs:element name="Immediate" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="Delete" type="immediateIncrementableType"/>
<xs:element name="Insert" type="immediateIncrementableType"/>
<xs:element name="Update" type="immediateIncrementableType"/>
</xs:choice>
<xs:attribute name="baseImmediateVersionNum" type="xs:int" use="required"/>
<xs:attribute name="targetImmediateVersionNum" type="xs:int" use="required"/>
<xs:attribute name="targetPublishedAt" type="xs:dateTime" use="required"/>
<xs:attribute name="targetImplementationAt" type="xs:dateTime" use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="baseRegularVersionNum"
type="lrit:ddpIncrementalVersionNumType"/>
<xs:attribute name="targetRegularVersionNum" type="lrit:ddpIncrementalVersionNumType"/>
<xs:attribute name="baseImmediateVersionNum" type="lrit:ddpIncrementalVersionNumType"/>
<xs:attribute name="targetImmediateVersionNum" type="lrit:ddpIncrementalVersionNumType"/>
</xs:complexType>
</xs:element>
</xs:schema>
Annex, page 147
DDPNotification.xsd file

<xs:schema version="1.0" targetNamespace="http://gisis.imo.org/XML/LRIT/ddpNotification/2008" xmlns="http://gisis.imo.org/XML/LRIT/ddpNotification/2008"
<xs:simpleType name="messageTypeType">
<xs:restriction base="xs:integer">
<xs:enumeration value="8"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="DDPNotification" type="DDPNotificationType"/>

<xs:complexType name="DDPNotificationType">
<xs:sequence>
<xs:element name="MessageType" type="messageTypeType"/>
<xs:element name="MessageId" type="lrit:msgIDType"/>
<xs:element name="UpdateType">
<xs:simpleType>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="Message" type="lrit:messageType"/>
<xs:element name="TimeStamp" type="xs:dateTime"/>
<xs:element name="NewVersionNum" type="lrit:ddpIncrementalVersionNumType"/>
</xs:sequence>
<xs:attribute name="test" type="lrit:testType" use="optional" default="0"/>
</xs:complexType>
</xs:schema>
Annex, page 148
DDPRequest.xsd file

<xs:schema version="1.0" targetNamespace="http://gisis.imo.org/XML/LRIT/ddpRequest/2008" xmlns="http://gisis.imo.org/XML/LRIT/ddpRequest/2008"
</xs:restriction>
</xs:simpleType>
<xs:element name="DDPRequest" type="DDPRequestType"/>

<xs:complexType name="DDPRequestType">
<xs:sequence>
<xs:element name="ReferenceId" type="lrit:refIDType"/>
<xs:simpleType>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="ArchivedDDPVersionNum" type="lrit:ddpVersionNumType" minOccurs="0"/>
<xs:element name="ArchivedDDPTimeStamp" type="xs:dateTime" minOccurs="0"/>
Annex, page 149
<xs:element name="Originator" type="lrit:lritIDType"/>

<xs:element name="DDPVersionNum" type="lrit:ddpVersionNumType"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Annex, page 150
DDPUpdate.xsd file

<xs:schema version="1.0" targetNamespace="http://gisis.imo.org/XML/LRIT/ddpUpdate/2008" xmlns="http://gisis.imo.org/XML/LRIT/ddpUpdate/2008"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:lrit="http://gisis.imo.org/XML/LRIT/types/2008" xmlns:xmime="http://www.w3.org/2005/05/xmlmime"
elementFormDefault="qualified">
</xs:restriction>
</xs:simpleType>
<xs:element name="DDPUpdate" type="DDPUpdateType"/>

<xs:complexType name="DDPUpdateType">
<xs:sequence>
<xs:simpleType>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="DDPFileVersionNum" type="lrit:ddpVersionNumOrIncrementalVersionType"/>
Annex, page 151
<xs:element name="DDPFile" type="xs:base64Binary" xmime:expectedContentTypes="application/zip"/>

</xs:sequence>
</xs:complexType>
</xs:schema>
Annex, page 152
JournalReport.xsd file

<xs:schema version="1.0" targetNamespace="http://gisis.imo.org/XML/LRIT/journalReport/2008" xmlns="http://gisis.imo.org/XML/LRIT/journalReport/2008"
</xs:restriction>
</xs:simpleType>
<xs:element name="JournalReport" type="JournalReportType"/>

<xs:complexType name="JournalReportType">
<xs:sequence>
<xs:element name="JournalFile" type="xs:base64Binary" xmime:expectedContentTypes="application/zip"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Annex, page 153
PricingFile.xsd file

<xs:schema version="1.0" targetNamespace="http://gisis.imo.org/XML/LRIT/pricingFile/2008" xmlns="http://gisis.imo.org/XML/LRIT/pricingFile/2008"
<xs:simpleType name="lritIDTypeList">
<xs:list itemType="lrit:lritIDType"/>
</xs:simpleType>
<xs:element name="PricingFile">
<xs:complexType>
<xs:sequence>
<xs:element name="PriceList" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="dataProviderID" type="lritIDTypeList"/>
<xs:element name="BreakDown" maxOccurs="unbounded">

<xs:complexType>
<xs:sequence>
<xs:element name="Poll" type="lrit:priceValueType"/>
<xs:element name="PeriodicRateChange"
type="lrit:priceValueType"/>
<xs:element name="PositionReport" type="lrit:priceValueType"/>
<xs:element name="ArchivePositionReport"
type="lrit:priceValueType"/>
</xs:sequence>
<xs:attribute name="currency" type="lrit:currencyType"/>
Annex, page 154
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="dataCentreID" type="lrit:lritIDType" use="required"/>
<xs:attribute name="issueDate" type="xs:date"/>
<xs:attribute name="effectiveDate" type="xs:date"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Annex, page 155
PricingNotification.xsd file

<xs:schema version="1.0" targetNamespace="http://gisis.imo.org/XML/LRIT/pricingNotification/2008"
xmlns="http://gisis.imo.org/XML/LRIT/pricingNotification/2008" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:lrit="http://gisis.imo.org/XML/LRIT/types/2008" elementFormDefault="qualified">

</xs:restriction>
</xs:simpleType>
<xs:element name="PricingNotification" type="PricingNotificationType"/>

<xs:complexType name="PricingNotificationType">
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:schema>
Annex, page 156
PricingRequest.xsd file

<xs:schema version="1.0" targetNamespace="http://gisis.imo.org/XML/LRIT/pricingRequest/2008" xmlns="http://gisis.imo.org/XML/LRIT/pricingRequest/2008"
</xs:restriction>
</xs:simpleType>
<xs:element name="PricingRequest" type="PricingRequestType"/>

<xs:complexType name="PricingRequestType">
<xs:sequence>
<xs:element name="Originator" type="lrit:dataCentreLRITIDType"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Annex, page 157
PricingUpdate.xsd file

<xs:schema version="1.0" targetNamespace="http://gisis.imo.org/XML/LRIT/pricingUpdate/2008" xmlns="http://gisis.imo.org/XML/LRIT/pricingUpdate/2008"
</xs:restriction>
</xs:simpleType>
<xs:element name="PricingUpdate" type="PricingUpdateType"/>

<xs:complexType name="PricingUpdateType">
<xs:sequence>
<xs:element name="ReferenceId" type="lrit:msgIDType"/>
<xs:element name="PricingFile" type="xs:base64Binary" xmime:expectedContentTypes="application/zip"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Annex, page 158
Receipt.xsd file

<xs:schema version="1.0" targetNamespace="http://gisis.imo.org/XML/LRIT/receipt/2008" xmlns="http://gisis.imo.org/XML/LRIT/receipt/2008"
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="receiptCodeType">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="256"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="Receipt" type="ReceiptType"/>

<xs:complexType name="ReceiptType">
<xs:sequence>
Annex, page 159

<xs:element name="ReceiptCode" type="receiptCodeType"/>
<xs:element name="Destination" type="lrit:lritIDType"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Annex, page 160
SARSURPICRequest.xsd file

<xs:schema version="1.0" targetNamespace="http://gisis.imo.org/XML/LRIT/sarSurpicRequest/2008"
xmlns="http://gisis.imo.org/XML/LRIT/sarSurpicRequest/2008" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:lrit="http://gisis.imo.org/XML/LRIT/types/2008" elementFormDefault="qualified">
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="sarCircularAreaType">
<xs:pattern value="()|((([0-8][0-9]\.[0-5][0-9]\.[nNsS])|(90\.00\.[nNsS])):(([0-1][0-7][0-9]\.[0-5][0-9]\.[eEwW])|([0][8-9][0-9]\.[0-5][0-
9]\.[eEwW])|(180\.00\.[eEwW])):([0-9]{3}))"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="sarRectangularAreaType">
<xs:pattern value="()|(([0-8][0-9]\.[0-5][0-9]\.[nNsS])|(90\.00\.[nNsS])):(([0-1][0-7][0-9]\.[0-5][0-9]\.[eEwW])|([0][8-9][0-9]\.[0-5][0-
9]\.[eEwW])|(180\.00\.[eEwW])):(([0-8][0-9]\.[0-5][0-9]\.[nN])|(90\.00\.[nN])):(([0-1][0-7][0-9]\.[0-5][0-9]\.[eE])|([0][8-9][0-9]\.[0-5][0-9]\.[eE])|(180\.00\.[eE]))"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="numberOfPositionsType">
</xs:restriction>
</xs:simpleType>
<xs:element name="SARSURPICRequest" type="SARSURPICType"/>
Annex, page 161
<xs:complexType name="SARSURPICType">
<xs:sequence>
<xs:choice>
<xs:element name="SARCircularArea" type="sarCircularAreaType"/>
<xs:element name="SARRectangularArea" type="sarRectangularAreaType"/>
</xs:choice>
<xs:element name="NumberOfPositions" type="numberOfPositionsType"/>
<xs:element name="DataUserRequestor" type="lrit:lritIDType"/>

</xs:sequence>
</xs:complexType>
</xs:schema>
Annex, page 162
ShipPositionReport.xsd file

<xs:schema version="1.0" targetNamespace="http://gisis.imo.org/XML/LRIT/positionReport/2008" xmlns="http://gisis.imo.org/XML/LRIT/positionReport/2008"
</xs:restriction>
</xs:simpleType>
<xs:element name="ShipPositionReport" type="ShipPositionReportType"/>

<xs:complexType name="ShipPositionReportType">
<xs:sequence>
<xs:element name="Latitude" type="lrit:latitudeType"/>
<xs:element name="Longitude" type="lrit:longitudeType"/>
<xs:element name="TimeStamp1" type="xs:dateTime"/>
<xs:element name="ShipborneEquipmentId" type="xs:string"/>
<xs:element name="ASPId" type="lrit:aspLRITIDType"/>
<xs:element name="CSPId" type="lrit:cspLRITIDType" minOccurs="0"/>
<xs:element name="IMONum" type="lrit:imoNumType"/>
<xs:element name="MMSINum" type="lrit:mmsiNumType" minOccurs="0"/>
<xs:element name="DCId" type="lrit:dataCentreLRITIDType"/>
Annex, page 163

<xs:element name="ResponseType" type="lrit:responseTypeType"/>
<xs:element name="ShipName" type="lrit:shipNameType" minOccurs="0"/>
<xs:element name="DataUserProvider" type="lrit:lritIDType"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Annex, page 164
ShipPositionRequest.xsd file

<xs:schema version="1.0" targetNamespace="http://gisis.imo.org/XML/LRIT/positionRequest/2008" xmlns="http://gisis.imo.org/XML/LRIT/positionRequest/2008"
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="accessTypeType">
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="requestTypeType">
Annex, page 165
</xs:restriction>
</xs:simpleType>
<xs:complexType name="requestDurationType">
<xs:attribute name="startTime" type="xs:dateTime" use="optional"/>
<xs:attribute name="stopTime" type="xs:dateTime" use="optional"/>
</xs:complexType>
<xs:simpleType name="distanceType">
</xs:restriction>
</xs:simpleType>
<xs:element name="ShipPositionRequest" type="ShipPositionRequestType"/>
<xs:complexType name="ShipPositionRequestType">
<xs:sequence>
<xs:element name="IMONum" type="lrit:imoNumType"/>
<xs:element name="DataUserProvider" type="lrit:lritIDType"/>
<xs:element name="AccessType" type="accessTypeType"/>
<xs:choice minOccurs="0">
<xs:element name="Port" type="lrit:locodeType"/>
<xs:element name="PortFacility" type="lrit:imoPortFacilityNumberType"/>
<xs:element name="Place" type="lrit:placeCodeType"/>
</xs:choice>
<xs:element name="Distance" type="distanceType"/>
<xs:element name="RequestType" type="requestTypeType"/>
<xs:element name="RequestDuration" type="requestDurationType" minOccurs="0"/>
Annex, page 166
</xs:sequence>
</xs:complexType>
</xs:schema>
Annex, page 167
SystemStatus.xsd file

<xs:schema version="1.0" targetNamespace="http://gisis.imo.org/XML/LRIT/systemStatus/2008" xmlns="http://gisis.imo.org/XML/LRIT/systemStatus/2008"
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="systemStatusIndicatorType">
</xs:restriction>
</xs:simpleType>
<xs:element name="SystemStatus" type="SystemStatusType"/>

<xs:complexType name="SystemStatusType">
<xs:sequence>
<xs:element name="SystemStatus" type="systemStatusIndicatorType"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Annex, page 168
Types.xsd file

<xs:schema version="1.0" targetNamespace="http://gisis.imo.org/XML/LRIT/types/2008" xmlns="http://gisis.imo.org/XML/LRIT/types/2008"
xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:simpleType name="lritIDType">
<xs:pattern value="[0-4][0-9]{3}"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="contractingGovernmentLRITIDType">
<xs:restriction base="lritIDType">
<xs:pattern value="[1][0-9]{3}"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="sarServiceLRITIDType">
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="dataCentreLRITIDType">
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="aspLRITIDType">
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="cspLRITIDType">
Annex, page 169
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ddpServerLRITIDType">
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ideLRITIDType">
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="lritCoordinatorLRITIDType">
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="msgIDType">
<xs:pattern value="([0-9]{4})(20[0-2][0-9])(0[1-9]|1[0-2])(0[1-9]|[1-2][0-9]|3[0-1])([0-1][0-9]|2[0-3])([0-5][0-9])([0-5][0-9])([0-9]{5})"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="refIDType">
<xs:pattern value="()|(([0-9]{4})(20[0-2][0-9])(0[1-9]|1[0-2])(0[1-9]|[1-2][0-9]|3[0-1])([0-1][0-9]|2[0-3])([0-5][0-9])([0-5][0-9])([0-9]{5}))"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="imoNumType">
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="shipNameType">
<xs:minLength value="0"/>
<xs:maxLength value="50"/>
</xs:restriction>
Annex, page 170
</xs:simpleType>
<xs:simpleType name="mmsiNumType">
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="testType">
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="responseTypeType">
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="longitudeType">
<xs:length value="11"/>
<xs:pattern value="([0-1][0-7][0-9]\.[0-5][0-9]\.[0-9][0-9]\.[eEwW])|([0][8-9][0-9]\.[0-5][0-9]\.[0-9][0-9]\.[eEwW])|(180\.00\.00\.[eEwW])"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="latitudeType">
<xs:length value="10"/>
<xs:pattern value="([0-8][0-9]\.[0-5][0-9]\.[0-9][0-9]\.[nNsS])|(90\.00\.00\.[nNsS])"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="messageType">
<xs:maxLength value="256"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ddpVersionNumType">
Annex, page 171
<xs:pattern value="[0-9]+:[0-9]+"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ddpIncrementalVersionNumType">
<xs:pattern value="[0-9]+"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ddpVersionNumOrIncrementalVersionType">
<xs:pattern value="[0-9]+(:[0-9]+)?"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="pricingVersionNumType">
<xs:restriction base="xs:positiveInteger"/>
</xs:simpleType>
<xs:simpleType name="locodeType">
<xs:pattern value="[A-Z]{2}([A-Z0-9]){3}"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="imoPortFacilityNumberType">
<xs:pattern value="[A-Z]{2}([A-Z0-9]){3}-[0-9]{4}"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="placeCodeType">
<xs:pattern value="[A-Z]{3}([0-9]){3}"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="percentageValueType">
<xs:restriction base="xs:float">
<xs:pattern value="[0-9]+(\.[0-9]{1,2})?"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="priceValueType">
Annex, page 172
<xs:restriction base="xs:float">
<xs:pattern value="[0-9]+(\.[0-9]{1,4})?"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="currencyType">
<xs:pattern value="[A-Z]{3}"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="polygonType">
<xs:sequence>
<xs:element name="Caption" type="xs:string" minOccurs="0" form="qualified"/>
<xs:element name="PosList" type="polygonPosListType" form="qualified"/>
</xs:sequence>
<xs:attribute name="areaID" type="xs:string" use="required"/>
</xs:complexType>
<xs:simpleType name="posType">
<xs:pattern value="\s*-?[0-9]{1,3}\.[0-9]{2}\s+-?[0-9]{1,2}\.[0-9]{2}\s*"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="polygonPosListType">
<xs:pattern value="\s*(\s*-?[0-9]{1,3}\.[0-9]{2}\s+-?[0-9]{1,2}\.[0-9]{2}\s*)(\s+-?[0-9]{1,3}\.[0-9]{2}\s+-?[0-9]{1,2}\.[0-9]{2}\s*){2,}"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Annex, page 173
WSDLs files
DC.wsdl file

<wsdl:definitions name="dc" targetNamespace="http://gisis.imo.org/XML/LRIT/2008" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://gisis.imo.org/XML/LRIT/2008" xmlns:posrep="http://gisis.imo.org/XML/LRIT/positionReport/2008"
xmlns:posreq="http://gisis.imo.org/XML/LRIT/positionRequest/2008" xmlns:surpic="http://gisis.imo.org/XML/LRIT/sarSurpicRequest/2008"
xmlns:receipt="http://gisis.imo.org/XML/LRIT/receipt/2008" xmlns:ddpNotification="http://gisis.imo.org/XML/LRIT/ddpNotification/2008"
xmlns:ddpUpdate="http://gisis.imo.org/XML/LRIT/ddpUpdate/2008" xmlns:systemStatus="http://gisis.imo.org/XML/LRIT/systemStatus/2008"
xmlns:pricingNotification="http://gisis.imo.org/XML/LRIT/pricingNotification/2008" xmlns:pricingUpdate="http://gisis.imo.org/XML/LRIT/pricingUpdate/2008"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/">
<wsdl:types>
<xs:schema elementFormDefault="qualified" targetNamespace="http://gisis.imo.org/XML/LRIT/2008">
<xs:import namespace="http://gisis.imo.org/XML/LRIT/positionReport/2008" schemaLocation="ShipPositionReport.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/positionRequest/2008" schemaLocation="ShipPositionRequest.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/sarSurpicRequest/2008" schemaLocation="SARSURPICRequest.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/receipt/2008" schemaLocation="Receipt.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/ddpNotification/2008" schemaLocation="DDPNotification.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/ddpRequest/2008" schemaLocation="DDPRequest.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/ddpUpdate/2008" schemaLocation="DDPUpdate.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/systemStatus/2008" schemaLocation="SystemStatus.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/pricingNotification/2008" schemaLocation="PricingNotification.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/pricingUpdate/2008" schemaLocation="PricingUpdate.xsd"/>
<xs:simpleType name="responseType">
<xs:enumeration value="Success"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="Response">
<xs:complexType>
<xs:sequence>
<xs:element name="response" type="tns:responseType"/>
Annex, page 174
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
</wsdl:types>
<wsdl:message name="ShipPositionReportRequest">
<wsdl:part name="params" element="posrep:ShipPositionReport"/>
</wsdl:message>
<wsdl:message name="ShipPositionReportResponse">
<wsdl:part name="params" element="tns:Response"/>
</wsdl:message>
<wsdl:message name="ShipPositionRequestRequest">
<wsdl:part name="params" element="posreq:ShipPositionRequest"/>
</wsdl:message>
<wsdl:message name="ShipPositionRequestResponse">
</wsdl:message>
<wsdl:message name="SARSURPICRequestRequest">
<wsdl:part name="params" element="surpic:SARSURPICRequest"/>
</wsdl:message>
<wsdl:message name="SARSURPICRequestResponse">
</wsdl:message>
<wsdl:message name="ReceiptRequest">
<wsdl:part name="params" element="receipt:Receipt"/>
</wsdl:message>
<wsdl:message name="ReceiptResponse">
</wsdl:message>
<wsdl:message name="DDPNotificationRequest">
<wsdl:part name="params" element="ddpNotification:DDPNotification"/>
</wsdl:message>
<wsdl:message name="DDPNotificationResponse">
Annex, page 175

</wsdl:message>
<wsdl:message name="DDPUpdateRequest">
<wsdl:part name="params" element="ddpUpdate:DDPUpdate"/>
</wsdl:message>
<wsdl:message name="DDPUpdateResponse">
</wsdl:message>
<wsdl:message name="SystemStatusRequest">
<wsdl:part name="params" element="systemStatus:SystemStatus"/>
</wsdl:message>
<wsdl:message name="SystemStatusResponse">
</wsdl:message>
<wsdl:message name="PricingNotificationRequest">
<wsdl:part name="params" element="pricingNotification:PricingNotification"/>
</wsdl:message>
<wsdl:message name="PricingNotificationResponse">
</wsdl:message>
<wsdl:message name="PricingUpdateRequest">
<wsdl:part name="params" element="pricingUpdate:PricingUpdate"/>
</wsdl:message>
<wsdl:message name="PricingUpdateResponse">
</wsdl:message>
<wsdl:portType name="dcPortType">
<wsdl:operation name="ShipPositionReport">
<wsdl:input message="tns:ShipPositionReportRequest"/>
<wsdl:output message="tns:ShipPositionReportResponse"/>
</wsdl:operation>
<wsdl:operation name="ShipPositionRequest">
<wsdl:input message="tns:ShipPositionRequestRequest"/>
Annex, page 176
<wsdl:output message="tns:ShipPositionRequestResponse"/>
</wsdl:operation>
<wsdl:operation name="SARSURPICRequest">
<wsdl:input message="tns:SARSURPICRequestRequest"/>
<wsdl:output message="tns:SARSURPICRequestResponse"/>
</wsdl:operation>
<wsdl:operation name="Receipt">
<wsdl:input message="tns:ReceiptRequest"/>
<wsdl:output message="tns:ReceiptResponse"/>
</wsdl:operation>
<wsdl:operation name="DDPNotification">
<wsdl:input message="tns:DDPNotificationRequest"/>
<wsdl:output message="tns:DDPNotificationResponse"/>
</wsdl:operation>
<wsdl:operation name="DDPUpdate">
<wsdl:input message="tns:DDPUpdateRequest"/>
<wsdl:output message="tns:DDPUpdateResponse"/>
</wsdl:operation>
<wsdl:operation name="SystemStatus">
<wsdl:input message="tns:SystemStatusRequest"/>
<wsdl:output message="tns:SystemStatusResponse"/>
</wsdl:operation>
<wsdl:operation name="PricingNotification">
<wsdl:input message="tns:PricingNotificationRequest"/>
<wsdl:output message="tns:PricingNotificationResponse"/>
</wsdl:operation>
<wsdl:operation name="PricingUpdate">
<wsdl:input message="tns:PricingUpdateRequest"/>
<wsdl:output message="tns:PricingUpdateResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="dcServiceBinding" type="tns:dcPortType">

<soap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<soap12:operation soapAction=""/>
<wsdl:input>
<soap12:body use="literal"/>
Annex, page 177
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:input>
</wsdl:input>
<wsdl:output>
Annex, page 178
</wsdl:output>
</wsdl:operation>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="PricingNotification">
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
Annex, page 179
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="dcService">
<wsdl:port name="dcPort" binding="tns:dcServiceBinding">
<soap12:address location="http://localhost:8080/dc"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Annex, page 180
DDP.wsdl file

<wsdl:definitions name="ddp" targetNamespace="http://gisis.imo.org/XML/LRIT/2008" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://gisis.imo.org/XML/LRIT/2008" xmlns:ddpRequest="http://gisis.imo.org/XML/LRIT/ddpRequest/2008"
xmlns:receipt="http://gisis.imo.org/XML/LRIT/receipt/2008" xmlns:systemStatus="http://gisis.imo.org/XML/LRIT/systemStatus/2008"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/">
<wsdl:types>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/ddpRequest/2008" schemaLocation="DDPRequest.xsd"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
</wsdl:types>
<wsdl:message name="DDPRequestRequest">
<wsdl:part name="params" element="ddpRequest:DDPRequest"/>
</wsdl:message>
<wsdl:message name="DDPRequestResponse">
</wsdl:message>
Annex, page 181
</wsdl:message>
</wsdl:message>
</wsdl:message>
</wsdl:message>
<wsdl:portType name="ddpPortType">
<wsdl:operation name="DDPRequest">
<wsdl:input message="tns:DDPRequestRequest"/>
<wsdl:output message="tns:DDPRequestResponse"/>
</wsdl:operation>
</wsdl:operation>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="ddpServiceBinding" type="tns:ddpPortType">

<wsdl:operation name="DDPRequest">
Annex, page 182
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="ddpService">
<wsdl:port name="ddpPort" binding="tns:ddpServiceBinding">

<soap12:address location="http://localhost:8080/ddp"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Annex, page 183
IDE-DC.wsdl file

<wsdl:definitions name="ide" targetNamespace="http://gisis.imo.org/XML/LRIT/2008" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://gisis.imo.org/XML/LRIT/2008" xmlns:posrep="http://gisis.imo.org/XML/LRIT/positionReport/2008"
xmlns:posreq="http://gisis.imo.org/XML/LRIT/positionRequest/2008" xmlns:surpic="http://gisis.imo.org/XML/LRIT/sarSurpicRequest/2008"
xmlns:receipt="http://gisis.imo.org/XML/LRIT/receipt/2008" xmlns:systemStatus="http://gisis.imo.org/XML/LRIT/systemStatus/2008"
xmlns:journalReport="http://gisis.imo.org/XML/LRIT/journalReport/2008" xmlns:pricingRequest="http://gisis.imo.org/XML/LRIT/pricingRequest/2008"
xmlns:pricingUpdate="http://gisis.imo.org/XML/LRIT/pricingUpdate/2008" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/">
<wsdl:types>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/positionReport/2008" schemaLocation="ShipPositionReport.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/positionRequest/2008" schemaLocation="ShipPositionRequest.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/sarSurpicRequest/2008" schemaLocation="SARSURPICRequest.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/journalReport/2008" schemaLocation="JournalReport.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/pricingRequest/2008" schemaLocation="PricingRequest.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/pricingUpdate/2008" schemaLocation="PricingUpdate.xsd"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
Annex, page 184
</xs:schema>
</wsdl:types>
<wsdl:message name="ShipPositionReportRequest">
<wsdl:part name="params" element="posrep:ShipPositionReport"/>
</wsdl:message>
<wsdl:message name="ShipPositionReportResponse">
</wsdl:message>
<wsdl:message name="ShipPositionRequestRequest">
<wsdl:part name="params" element="posreq:ShipPositionRequest"/>
</wsdl:message>
<wsdl:message name="ShipPositionRequestResponse">
</wsdl:message>
<wsdl:message name="SARSURPICRequestRequest">
<wsdl:part name="params" element="surpic:SARSURPICRequest"/>
</wsdl:message>
<wsdl:message name="SARSURPICRequestResponse">
</wsdl:message>
</wsdl:message>
</wsdl:message>
</wsdl:message>
</wsdl:message>
Annex, page 185
</wsdl:message>
<wsdl:message name="JournalReportRequest">
<wsdl:part name="params" element="journalReport:JournalReport"/>
</wsdl:message>
<wsdl:message name="JournalReportResponse">
</wsdl:message>
<wsdl:message name="PricingRequestRequest">
<wsdl:part name="params" element="pricingRequest:PricingRequest"/>
</wsdl:message>
<wsdl:message name="PricingRequestResponse">
</wsdl:message>
<wsdl:message name="PricingUpdateRequest">
<wsdl:part name="params" element="pricingUpdate:PricingUpdate"/>
</wsdl:message>
<wsdl:message name="PricingUpdateResponse">
</wsdl:message>
<wsdl:portType name="idePortType">
<wsdl:input message="tns:ShipPositionReportRequest"/>
<wsdl:output message="tns:ShipPositionReportResponse"/>
</wsdl:operation>
<wsdl:input message="tns:ShipPositionRequestRequest"/>
<wsdl:output message="tns:ShipPositionRequestResponse"/>
</wsdl:operation>
<wsdl:input message="tns:SARSURPICRequestRequest"/>
<wsdl:output message="tns:SARSURPICRequestResponse"/>
Annex, page 186
</wsdl:operation>
</wsdl:operation>
</wsdl:operation>
<wsdl:operation name="JournalReport">
<wsdl:input message="tns:JournalReportRequest"/>
<wsdl:output message="tns:JournalReportResponse"/>
</wsdl:operation>
<wsdl:operation name="PricingRequest">
<wsdl:input message="tns:PricingRequestRequest"/>
<wsdl:output message="tns:PricingRequestResponse"/>
</wsdl:operation>
<wsdl:input message="tns:PricingUpdateRequest"/>
<wsdl:output message="tns:PricingUpdateResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="ideServiceBinding" type="tns:idePortType">

<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:input>
Annex, page 187
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="JournalReport">
<wsdl:input>
</wsdl:input>
Annex, page 188
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="PricingRequest">
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="ideService">
<wsdl:port name="idePort" binding="tns:ideServiceBinding">

<soap12:address location="http://localhost:8080/ide"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Annex, page 189
IDE-DDP.wsdl file

<wsdl:definitions name="ide" targetNamespace="http://gisis.imo.org/XML/LRIT/2008" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://gisis.imo.org/XML/LRIT/2008" xmlns:receipt="http://gisis.imo.org/XML/LRIT/receipt/2008"
xmlns:ddpNotification="http://gisis.imo.org/XML/LRIT/ddpNotification/2008" xmlns:ddpUpdate="http://gisis.imo.org/XML/LRIT/ddpUpdate/2008"
xmlns:systemStatus="http://gisis.imo.org/XML/LRIT/systemStatus/2008" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/">
<wsdl:types>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/ddpNotification/2008" schemaLocation="DDPNotification.xsd"/>
<xs:import namespace="http://gisis.imo.org/XML/LRIT/ddpUpdate/2008" schemaLocation="DDPUpdate.xsd"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
</wsdl:types>
</wsdl:message>
Annex, page 190
</wsdl:message>
<wsdl:message name="DDPNotificationRequest">
<wsdl:part name="params" element="ddpNotification:DDPNotification"/>
</wsdl:message>
<wsdl:message name="DDPNotificationResponse">
</wsdl:message>
<wsdl:message name="DDPUpdateRequest">
<wsdl:part name="params" element="ddpUpdate:DDPUpdate"/>
</wsdl:message>
</wsdl:message>
</wsdl:message>
</wsdl:message>
<wsdl:portType name="ideDDPPortType">
</wsdl:operation>
<wsdl:input message="tns:DDPNotificationRequest"/>
<wsdl:output message="tns:DDPNotificationResponse"/>
</wsdl:operation>
<wsdl:input message="tns:DDPUpdateRequest"/>
<wsdl:output message="tns:DDPUpdateResponse"/>
</wsdl:operation>
Annex, page 191
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="ideDDPServiceBinding" type="tns:ideDDPPortType">

<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:input>
Annex, page 192
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="ideDDPService">
<wsdl:port name="ideDDPPort" binding="tns:ideDDPServiceBinding">

<soap12:address location="http://localhost:8080/ideDDP"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
____________
E
4 ALBERT EMBANKMENT
LONDON SE1 7SR
Telephone: +44 (0)20 7735 7611 Fax: +44 (0)20 7587 3210
Ref. T2-OSS/1.4 MSC.1/Circ.1294/Rev.2

15 February 2011
(PART II)
1 The Maritime Safety Committee (the Committee), at its eighty-eighth session

(24 November to 3 December 2010), considered and approved amendments to the Protocols
and arrangements for the prototype, developmental, integration and modification testing phases
of the LRIT system agreed by the Ad Hoc LRIT Group (the Group) at its ninth session
(MSC 88/26, paragraph 6.17 refers). The present circular incorporates the aforesaid
amendments, as well as the amendments approved by the Committee, at its eighty-sixth session
(27 May to 5 June 2009), regarding the entitlement of Search and Rescue (SAR) services of
SOLAS Contracting Governments to request and receive archived LRIT (MSC 86/26,
paragraph 6.51 refers).
2 The Long-range identification and tracking system Technical documentation (Part II)*
includes:
.1 Protocols and arrangements for the prototype, developmental, integration and

modification testing phases of the LRIT system;
.2 Procedures for the notification, reporting and recording of temporary

suspensions of operations or reduction of the service provided; and
.3 Procedures for the consideration of proposals for the amendment of technical

specifications for the LRIT system, the XML schemas and the test procedures
and test cases.
3 The Technical documentation (Part II) should always be read together with SOLAS
regulation V/19-1, the Revised performance standards and functional requirements for the
long-range identification and tracking of ships adopted by resolution MSC.263(84) and the
Technical documentation (Part I) which is set out in MSC.1/Circ.1259/Rev.4.
4 SOLAS Contracting Governments are invited to bring the present circular and its annex
to the attention of those engaged in the establishment, testing and operation of their LRIT Data
Centres.
*
The Long-range identification and tracking system Technical documentation (Part II) is available in English
only in accordance with the decision of MSC 84.
Page 2
5 The United States, as provider of the International LRIT Data Exchange on an interim
basis, is invited to bring the present circular and its annex to the attention of those involved with
the operation of the International LRIT Data Exchange.
6 Austria, Belgium, Bulgaria, Cyprus, the Czech Republic, Denmark, Estonia, Finland,
France, Germany, Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta,
the Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden and the
United Kingdom (the proposing Contracting Governments), which had submitted a proposal for
the establishment, maintenance and operation of the International LRIT Data Exchange as
from 2011, are invited to bring the present circular to the attention of those engaged in the
7 SOLAS Contracting Governments, LRIT Data Centres acting through SOLAS

Contracting Government(s) which have established them, the International LRIT Data Exchange
acting through the United States or the proposing Contracting Governments, as the case may
be, and the LRIT Coordinator are also invited to bring to the attention of the Committee, at the
earliest opportunity, the results of the experience gained from the use of the Technical
documentation (Part II) for consideration of action to be taken.
8 This circular revokes MSC.1/Circ.1294/Rev.1 issued on 13 May 2010 and any reference
to MSC.1/Circ.1294 or MSC.1/Circ.1294/Rev.1 should be read as reference to the present
circular.
***
Annex, page 1
ANNEX
(English only)
(PART II)
1 The Technical documentation of the LRIT system is set out in two parts.
2 Part I of the Technical documentation, issued under cover of MSC.1/Circ.1259/Rev.4.
3 Part II of the Technical documentation is issued under this circular and includes the:
.1 Protocols and arrangements for the prototype, developmental, integration and

modification testing phases of the LRIT system;
.2 Procedures for the notification, reporting and recording of temporary

suspensions of operations or reduction of the service provided; and
.3 Procedures for the consideration of proposals for the amendment of technical

specifications for the LRIT system, the XML schemas and the test procedures
and test cases,
which are set out in annexes 1 to 3, respectively, to this circular.
Annex, page 2
ANNEX 1
PROTOCOLS AND ARRANGEMENTS FOR THE

PROTOTYPE, DEVELOPMENTAL, INTEGRATION AND MODIFICATION
TESTING PHASES OF THE LRIT SYSTEM
(Version 3)
1 General provisions
1.1 Scope, testing requirements and limitations
1.1.1 Scope
1.1.1.1 The intent of this document is to provide protocols for the prototype, developmental,
integration, and modification testing phases of the Long-range identification and tracking (LRIT)
system.
1.1.1.2 This document describes the methodology for testing the LRIT system and its
components, namely the International LRIT Data Exchange (IDE), LRIT Data Distribution Plan
(DDP) server and the LRIT Data Centres (DCs), which is defined as validation and verification of
data communications and functionality between various components of the LRIT system and the
correct sending and receiving of the LRIT messages.
1.1.2 Testing requirements
1.1.2.1 The present protocols and arrangements have been designed to address the
requirements set out in:
.1 Regulation1 V/19-1;
.2 Revised performance standards and functional requirements for the

long-range identification and tracking of ships2 (Performance standards);
.3 Technical specifications for communications within the LRIT system3;
.4 Technical specifications for the International LRIT Data Exchange3;
.5 Technical specifications for the LRIT Data Distribution Plan3;
.6 Technical specifications for the International LRIT Data Centre3,4; and
.7 XML schemas3.
1
Unless expressly provided otherwise Regulation means a regulation of the International Convention for the
Safety of Life at Sea, 1974, as amended.
2
As adopted by resolution MSC.263(84).
3
Refer to MSC.1/Circ.1259/Rev.4 on Long-range identification and tracking system Technical documentation
(Part I).
4
The related technical specifications as set out in MSC.1/Circ.1259/Rev.4 are subject to review and updating by
the Maritime Safety Committee and the related work would only be undertaken if an International LRIT Data
Centre is to be established.
Annex, page 3
1.1.2.2 The appendices to this document set out the detailed individual tests which should
be carried out. Each such test identifies the relevant provisions of the requirements identified in
paragraph 1.1.2.1.
1.1.2.3 The detailed individual tests when conducted should conform to the processes and
procedures set out in this document and the appendices.
1.1.2.4 Once completed, the testing documentation should be submitted, for each testing
phase as described in the process and procedures section of this document.
1.1.3 Limitations of the testing process
1.1.3.1 The provisions of regulation V/19-1 and the Performance standards, as far as all the
components of the LRIT system are concerned, and the provisions of the technical specifications
for the LRIT system (refer to paragraphs 1.1.2.1.3 to 1.1.2.1.7 above) as far as the IDE, the
International LRIT Data Centre, the DDP and the DDP server are concerned, include a number
of requirements which cannot be verified through testing.
1.1.3.2 As the current arrangements envisaged by the Maritime Safety Committee

(Committee) in relation to the establishment of the LRIT system do not provide for any form of
physical inspections on location it is the responsibility of those establishing DCs, the IDE, the
DDP and the DDP server to verify and document their compliance with the related requirements
and to produce such documentation when requested to do so by the Committee.
1.1.3.3 The tests envisaged in the present document assume that those establishing DCs,
the IDE, the DDP and the DDP server have completed the process of verifying and documenting
such compliance prior to entering the prototype, developmental, integration or modification
testing phase, as the case may be.
2 Testing protocols
2.1 Overview
2.1.1 General
2.1.1.1 The testing protocols for the LRIT system are critical to ensure a successful system
and in order for it to become and remain operational.
2.1.1.2 The prototype phase establishes the prototype environment and the connection of
the LRIT system prototype components. After the prototype phase, a test environment and the
production environment would be established and open for new DCs to begin testing, beginning
with developmental testing within the testing environment and graduating to integration testing in
the production environment. The modification testing phase, which also includes a testing
environment and the production environment, provides for testing of changes in the LRIT system
on or after 00:01 UTC on 31 December 2008 following the adoption of amendments to the
requirements referred to in paragraph 1.1.2.1, other than amendments to those referred to in
paragraphs 1.1.2.1.3 to 1.1.2.1.7 which may be found necessary during the initial setting up of
the system.
2.1.1.3 During the initial setting up and testing of the LRIT system, which on the basis of the
available information is expected to continue after 31 December 2008, it may become necessary
to conduct additional tests as a result of the adoption of amendments to the technical
specifications for the LRIT system referred to in paragraphs 1.1.2.1.3 to 1.1.2.1.7. Such
additional tests may entail consequential amendments to the test procedures and test cases set
Annex, page 4
out in the appendices 2 to 4 of the annex or the adoption of additional test procedures and test
cases. The related additional tests will be determined at the time of the adoption of the related
amendments to the aforesaid technical specifications, together with the technical and
administrative requirements and arrangements to be followed for conducting such tests, as well
as the extent to which components of the system which have already completed or are
undertaking testing should be retested.
2.1.2 Testing phases
2.1.2.1 There are four distinct testing phases as follows:
.1 Prototype testing phase 1 July 2008 to the date of completion of the

testing of the prototype IDE, the prototype DDP and DDP server and a
satisfactory number of prototype DCs, subject to the decisions of the
Committee
This is the first step in the establishment of the LRIT system and during this
phase the prototype IDE, the prototype DDP and DDP server and a number
of prototype DCs would undergo communications and functional tests with
a view to verifying that they meet the relevant requirements of regulation
V/19-1, of the Performance standards and of the technical specifications for
the LRIT system.
In addition, the purpose of this phase is to ascertain whether there is a

need to amend in any way any of the technical specifications for the LRIT
system.
The DCs that satisfactorily completed all communications and functional

tests during the prototype testing phase would form, together with the
prototype IDE and the prototype DDP and DDP server, the production
environment and are not required to undergo or satisfactorily complete any
tests during either the developmental or the integration testing phases.
In addition, the aforesaid DCs would form the first testing environment.
The results of the prototype testing phase will be reported to and reviewed
by the Committee, at its eighty-fifth session. The end date of this phase will
be prior to 31 December 2008 and will be determined by the aforesaid
session of the Committee;
.2 Developmental testing phase date of establishment of the testing

environment5 to the date to be decided by the Committee
The purpose of this phase is to enable prototype DCs which have either not
been able to satisfactorily complete all communications and functional tests
during the prototype testing phase or other DCs that are ready for testing
after the formation of the prototype environment to become, through the
integration testing phase, part of the production environment during the
initial setting up of the LRIT system. As a result, with the exception of the
prototype DCs that satisfactorily completed all communications and
functionality tests during the prototype testing phase, all DCs should first
participate in the developmental testing phase in order to determine
5
Subject to the DCs completing prototype testing and being available to assist the testing of DCs which have not
participated in the prototype testing phase.
Annex, page 5
whether they should be accepted to participate in the integration testing

phase which would in turn determine whether they should be accepted to
become part of the production environment.
DCs which satisfactorily complete all communications and functional tests

during the developmental testing phase may be required to participate in
the testing environment to enable the testing of other DCs during the
developmental testing phase.
On the basis of the available information the establishment of DCs during

the initial setting up of the LRIT system is expected to continue
after 31 December 2008. As a result the Committee, at its eighty-fifth
session, will determine the date by which all DCs to be established during
the initial setting of the LRIT system should satisfactorily complete all
required tests and thus determine the end date of the developmental
testing phase;
.3 Integration testing phase Date of completion of the prototype testing

phase to the date to be decided by the Committee
The purpose of this phase is to enable DCs which have satisfactorily

completed the developmental testing phase to become part of the
production environment during the initial setting up of the LRIT system.
As a result, DCs that have satisfactorily completed developmental testing

should then participate in the integration testing phase in order to
determine whether they should be accepted to become part of the
production environment.
The DCs that participated in the prototype testing and have satisfactorily
completed all functional and communications tests during the prototype
testing phase would form the production environment and are not required
to participate in and satisfactorily complete the integration testing phase.
DCs which satisfactorily complete all communications and functional tests

during the integration testing phase may be required to participate in the
testing environment to enable the testing of other DCs during the
developmental or integration testing phases.
On the basis of the available information, the establishment of DCs during

the initial setting up of the LRIT system is expected to continue
after 31 December 2008. As a result the Committee, at its eighty-fifth
session, will determine the date by which all DCs to be established during
the initial setting of the LRIT system should satisfactorily complete all
required tests and thus determine the end date of the integration testing
phase; and
.4 Modification testing phase 31 December 2008 through life of system
The purpose of this phase is to enable the testing of modifications to the

production environment on or after 31 December 2008 as a result of
amendments to provisions of regulation V/19-1, the Performance
standards, or the technical specifications of the LRIT system. The specific
tests to be conducted in each case and which LRIT system components
Annex, page 6
should undergo such tests would be determined in line with the

requirements of the amendments to be adopted.
The modification testing phase includes a testing environment and the

2.1.3 Environments used for testing
2.1.3.1 There are three types of environments used for testing as follows:
.1 Prototype environment the prototype environment is the LRIT system

used during the prototype phase. This environment is established by the
prototype IDE, the prototype DDP and DDP server and a minimum of two
prototype DCs;
.2 Testing environment the testing environment is the LRIT system used

during the developmental testing and modification testing phases. This
environment is established by the test IDE, test DDP and DDP server and a
minimum of two test DCs which has satisfactorily completed all functional
and communications tests during either the prototype or developmental
testing phases. A DC wishing to become part of the production
environment (other than a prototype DC which has satisfactorily completed
all communications and functional tests) should first complete
developmental testing within the testing environment; and
.3 Production environment the production environment is the LRIT system

used for operation of the LRIT system, including during the modification
testing phase. This environment is initially established by the prototype
IDE, prototype DDP and DDP server and prototype DCs that have
satisfactorily completed all communications and functional tests. This
environment is also the environment within which DCs (other than the
prototype ones referred to above) that have undergone and satisfactorily
completed the developmental testing phase, once accepted, would
undergo the integration testing phase and once accepted, conduct final
LRIT system operations.
2.1.3.2 The individual tests to be undertaken in each of the testing environments by each of
the components of the LRIT system are identified under the column headed environment in the
tests descriptions in the appendices to the annex.
2.1.4 Test types
2.1.4.1 There are two types of tests as follows:
.1 Communications test this is a suite of tests (identified with the letter C

under the column headed test type in the tests descriptions in the
appendices to the annex) that each of the components under test should
undergo and satisfactorily complete in order to demonstrate that the
component has correctly implemented the Technical specifications for
communications within the LRIT system and the various related
requirements of the Performance standards. Functionality of the various
components would not be tested during this type of test, only their
compliance with the aforesaid requirements would be tested; and
Annex, page 7
.2 Functional test this is a suite of tests (identified with the letter F under
the column headed test type in the tests descriptions in the appendices to
the annex) that each of the components of the LRIT system under test
should undergo and satisfactorily complete in order to demonstrate that it
meets the requirements of regulation V/19-1 and performs the relevant
functionality requirements of the Performance standards, excluding those
covered by communications tests, to the extent the said requirements can
be demonstrated through testing.
Notwithstanding the aforesaid, the IDE and the DDP and DDP server
during this test should, in addition, also demonstrate that they perform all
the functionality requirements of the Technical specifications for the
International LRIT Data Exchange and Technical specifications for the LRIT
Data Distribution Plan respectively, to the extent the said requirements can
be demonstrated through testing.
2.1.5 Tests and test certification
2.1.5.1 There are two groups of tests as follows:
.1 Pre-tests Tests conducted by components of the LRIT system before

entering into the prototype, testing, or production environments. These
tests (identified under the column headed required before entering in the
tests cases in the appendices to the annex) are conducted by each of the
components of the LRIT system to ensure a smooth transition into the
related environment; and
.2 Environment tests These tests (identified under the column headed

required during in the tests descriptions in the appendices to the annex) are
conducted after an LRIT component has entered the prototype, testing, or
2.1.5.2 There are two types of test certifications as follows:
.1 Internal test certification These are either pre-tests or environment

tests (identified as internal under the column headed certification in the
tests descriptions in the appendices to the annex) that are self-certified as
pass/fail by the LRIT component undergoing the test and in the case of
prototype testing by one or more components of the LRIT system forming
the prototype environment; and
.2 External test certification These are either pre-tests or environment

tests (identified as external under the column headed certification in the
tests descriptions in the appendices to the annex) that are certified as
pass/fail by the LRIT component undergoing testing and one or more
components of the LRIT system forming the prototype, testing, or
Annex, page 8
3 Process and procedures
3.1 General
3.1.1 Overview
3.1.1.1 Before undertaking any tests during the various testing phases, those concerned
with the components of the LRIT system to be tested and those concerned with the components
of the LRIT system participating in the testing should first meet the technical and administrative
requirements of the arrangements specified below.
3.1.1.2 Each phase of testing also requires the accurate documentation of the results of the
communications and functional tests which should be prepared by those concerned with the
components of the LRIT system to be tested and those concerned with the components of the
LRIT system participating in the testing in accordance with the arrangements specified below.
3.2 Prototype testing phase arrangements and procedures
3.2.1 Overview
3.2.1.1 The prototype testing environment should consist of the prototype IDE, the prototype
DDP and DDP server and a number of prototype DCs (at least two) for which the Contracting
Governments have notified, pursuant to the provisions of the Performance standards, the
Organization as to their establishment and existence indicating their wish and readiness to
participate in the prototype testing phase. Only DCs established by Contracting Governments
that have provided all the required information to the DDP should be allowed to participate in the
prototype testing phase.
3.2.1.2 The prototype testing phase is critical for the successful implementation of the
LRIT system. In order to ensure the timely establishment of the LRIT system it is necessary to
provide, as soon as possible, inter alia:
.1 certainty in relation to the adequacy and completeness of the Technical

specifications for communications within the LRIT system; and
.2 a testing environment to enable those engaged in the establishment of DCs

to test their functionality in particular the satisfactory operation of the
geo-spatial elements.
3.2.1.3 At the time of adoption of this version of the present protocols it was recognized that
a number of DCs participating in the prototype testing phase might not be able to engage or
conduct a number of functional tests for example due to their geo-spatial elements still being
under construction.
3.2.1.4 As a result, each DC participating in the prototype testing phase should undertake
and satisfactorily complete first all communications tests. The scheduling of the various
functional tests should be determined through a mutual agreement with the components of the
LRIT system which would be participating in the relevant tests.
3.2.1.5 In case a DC participating in the prototype testing phase is unable to satisfactorily

complete all functional tests by the date which the Committee will determine as the end date of
the prototype testing phase, that DC should be treated as a DC which has not undergone any
testing and should commence testing anew through the developmental and integration testing
phase route.
Annex, page 9
3.2.2 Pre-prototype testing arrangements (At time of the adoption of this version of the
present protocols a number of aspects set out in paragraph 3.2.2.1 have been overtaken by
events. However, in the context of providing a record of the actions taken during the prototype
testing phase these have been retained in the form they were adopted by the Ad Hoc LRIT
Group at its fifth session.)
3.2.2.1 The pre-prototype testing process is as follows:
.1 DCs participating in the prototype testing phase are those which have
notified6 by 11 July 2008 the Organization to this end indicating that they
are ready for testing and are prepared to connect to the prototype
environment;
.2 DCs participating in the prototype testing phase should, if they have

not already done so, communicate to the Organization, no later
than 15 September 2008, the name and contact details (office and postal
address, office and mobile telephone number, facsimile number and e-mail
address) of an official or officer charged with coordinating all matters
relating to the tests to be conducted;
.3 The Contracting Government(s) establishing the prototype DCs should, if

they have not already done so, provide, no later than 15 September 2008,
all the required information to the DDP and the Secretariat should advise to
this end those forming the prototype environment that the required
information have been received and thus confirm that the prototype testing
should continue;
.4 All prototype components should, if they have not already done so, request,
no later than 1 September 2008, from the United States, acting in the
capacity of the operator of the IDE, the issue of a PKI certificate which they
should install and use during testing taking into account any related
instructions and guidance provided by the United States and subject to any
conditions attached thereto;
.5 Each of the prototype components should undertake and complete, after

implementing the revised XML schemas set out in annex 5 to document
MSC 85/6/1/Add.1, the Pre-tests specified in the related appendices of the
annex for the prototype environment and forward its respective completed
documentation to the Organization if they have not already done so not
later than 15 September 2008 or at least five working days prior to the date
they will agree to commence prototype testing, whichever of the two dates
is later;
.6 The Secretariat should provide those forming the prototype environment

with copies of the Pre-tests documentation as soon as it receives it;
.7 Those forming the prototype environment should, no later than three

working days after receiving the Pre-tests documentation, advise the
Organization whether they are comfortable with the results of the Pre-tests
and confirm that they are ready to proceed with the prototype testing;
6
As of 11 July 2008, the following Contracting Governments establishing National LRIT Data Centres have
notified the Organization of their wish to participate in the prototype testing phase: the Bahamas, Brazil,
Canada, Liberia, the Marshall Islands, the Republic of Korea and the United States.
Annex, page 10
.8 The United States, acting in its capacity as the operator of the IDE, and in
consultation with the DDP server and the DCs forming the prototype
environment, should determine and advise the date and times on which
each DC would commence prototype testing and advise those concerned
of the date by which the prototype tests should be preferably completed;
and
.9 The prototype DDP server and the prototype DCs should request the
connection to the IDE and the DDP server (in the case of DCs) and
coordinate a testing schedule with the components forming the prototype
environment. The IDE and DDP server should have a leading and
coordinating role in scheduling the tests to be conducted and the DC
undergoing prototype testing should conduct the tests they identify in the
order they determine these.
3.2.3 Prototype testing process (At time of the adoption of this version of the present
protocols a number of aspects set out in paragraph 3.2.3.1 have been overtaken by events.
However, in the context of providing a record of the actions taken during the prototype testing
phase these have been retained in the form they were adopted by the Ad Hoc LRIT Group at its
fifth session.)
3.2.3.1 The prototype testing process is subject to the implementation of the revised
XML schemas set out in annex 5 to document MSC 85/6/1/Add.1 and is as follows:
.1 The prototype components should satisfactorily complete all

communications and functional tests subject to the additional provisions
specified in the procedures and arrangements set out in annex 3 to
document MSC 85/6/1/Add.1;
.2 All components participating in the testing should document the results of

the testing at their end, so as to be able to examine the results of the tests
as documented by the components undergoing or involved in the testing;
.3 All components participating in the testing should forward the complete

testing documentation after the end of the communications and functional
tests, as the case may be, to the Organization no later than two working
days after the end of the testing together with the associated summary
report;
.4 The Secretariat should provide those forming the prototype environment

with copies of the testing documentation and of the summary reports as
soon as it receives it;
.5 All components participating in the testing should, no later than two working
days after receiving the testing documentation and the summary report,
advise the Organization whether they are satisfied with the results of
testing as documented by the other components which have undergone or
participated in the testing and confirm that they certify these as true and
correct by completing the relevant section of the related summary report
and returning it to the Organization; and
.6 The Secretariat should prepare at the end of the prototype testing phase a
draft report for the consideration by MSC 85 and should forward it to all the
components that participated in the prototype testing phase for their
Annex, page 11
perusal and comments. Any comments should be forwarded to the

Secretariat no later than two working days after receiving the draft report.
In the absence of any response, the Secretariat should assume that the
component(s) which did not respond have no comments and are satisfied
with the draft report being finalized and submitted for consideration by
MSC 85. In case of comments or proposed amendments, the Secretariat
should act accordingly with a view to reaching consensus amongst all
parties and ensuring that the report is submitted for consideration by
MSC 85 in a timely manner.
3.2.3.2 The prototype IDE and DDP server should endeavour to complete all
communications and functional tests in which they are involved before commencing any tests
which involve a DC.
3.2.4 Post-prototype testing process (At time of the adoption of this version of the
present protocols a number of aspects set out in paragraph 3.2.4.1 have been overtaken by
events. However, in the context of providing a record of the actions taken during the prototype
testing phase these have been retained in the form they were adopted by the Ad Hoc LRIT
Group at its fifth session.)
3.2.4.1 The post-prototype testing arrangements to be observed are as follows:
.1 The components participating in the prototype testing phase should identify

and submit for consideration by the Ad Hoc LRIT Working Group, at its
sixth session, any final amendments to the technical specifications for the
LRIT system including the necessary modifications to the present protocols
and the XML schemas;
.2 The prototype components (i.e. IDE, DDP server and voluntary DCs7)
should establish the testing environment not later than 1 October 2008 and
should advise to this end the Organization as soon as the testing
environment is ready to engage in the developmental testing phase; and
.3 The prototype components (i.e. IDE, DDP server and voluntary DCs)
should establish a production environment no later than 1 October 2008
and should advise the Organization to this end as soon as the testing
environment is ready to engage in the integration testing phase.
3.2.5 Continuation and completion of the prototype testing process (This part has
been adopted in order to provide the framework for the continuation and completion of the
prototype testing phase as the result of adoption by the Ad Hoc LRIT Group, at its sixth session,
of amendments to the technical specifications for the LRIT system, the XML schemas and the
test procedures and test cases.)
3.2.5.1 The IDE, DDP server and all DCs participating in the prototype testing should before
continuing any further testing:
.1 implement the revised XML schemas set out in annex 5 to document

MSC 85/6/1/Add.4;
7
Refer to the procedures and arrangements set out in annex 3 to document MSC 85/6/1/Add.3.
Annex, page 12
.2 implement any required changes to their systems as results of the

amendments to the technical specifications for the LRIT system adopted by
the Ad Hoc LRIT Group, at its sixth session, as set out in annex 5 to
document MSC 85/6/1/Add.4; and
.3 confirm to the other components of the LRIT system participating in the

prototype testing phase that they have taken all required actions in line with
subparagraphs .1 and .2 above, satisfactorily completed all necessary
self-testing and are ready to continue the testing process.
3.2.5.2 The IDE, DDP server and all DCs participating in the prototype testing should:
.1 undertake and satisfactorily complete all test procedures and test cases
specified in the relevant appendices of the annex which have not yet
conducted. This should include all test procedures and test cases for
which they have not reported the test results to the Organization and all
new test procedures and test cases adopted by the Ad Hoc LRIT Group, at
its sixth session; and
.2 repeat and satisfactorily complete all test procedures and test cases which
have been amended by the Ad Hoc LRIT Group, at its sixth session.
3.2.5.3 The IDE, DDP server and all DCs participating in the prototype testing should
forward the complete testing documentation together with the associated summary report to the
Organization by 14 November 2008 at the latest.
3.2.5.3.1 The testing documentation for all DCs participating in the prototype testing is set out
in appendix 2 of the annex, for the IDE in appendix 3 of the annex and for DDP server in
appendix 4 of the annex. The summary report, for all DCs, is set out in appendix 5 of the annex.
These may be obtained from the Secretariat in word format upon request. When completing the
testing documentation the existing text should not be amended in any way and the entries
should be limited to include a Pass or a Fail under the column headed Pass/Fail. Any related
information should be provided on separate sheets by cross referencing the test procedure
and/or case to which these relate.
3.2.5.4 The Secretariat should provide those forming the prototype environment with copies
of the testing documentation and the summary reports as soon as it receives them.
3.2.5.5 All components participating in the testing should, no later than one working day after
receiving the testing documentation and the summary report, advise the Organization whether
they are satisfied with the results of testing as documented by the other components which have
undergone or participated in the testing and confirm that they certify these as true and correct by
completing the relevant section of the related summary report and returning it to the
Organization.
3.2.5.6 The Secretariat should prepare by 19 November 2008 a draft report on the results of
the prototype testing phase for the consideration by the Committee, at its eighty-fifth session,
and should forward it to all the components that participated in the prototype testing phase for
their perusal and comments. Any comments should be forwarded to the Secretariat no later
than 20 November 2008. In the absence of any response, the Secretariat should assume that
the component(s) which did not respond have no comments and are satisfied with the draft
report being finalized and submitted for consideration by the Committee. In case of comments
or proposed amendments, the Secretariat should act accordingly with a view to reaching
consensus amongst all parties and ensuring that the report is submitted for consideration by
Committee in a timely manner.
Annex, page 13
3.3 Developmental testing phase arrangements and procedures
3.3.1 Overview
3.3.1.1 Developmental testing is conducted in the testing environment which would be

established after the successful prototype testing of the prototype IDE, DDP server, and at least
two prototype DCs. Developmental testing should always include one DC that has satisfactorily
completed all communications and functional tests during either the prototype or developmental
phase. However, a DC which has satisfactorily completed developmental testing but has failed
to complete integration testing should not form part of the testing environment.
3.3.1.2 The Organization would notify all Contracting Governments when the testing
environment is ready and available for developmental testing. DCs wishing to undergo
developmental testing would be accommodated on a first come, first served basis.
3.3.2 Pre-developmental testing process
3.3.2.1 The pre-developmental testing arrangements to be observed are as follows:
.1 The Contracting Government(s) establishing the DC wishing to undergo

development testing should notify to this end the Organization;
.2 The Contracting Government(s) concerned should provide all the required

information to the DDP no later than three working days prior to the
commencement of the developmental testing and the Secretariat should
advise to this end those forming the testing environment. As far as the
polygons of the geographical areas which should be included in the DDP,
the Contracting Government should ensure that these fully comply with the
constrains provided in section 5 of the Technical specifications of the LRIT
Data Distribution Plan;
.3 The DC should, after ensuring that it has implemented the release version
of the XML schemas in force, undertake and satisfactorily complete the
Pre-tests specified in the appendix 2 of the annex which are relevant to
DCs for the testing environment and should forward the completed pre-test
documentation to the Organization, together with a confirmation that it has
implemented the aforesaid schemas;
.4 The DC should ascertain that the polygons of the geographical areas which
should be included by the Contracting Government in the DDP fully comply
with the constrains provided in section 5 of the Technical specifications of
the LRIT Data Distribution Plan; should implement and test the polygons;
and confirm that it has done so and that these have not caused any errors
or malfunctions to the Organization when submitting the Pre-test
documentation. In case of errors or malfunctions, it should advise the
Contracting Government concerned to make the required changes in the
DDP before forwarding the completed pre-test documentation to the
Organization;
.5 The Secretariat should provide those forming the testing environment with
copies of the Pre-tests documentation together with the confirmations
specified in subparagraphs .3 and .4 as soon as it receives it;
Annex, page 14
.6 Those forming the testing environment should, no later than three working
days after receiving the Pre-tests documentation, advise the Organization
whether they are comfortable with the results of the Pre-tests and confirm
that they are ready to proceed with the developmental testing;
.7 The Secretariat in consultation with the components forming the testing

environment and the DC requesting developmental testing should
determine and advise the date and times on which the developmental
testing would commence and advise those concerned of the date by which
the tests should be preferably completed; and
.8 The Secretariat should also provide to the LRIT Coordinator salient

information concerning that DC.
3.3.3 Developmental testing process
3.3.3.1 The development testing process to be observed is as follows:
.1 DC, as soon as is advised of the date and times on which the

developmental testing would commence, should request from the
Secretariat, the issue of a PKI certificate and should confirm to those
forming the testing environment that it has installed it. The Secretariat
should not issue such a PKI certificate unless the information which should
be communicated to the Organization have been received and/or entered
in the DDP and the pre-testing documentation has been circulated to the
interested parties and they have confirmed their readiness to commence
testing;
.2 DC should request the connection to the IDE and the DDP server and
coordinate a testing schedule with the components forming the testing
environment. The IDE and DDP server should have a leading and
coordinating role in scheduling the tests to be conducted and the DC
undergoing developmental testing should conduct the tests they identify in
the order they determine these;
.3 DC should undergo and satisfactorily complete the communications and

functional tests specified in appendix 2 of the annex for the testing
environment;
.4 The DC which has undergone testing should complete and forward its
testing documentation and the related summary report to the Organization
and to the LRIT Coordinator no later than two working days after the end of
the developmental testing. The testing documentation is set out in
appendix 2 of the annex and the summary report is set out in appendix 5 of
the annex. These may be obtained from the Secretariat in word format
upon request. When completing the testing documentation the existing text
should not be amended in any way and the entries should be limited to
include a Pass or a Fail under the column headed Pass/Fail. Any related
information should be provided on separate sheets by cross referencing the
test procedure and/or case to which these relate;
.5 All other components of the LRIT system participating in the testing should
also document the results of the testing at their end, so as to be able to
examine the results of the tests as documented by the DC undergoing testing;
Annex, page 15
.6 The Secretariat should provide those participating in the testing

environment with copies of the testing documentation and of the related
summary report as soon as it receives it;
.7 Those forming the testing environment should, no later than two working
days after receiving the testing documentation and the related summary
report, advise the Organization and the LRIT Coordinator whether they are
satisfied with the results of developmental testing as documented by the
DC which has undergone developmental testing and confirm that they
certify these as true and correct by completing the relevant section of the
related summary report and returning it to the Organization and forwarding
a copy of it to the LRIT Coordinator;
.8 The LRIT Coordinator, after examining the testing documentation and the
related summary report, if it is satisfied, should authorize, as instruct by
MSC 84, the integration of the DC which has satisfactorily completed
developmental testing and should advise the Organization to this end. The
LRIT Coordinator, if unable to authorize the integration of the DC which has
undergone developmental testing into the production environment should
communicate its decision to the DC concerned and the Organization
together with the reasons thereof;
.9 The Secretariat should communicate the decisions of the LRIT Coordinator

to those who have formed the testing environment; and
.10 If the LRIT Coordinator has authorized the integration of the DC into the
production environment, the Secretariat should inform accordingly those
forming the production environment.
3.4 Integration testing phase arrangements and procedures
3.4.1 Overview
3.4.1.1 Integration testing is conducted in the production environment which would be

established after the successful prototype testing of the prototype IDE, DDP server, and at least
two prototype DCs. Integration testing should always include two DCs that are forming part of
the production environment.
3.4.1.2 The Organization should notify all Contracting Governments when the production
environment is ready and available for integration testing. DCs wishing to undergo integration
testing should be accommodated on a first come, first served basis.
3.4.2 Integration testing process
3.4.2.1 The integration testing process to be observed is as follows:
.1 DC should request the connection to the IDE and the DDP server and
coordinate a testing schedule with the components forming part of the
production environment which would participate in the integration testing.
The IDE and DDP server should have a leading and coordinating role in
scheduling the tests to be conducted and the DC undergoing integration
testing should conduct the tests they identify in the order they determine
these;
Annex, page 16
.2 DC should undergo and satisfactorily complete the communications and

functional tests specified in appendix 2 of the annex for integration into the
production environment;
.3 The DC which has undergone testing should complete and forward its
integration testing documentation and the related summary report to the
Organization and the LRIT Coordinator no later than two working days after
the end of the integration testing. The testing documentation is set out in
appendix 2 of the annex and the summary report is set out in appendix 5 of
the annex. These may be obtained from the Secretariat in word format
upon request. When completing the testing documentation, the existing
text should not be amended in any way and the entries should be limited to
include a Pass or a Fail under the column headed Pass/Fail. Any related
information should be provided on separate sheets by cross referencing the
test procedure and/or case to which these relate;
.4 All other components participating in the integration testing should also

document the results of the testing at their end, so as to be able to examine
the results of the tests as documented by the DC undergoing testing;
.5 The Secretariat should provide to those participating in the integration

testing with copies of the integration testing documentation and the related
summary report as soon as it receives it;
.6 Those participating in the integration testing should, no later than two

working days after receiving the integration documentation and the related
summary report, advise the Organization and the LRIT Coordinator whether
they are satisfied with the results of integration testing as documented by
the DC which has undergone integration testing and confirm that they
certify these as true and correct by completing the relevant section of the
related summary report and returning it to the Organization and forwarding
a copy of it to the LRIT Coordinator; and
.7 If the DC being tested fails the integration testing, the Secretariat should,
as soon as the Organization has been notified to this end, inform
accordingly those operating in the production environment and those who
participated in the developmental testing of the DC in question.
3.4.2.2 In case a DC undergoing testing during the integration testing phase fails to
satisfactorily complete all required tests, that DC should be treated as a DC which has not
undergone any testing and should commence testing anew through the developmental and
integration testing phase route.
3.5 Modification testing phase
3.5.1 Overview
3.5.1.1 Modification testing is conducted in the testing environment and, if necessary, in the
production environment. Modification testing should be conducted whenever new test
procedures and test cases are required to be conducted as a result of amendments to the
provisions of regulation V/19-1, the Revised performance standards or the Technical
specifications for the LRIT system, or any related decision of the Maritime Safety Committee.
Annex, page 17
3.5.1.2 The detailed modification test procedures and test cases, as well as any decisions or
additional guidance, will be prepared and approved by either the Committee or the LRIT
operational governance body, as defined within the Continuity of Service Plan for the LRIT
System, on a case by case basis taking into consideration the impact and urgency of the
modification.
3.5.2 Pre-modification testing process
3.5.2.1 The Secretariat should notify all LRIT system components (IDE, DDP server and
DCs) operating in the production environment of the LRIT system and the LRIT Coordinator,
about any decision (schedule, deadlines, etc)relating to the implementation of amendments to
the provisions of regulation V/19-1, the Revised performance standards or the Technical
specifications for the LRIT system, or any decision of the Maritime Safety Committee, which may
require additional testing to be conducted in the testing and the production environments of the
LRIT system.
3.5.2.1.1 The Secretariat should provide those LRIT system components required to undergo
modification testing with a bespoken version of the Summary report and the Report of test
results, including the required test procedures and test cases, as well as any particular
instructions to be observed.
3.5.2.2 In case a new version of the XML schemas needs to be implemented, the
corresponding release version should be available for download in the testing environment of the
DDP.
3.5.3 Modification testing process
3.5.3.1 The LRIT system component concerned should undergo and satisfactorily complete
the communications and functional tests specified in the Secretariat's notification for the testing
environment.
3.5.3.2 As soon as the testing is completed, the LRIT system component that has
undergone testing in the testing environment should complete the Summary report and the
Report of test results and forward these to the Organization.
3.5.3.2.1 When completing the testing documentation, the existing text should not be
amended in any way as this may invalidate the whole testing process.
3.5.3.2.2 The entries in the Report of test result should be limited to either include a Pass or a
Fail under the column headed Pass/Fail.
3.5.3.2.3 The LRIT system component should only complete the relevant part of the Summary
report which is required to be completed by the LRIT system component undergoing testing.
Other relevant parts of the Summary report which may require external certification, if any, will
be forwarded by the Secretariat to those LRIT system components, which have assisted the
testing, for its completion.
3.5.3.3 The Secretariat should provide those system components which have assisted the
testing with copies of the Report of test results and of the related Summary report as soon as it
receives them.
3.5.3.4 Those assisting the testing should, no later than two working days after receiving the
testing documentation, advise the Organization whether they are satisfied with the results of the
testing as documented by the LRIT system component which has undergone testing and confirm
Annex, page 18
that they certify these as true and correct by completing the relevant parts of the related
Summary report and returning it to the Organization.
3.5.3.5 Having received the relevant parts of the Summary report from those which were
required to externally certify the test cases, if any, the Secretariat will forward the complete
Summary report and Report of test results to the LRIT Coordinator for information.
3.5.3.6 In case an LRIT system component undergoing testing in the testing environment
fails to satisfactorily complete all required tests, that system component should be treated as a
system component which has not undergone any testing and should commence testing anew
through the modification testing phase route.
3.5.4 Implementation in the Production environment
3.5.4.1 Depending on the scope of the modification to the LRIT system, the modification can
either be made by the required system component(s) all at the same time or in stages. The
preferred implementation approach will be based on the specifics of the modification concerned.
Either the Committee or the LRIT Operational Governance body, defined within the Continuity of
Service Plan for the LRIT system, will decide the preferred, or required, implementation approach.
3.5.4.1.1 For modifications that must be implemented at the same time, it is anticipated that all
of the LRIT system components will have successfully completed their testing well before the
planed cut over date. If problems occur during the cut over, operational decisions will be made
as defined within the Continuity of Service Plan for the LRIT system to ensure the continued
operation of the system.
3.5.4.1.1.1 If all system components have not successfully completed testing prior to the
planned cut over, the LRIT Operational Governance body will decide whether or not to continue
the cut over. The decision will be based on the desire to maintain the LRIT system in operation
with the maximum number of LRIT system components on line and capable of exchanging LRIT
information.
3.5.4.1.2 For modifications that can be implemented in stages, the cut over will occur within
the time period defined by the guidance prepared for the modification. As each system
component completes the modification testing it will be re-integrated into the production system
in a coordinated manner.
3.5.4.1.2.1 LRIT system components, which have satisfactorily completed all required tests in
the testing environment should implement the modification in the production environment within
the time period defined by the guidance prepared for the modification. The time period could be
extended by the Secretariat depending on the magnitude of the test required to be conducted.
3.5.4.2 In case there were no additional test procedures and test cases required to be
conducted and having implementing the necessary system modifications in the production
environment, the LRIT system component concerned should notify the Organization and the
LRIT Coordinator once the required system modifications were satisfactory implemented.
Having received this notification, the modification testing phase would be considered as
complete for that system component.
3.5.4.3 In case there are test procedures and test cases required to be conducted in the
production environment, the Secretariat should provide those required to undergo testing with a
bespoke version of the Summary report and Report of test results, including the required test
procedures and test cases, as well as any particular instructions to be observed. In this case,
the following procedures should be observed:
Annex, page 19
.1 As soon as the testing is completed, the LRIT system component which

has undergone testing in the production environment should complete and
forward its Summary report and Report of test results to the Organization.
.1 When completing the testing documentation, the existing text

should not be amended in any way as this may invalidate the
whole testing process.
.2 The entries in the Report of test results should be limited either to

include a Pass or a Fail under the column headed Pass/Fail.
.3 LRIT system components should only complete the relevant part

of the Summary report which is required to be completed by the
DC undergoing testing. Other relevant parts of the Summary
report which may require external certification, if any, will be
forwarded by the Secretariat to those system components, which
have assisted the testing, for its completion.
.2 The Secretariat should provide those participating in the testing process

with copies of the Report of test results and of the related Summary report
as soon as it receives them.
.3 Those assisting the testing should, no later than two working days after
receiving the testing documentation, advise the Organization whether they
are satisfied with the results of the testing as documented by the LRIT
system component which has undergone testing in the production
environment and confirm that they certify these as true and correct by
completing the relevant parts of the related Summary report and returning it
to the Organization.
.4 Having received the relevant parts of the Summary report from those which
were required to externally certify the test cases, if any, the Secretariat will
forward the complete Summary report and Report of test results to the LRIT
Coordinator.
.5 If the LRIT system component fails to satisfactorily complete all required

tests, that system component should be treated as a system component
which has not undergone any testing and should commence testing anew
through the modification testing phase route. In this case, the Secretariat
should, as soon as the Organization has been notified, inform accordingly
those operating in the production environment and those who participated
in the modification testing of the system component in question.
Annex, page 20
ANNEX
LRIT SYSTEM TESTS
Introduction
1 The LRIT system tests pertaining to the testing of the following components of the
LRIT system:
.1 International LRIT Data Exchange;
.2 LRIT Data Centres; and
.3 LRIT Data Distribution Plan and LRIT Data Distribution Plan server.
1.1 The test procedures and test cases for each of the components of the LRIT system are
specified in appendices 2 to 4.
LRIT messages
2 The table below provides a summary of all LRIT messages (Message Types 1 to 15)
and indicates whether the message is routed between LRIT Data Centres or broadcast to all
LRIT Data Centres (i.e. data communication paths required and the associated messages
required for LRIT of ships).
Table
Summary of LRIT Messages (1)
Type Name Description/Purpose Tx(2) Rx(2) Broadcast

LRIT information (position report) messages
1 Periodic Regular periodic position reports DC2 IDE No
position
report IDE DC1
2 Polled Position report as a result of a poll DC2 IDE No

position request
report IDE DC1
3 SAR position Position report as a result of a DCx IDE No

report SAR request
IDE DC1
4 Position To enable a DC to request LRIT DC1 IDE No
request information for ships being
monitored by another DC IDE DC2
5 SAR To enable a DC to request LRIT DC1 IDE No

poll information, as a SAR user, for
request ships being monitored by another IDE DC2
DC
Annex, page 21
Type Name Description/Purpose Tx(2) Rx(2) Broadcast

6 SAR SAR request for position of ships DC1 IDE Yes
SURPIC in a specific area, broadcast via
request the IDE to all DCs IDE DCx
Other messages
7 Receipt To enable a LRIT component to DDP server DC, IDE
confirm the processing of a LRIT No
message DC2 IDE,
DDP server
IDE DC1,
DDP server
8 DDP Notification that a new or an DDP server IDE Yes
notification updated version of the DDP file is
available IDE DCx
9 DDP Request for full, incremental or DCx DDP server No

request archived version of the DDP from IDE
the DDP server
10 DDP Response to a DDP request with DDP server DCx Does not
update requested versions of the DDP IDE get routed
attached by the IDE
11 System To enable the IDE to communicate IDE DCx Yes
status a status message every 30 min to DDP server
each DC and the DDP server
advising that the system is DCx IDE
"healthy" and receive status DDP server
messages from the DCs and the
DDP server
12 Journal Routine monthly message from a R/CDC1 and IDE No
R/CDC or the IDC to the IDE IDC
containing its Journal
13 Pricing Notification that a new pricing list IDE DC Yes
notification for inter-DC charges is in place
14 Pricing Request for updated pricing list DC IDE No

request
15 Updated Updated pricing list file DC IDE No

pricing file IDE DC
Note:
(1)
Refer to the Technical specifications for communications within the LRIT system for further
information.
(2)
DC1 = requesting DC; DC2 = providing DC; DCx = all DCs; R/CDC1 = Regional or
Cooperative LRIT Data Centre.
Annex, page 22
List of abbreviations
3 The following abbreviations are used in this document:
REF: the associated regulatory reference using the following abbreviations to

indicate the related provision:
R: Regulation V/19-1;
PS: Revised performance standards and functional requirements for the

long-range identification and tracking of ships;
TS1: Revised interim technical specifications for the LRIT system

Technical specifications for the International LRIT Data Exchange;

Technical specifications for the International LRIT Data Centre;

Technical specifications for communications within the LRIT system;

Technical specifications for LRIT Data Distribution Plan;
TS5: Criteria for the location of the International LRIT Data Centre and the
International LRIT Data Exchange (MSC 83/6/2, annex 2).
For example PS: 7.1.2 indicates paragraph 7.1.2 of the Revised performance
standards.
DC: LRIT Data Centre
NDC: National LRIT Data Centre
RDC: Regional LRIT Data Centre
CDC: Co-operative LRIT Data Centre
IDC: International LRIT Data Centre
IDE: International LRIT Data Exchange
DDP: LRIT Data Distribution Plan server
LDU: LRIT Data User
N/A: Not applicable
C: Communications test used in the column headed Test type in the tables of the
test cases
F: Functional test used in the column headed Test type in the tables of the test
cases
Annex, page 23
List of appendices
Appendix 1 Communication paths Generic test diagram
Appendix 2 LRIT Data Centre test procedures and test cases
Tables 2.1 to 2.16 Test procedures and test cases
Appendix 2A LRIT Data Centre test procedures and test cases
Tables 2-A.1 to 2-A.2 Test procedures and test cases for the first
modification testing
Appendix 3 International LRIT Data Exchange test procedures and test cases
Appendix 3A International LRIT Data Exchange test procedures and test cases
Tables 3-A.1 to 3-A.2 Test procedures and test cases for the first
modification testing
Appendix 4 LRIT Data Distribution server test procedures and test cases
Appendix 5 Summary report (for LRIT Data Centres)
Appendix 6 Explanatory notes and guidance on the conduct of testing of LRIT

Data Centres
Annex, page 24
Appendix 1
COMMUNICATION PATHS
Figure 1 illustrates the communication paths within the LRIT system through a generic test
diagram for all test cases listed in this document.
The communication paths are intended to illustrate the flow of LRIT messages between
components of the LRIT system. The letters A to J represent the various communication paths
within the test environment.
The IDE, DDP server and DC blocks represent either real components of the LRIT system or
simulator components. No simulator should be connected to the production environment.
In appendices 2 to 4, where necessary, the communications paths A to N are identified within

parenthesis in some instances in the testing procedures and in test cases under the columns
headed Case and Expected results.
Figure 1
Generic test diagram
DC1
A B
C K
D L
E I
DDP
IDE F DC2 J
server
G M
H N
DCx
DC1: requesting DC; DC2: providing DC; DCx: all DCs
Annex, page 25
Appendix 2
LRIT DATA CENTRE TEST PROCEDURES AND CASES
The Pass/Fail column of a particular test case indicates the results of the specific test. A pass entry should be made when the test has been
satisfactorily conducted and the results are satisfactory. A fail entry should be made when either the test cannot be conducted or the envisaged test
cannot be satisfactorily carried out or the results of the test are not satisfactory.
The Pass/Fail column of a particular test procedure summarizes the results of the associated test cases. A pass entry should be made when all
associated test cases have been satisfactorily conducted and their results are satisfactory. A fail entry should be made when the test of anyone of the
associated test cases cannot be conducted or the envisaged test cannot be satisfactorily carried out or the results of the test are not satisfactory.
Table 2.1
Test procedure DC-1.0
Test REF Test procedure Pass/Fail

DC-1.0 PS: 7.1.8 DC1 receives a Periodic Position Report (Message Type 1) through IDE (IDE DC1). Communication paths specified in
parentheses for each test case. All parameters associated with each message should be valid unless specified otherwise in a given
test case.
Test cases DC-1.1 to DC.1.6
Required
Test REF Case Expected results Test Environment before Required Certification Pass/Fail
type entering during
DC-1.1 PS: 7.1.8 DC receives periodic Verify reception of C Prototype Yes Yes External
position report from IDE message and no further Test Yes Yes External
with all valid Message action required by DC. The Production N/A Yes External
parameters. (C) DC does not need to log or
archive the message.
Annex, page 26
Required
Test REF Case Expected results Test Environment before Required Certification Pass/Fail
DC-1.2 PS: 7.1.8 DC receives a periodic The DC does not need to C Prototype No Yes Internal
position report that does log or archive the message. Test No Yes Internal
not pass schema validation. A SOAP Fault or Receipt Production N/A No N/A
(C) Message with Receipt
code 7 is sent with
message text indicating the
reason for rejection. (D)
DC-1.3 PS: 7.1.8 Message validation with The DC does not need to C Prototype No Yes Internal
TS3: 2.2.2 zero data or incomplete log or archive the message. Test No Yes Internal
data in fields. (C) A SOAP Fault or Receipt Production N/A No N/A
Message is sent with
DC-1.4 PS: 7.1.8 The LDU addressee is Successfully reception of C Prototype Yes Yes Internal
TS3: 2.2.2 registered to the DC. (C) the message. Test Yes Yes Internal
Production N/A Yes Internal
DC-1.5 PS: 7.1.8 The LDU addressee is not The DC does not need to C Prototype No Yes Internal
TS3: 2.2.2 registered to the DC. (C) log or archive the message. Test No Yes Internal
A Receipt Message with Production N/A No N/A
Receipt code 7 is sent with
DC-1.6 PS: 7.1.8 Message with ReferenceId The DC does not need to C Prototype No Yes Internal
TS3: 2.2.2 field different of 0 but the log or archive the message. Test No Yes Internal
Reference doesn't exist in A Receipt Message with Production N/A No N/A
DC. (C) Receipt code 7 is sent with
Annex, page 27
Table 2.2

DC-2.0 PS: 7.1.7 DC1 receives a Ship Position Request (Message Type 4 and 5) sent by other LRIT Data Centre (DC2) through IDE (C).
TS3: 2.2.3 Communication paths specified in parentheses for each test case. All parameters associated with each message should be valid
unless specified otherwise in a given test case.
Test cases DC-2.1 to DC-2.9
Required
Test REF Case Expect results Test Environment before Required Certification Pass/Fail
DC-2.1 PS: 7.1.7 DC1 receives a position DC1 sends the appropriate F/C Prototype No Yes External
TS3: 2.2.3 request Message with all position report or receipt for Test Yes Yes External
TS3:2.2.1.4 valid parameters. Tests each test case to DC2. (D) Production N/A No N/A
should be performed for all All timestamps should be in
test cases as stipulated in accordance with the
Table 2.2.1 and 2.2.2. (C) provision of TS3
DC-2.2 PS: 7.1.7 DC1 receives a position DC1 sends the first DC F Prototype No Yes External
TS3: 2.2.3 request for the same ship position reports at a rate of Test Yes Yes External
TS3:2.3.3 from two DCs. One of the 30 min for duration of 3 h. Production N/A No N/A
TS3:2.3.6 DCs request position The second requesting DC
reports at a rate of 30 min receives position reports at
for 3 h while the other DC a rate of 15 min for duration
requests position reports at of 2 h. (D)
a rate of 15 min for 2 h. (C)
Annex, page 28
Required
DC-2.3 PS: 7.1.7 Message validation with The DC does not need to C Prototype No Yes Internal
TS3: 2.2.3 invalid Message parameter. log or archive the message. Test No Yes Internal
(C) A SOAP Fault or Receipt Production N/A No N/A
Message with Receipt
code 7 is sent with
DC-2.4 PS: 7.1.7 The requested ship is not A Receipt Message with F Prototype No Yes External
TS3: 2.2.3 registered to the DC. (C) Receipt code 7 is sent with Test Yes Yes External
message text indicating the Production N/A No N/A
DC-2.5 PS: 7.1.7 For non archived data, the Sent a Receipt Message F Prototype No Yes External
TS3: 2.2.3 requestor does not have with Receipt code 0 to the Test Yes Yes External
the entitlement to receive requestor. (D) Production N/A No N/A
the requested data. (C)
DC-2.6 PS: 7.1.7 For archived data the Sent a Receipt Message F Prototype No No External
TS3: 2.2.3 requestor does not have (Message Type 7) with Test Yes Yes External
the entitlement to receive Receipt code 0 to the Production N/A No N/A
the requested data. The requestor. (D)
message Request Type
parameter value is 7. (C)
DC-2.7 PS: 7.1.7 DC1 receives an archived Send a Receipt Message F Prototype No Yes External
TS3: 2.2.3 data request for a (Message Type 7) with Test Yes Yes External
registered ship that didn't Receipt code 5 or 6 to the Production N/A No N/A
transmit LRIT Information in requestor DC. (D)
the period inside the
request duration. The
Annex, page 29
Required
DC-2.8 PS: 7.1.7 DC1 receives an archived Send a Receipt Message F Prototype No Yes External
TS3: 2.2.3 data request for a ship that (Message Type 7) with Test Yes Yes External
was not registered to the Receipt code 7 to LDU. (D) Production N/A No N/A
DC during the time of the
archived request. The
DC-2.9 PS: 7.1.7 DC1 receives an archived DC sends all requested F Prototype No Yes External
TS3: 2.2.3 data request for a ship that LRIT position reports to the Test Yes Yes External
transmitted LRIT Information requestor. (D) Production N/A No N/A
in the period inside the
request duration. The
Annex, page 30
Table 2.2.1
Test cases for test DC-2.1

(Message Type 4)
Not all tests from this table are required to be externally certified. Test cases which require external certification are specified in the
Summary report set out in Appendix 5. DCs should disregard the contents of all fields that indicate having "Not valid" or "Null" parameters
when processing LRIT position request messages from another DC. Section 2.3.8 of the Technical specifications for communications within
the LRIT system provides additional information on valid messages parameters combinations for Messages 4 and 5.
Test case
Access
Type Request Port or port Distance Request Expected Result Pass/Fail
Type facility duration
0 0 Null zero (0) Null DC1 verifies that all previous terminal change requests have been reset.
1 Null zero (0) Null DC1 sends a receipt message to DC2 with a receipt code of 7. (D)
Annex, page 31
Test case
Access
1 0 Null zero (0) Null DC1 sends a receipt message to DC2 with a receipt code of 7. (D)
1 Null zero (0) Null DC1 sends the appropriate position report to DC2 (D).
2 Null zero (0) Valid entry DC1 sends the first position report to DC2 (D) within the specified periodic
rate plus 30 min. All following reports are synchronized to the specified rate
for the specified duration.
7 Null zero (0) Valid entry DC sends all requested LRIT position reports to the requestor. (D)
8 Null zero (0) Null DC1 stops sending position reports to DC2 (D).
9 Null zero (0) Null DC1 sends the appropriate position report to DC2 (D).
10 Null zero (0) Null DC1 sends the first position report to DC2 (D) within the specified periodic
Annex, page 32
Test case
Access
11 Null zero (0) Null DC1 sends the first position report to DC2 (D) within the specified periodic
1 Null zero (0) Null DC1 sends a receipt message with receipt code 7 (D).
2 Null zero (0) Valid entry DC1 sends a receipt message with receipt code 7 (D).
7 Null zero (0) Valid entry DC sends all requested LRIT position reports to the requestor. (D) This test
case is applicable to all DC types other than NDCs. If the flag State
associated with the ship has changed DCs since the time the data was
archived (Ex: RDC NDC).
1 Valid entry Valid entry Null DC1 sends a receipt message with receipt code 7 (D).
Annex, page 33
Test case
Access
2 Valid entry Valid entry Valid entry DC1 sends the appropriate position report to DC2 (D) when the ship is within
the specified distance from the specified port/port facility and during the
specified request duration.
the specified distance from the specified port/port facility and the specified
request duration.
7 Valid entry Valid entry Valid entry DC1 sends a receipt message with receipt code 7 (D).
8 Valid entry Valid entry Null DC1 stops sending position reports to DC2 (D).
9 Valid entry Valid entry Null DC1 sends a receipt message with receipt code 7 (D).
4 This access type has been reserved for future use.
Annex, page 34
Test case
Access
1 Valid entry zero (0) Null DC1 sends the appropriate position report to DC2 (D).
2 Valid entry zero (0) Valid entry DC1 sends the first position report to DC2 (D) within the specified periodic
7 Valid entry zero (0) Valid entry DC sends all requested LRIT position reports to the requestor. (D)
8 Valid entry zero (0) Null DC1 stops sending position reports to DC2 (D).
9 Valid entry zero (0) Null DC1 sends the appropriate position report to DC2 (D).
Annex, page 35
Test case
Access
Annex, page 36
Table 2.2.2
Test cases for test DC-2.1

(Message Type 5)
Not all tests from this table are required to be externally certified. Test cases which require external certification are specified in the
Summary report set out in Appendix 5. DCs should disregard the contents of all fields that indicate having "Not valid" or "Null" parameters
when processing LRIT position request messages from another DC. Section 2.3.8 of the Technical specifications for communications within
the LRIT system provides additional information on valid messages parameters combinations for Messages 4 and 5.
Test case
Access Request Port or port Distance Request Expected Result Pass/Fail
Type Type facility duration
6 1 Not valid zero (0) Null DC1 sends the appropriate position report to DC2 (D).
7 Not valid zero (0) Valid DC1 sends the appropriate position report to DC2 (D).
9 Not valid zero (0) Null DC1 sends the appropriate position report to DC2 (D).
Annex, page 37
Table 2.3

DC-3.0 PS: 7.7 DC1 receives a SAR SURPIC Request (Message Type 6) sent by another DC (C). Communication paths specified in parentheses
TS3: 2.2.4 for each test case. All parameters associated with each message should be valid unless specified otherwise in a given test case.
TS3:2.3.9
Required
DC-3.1 PS: 7.7 DC1 receives a SAR DC1 sends the 2 most F Prototype No Yes External
TS3: 2.2.4 SURPIC Request recent position reports for Test Yes Yes External
TS3:2.3.9 Message with all valid data all ships that are located Production N/A No N/A
parameters, a specified within the specified
circular area and the geographical area. (D)
number of positions
requested to 2. (C)
DC-3.2 PS: 7.7 DC1 receives a SAR DC1 sends the 2 most F Prototype No Yes External
TS3: 2.2.4 SURPIC Request recent position reports for Test Yes Yes External
TS3:2.3.9 Message with all valid data all ships that are located Production N/A No N/A
parameters, a specified within the specified
rectangular area and the geographical area. (D)
number of positions
requested to 2. (C)
Annex, page 38
Required
DC-3.3 PS: 7.7 Message validation with The DC does not need to C Prototype No Yes Internal
TS3: 2.2.4 invalid Message log or archive the message. Test No Yes Internal
parameter. (C) A SOAP Fault or Receipt Production N/A No N/A
code 7 is sent with message
text indicating the reason for
rejection. (D)
Annex, page 39
Table 2.4

DC-4.0 PS: 7.1 DC1 receives a receipt (Message Type 7) sent by another DC (C). Communication paths specified in parentheses for each test
TS3: 2.2.5 case. All parameters associated with each message should be valid unless specified otherwise in a given test case.
Required
Test Required
Test REF Case Expect results Environment before Certification Pass/Fail
type during
entering
DC-4.1 PS: 7.1 DC receives Receipt Verify reception of C Prototype No Yes Internal
TS3: 2.2.5 Message from IDE with all message and no further Test No Yes Internal
valid Message parameters. action required by DC. Production N/A No N/A
(C) The DC does not need to
log or archive the
message.
TS3: 2.2.5 invalid Message log or archive the Test No Yes Internal
parameter. (C) message. A SOAP Fault Production N/A No N/A
or Receipt Message with
Annex, page 40
Table 2.5

DC-5.0 PS: 7.1 DC1 receives a System Status Message (Message Type 11) sent by the IDE. Communication paths specified in parentheses for
TS3: 2.2.9 each test case. All parameters associated with each message should be valid unless specified otherwise in a given test case.
Required
DC-5.1 PS: 7.1 DC receives System Verify reception of message C Prototype No Yes Internal
TS3: 2.2.9 Status Message from IDE and no further action Test No Yes Internal
with all valid Message required by DC. The DC Production N/A Yes Internal
parameters. (C) does not need to log or
TS3: 2.2.9 invalid Message log or archive the message. Test No Yes Internal
parameter. (C) A SOAP Fault or Receipt Production N/A No N/A
rejection. (D)
Annex, page 41
Table 2.6

DC-6.0 PS: 7.1 DC1 sends a System Status Message (Message Type 11) to the IDE. Communication paths specified in parentheses for each test
Test case DC-6.1
Required
DC-6.1 PS: 7.1 Check if DC sends Verify transmission of F Prototype No Yes External
TS3: 2.2.9 System Status Message message. Test Yes Yes External
every 30 min to IDE with Production N/A Yes External
all valid Message
parameters. (D)
Annex, page 42
Table 2.7

DC-7.0 PS: 7.1 DC1 receives a pricing notification message (Message Type 13) from the IDE. Communication paths specified in parentheses for
Test case DC-7.1
Required
DC-7.1 PS: 7.4 DC receives pricing Verify reception of message C Prototype No Yes External
TS3: 2.2.11 notification message from and no further action Test Yes Yes External
IDE with all valid required by DC. The DC Production N/A No N/A
Message parameters. (C) does not need to log or
Annex, page 43
Table 2.8

DC-8.0 PS: 7.4 DC1 sends a Pricing request message (Message Type 14) to the IDE. Communication paths specified in parentheses for each test
Test case DC-8.1
Required
DC-8.1 PS: 7.4 DC sends a pricing Verify correct transmission C Prototype No Yes External
TS3: 2.2.12 request message to the of message and no further Test Yes Yes External
IDE with all valid Message action required by DC. Production N/A Yes External
parameters. (D)
Annex, page 44
Table 2.9

DC-9.0 PS: 7.4 DC1 receives a Pricing Update Message (Message Type 15) from the IDE. Communication paths specified in parentheses for each
TS3: 2.2.13 test case. All parameters associated with each message should be valid unless specified otherwise in a given test case.
TS3:2.3.11
Test cases DC-9.1 to 9.2
Required
DC-9.1 PS: 7.4 DC receives Pricing Verify reception of message C Prototype No Yes External
TS3: 2.2.13 Update Message from and no further action Test Yes Yes External
TS3:2.3.11 IDE with all valid required by DC. Production N/A Yes External
Message parameters. (C)
DC-9.2 PS: 7.4 Message validation with The DC does not need to log C Prototype No Yes Internal
TS3: 2.2.13 invalid Message or archive the message. A Test No Yes Internal
parameter. (C) SOAP Fault or Receipt Production N/A No N/A
rejection. (D)
Annex, page 45
Table 2.10

DC-10.0 PS: 7.4 DC1 sends a Pricing Update Message (Message Type 15) to the IDE. Communication paths specified in parentheses for each test
TS3:2.3.11
Test case DC-10.1
Required
DC-10.1 PS: 7.4 DC sends a pricing Verify correct transmission of C Prototype No Yes External
TS3: 2.2.13 Update message to the message and no further Test Yes Yes External
TS3:2.3.11 IDE with all valid action required by the DC. Production N/A No N/A
Message parameters. (D)
Annex, page 46
Table 2.11

DC-11.0 PS: 7.1 DC1 receives a DDP Notification Message (Message Type 8) from the IDE. Communication paths specified in parentheses for
PS: 7.6 each test case. All parameters associated with each message should be valid unless specified otherwise in a given test case.
TS3: 2.2.6
Required
DC-11.1 PS: 7.1 DC1 receives a DDP DC sends a DDP Request F Prototype No Yes External
PS: 7.6 Notification Message from Message (Message Type 9) Test Yes Yes External
TS3: 2.2.6 IDE with all valid Message to the DDP server with the Production N/A No N/A
parameters with an DDP update type parameter
immediate DDP update set to either 1 (with
type. (C) requested version number
parameter) or 2 within 1 hr of
receiving the notification. (L)
DC-11.2 PS: 7.1 DC receives a DDP DC sends a DDP Request F Prototype No Yes External
PS: 7.6 Notification Message from Message (Message Type 9) Test Yes Yes External
TS3: 2.2.6 IDE with all valid Message to the DDP server with the Production N/A No N/A
parameters with a regular DDP update type parameter
DDP update type. (C) set to either 0 or 2 before
midnight UTC. (L)
Annex, page 47
Required
DC-11.3 PS: 7.1 Message validation with The DC does not need to log C Prototype No Yes Internal
PS: 7.6 invalid Message or archive the message. A Test No Yes Internal
TS3: 2.2.6 parameter. (C) SOAP Fault or Receipt Production N/A No N/A
rejection. (D)
Annex, page 48
Table 2.12

DC-12.0 PS: 7.1 DC1 sends a DDP Request message (Message Type 9) to the DDP server. Communication paths specified in parentheses for
PS: 7.6 each test case. All parameters associated with each message should be valid unless specified otherwise in a given test case.
TS3: 2.2.7
Test case DC-12.1
Required
DC-12.1 PS: 7.1 DC sends a DDP Request Verify that the DC can send C Prototype No Yes External
PS: 7.6 Message to the DDP a DDP Request Message. Test Yes Yes External
TS3: 2.2.7 server with all valid Production N/A Yes External
Message parameters. (L)
Annex, page 49
Table 2.13

DC-13.0 PS: 7.1 DC1 receives a DDP Update Message (Message Type 10) from the DDP server. Communication paths specified in parentheses
PS: 7.6 for each test case. All parameters associated with each message should be valid unless specified otherwise in a given test case.
TS3: 2.2.8
Required
DC-13.1 PS: 7.1 DC receives a DDP Update DC implements the DDP F Prototype No Yes External
PS: 7.6 Message from the DDP update at the specified Test No Yes External
TS3: 2.2.8 server with all valid implementation time. Production N/A No N/A
Message parameters. The Verify that all subsequent
DDP file attachment is an messages sent by the DC
immediate incremental type. contain the correct DDP
(K) version number.
DDP file attachment is a messages sent by the DC
regular incremental type. contain the correct DDP
(K) version number.
Annex, page 50
Required
DDP file attachment is a full messages sent by the DC
type. (K) contain the correct DDP
version number.
PS: 7.6 invalid Message parameter. log or archive the Test No Yes Internal
TS3: 2.2.8 (K) message. A SOAP Fault Production N/A No N/A
or Receipt Message with
message text indicating
the reason for rejection.
(L)
Annex, page 51
Table 2.14
Test procedure R/CDC-14.0

R/CDC-14.0 PS: 7.1 R/CDC1 sends the Journal message (Message Type 12) to the IDE. Communication paths specified in parentheses for each
PS: 7.3 test case. All parameters associated with each message should be valid unless specified otherwise in a given test case.
TS3: 2.2.10
TS3:2.3.10
Test case R/CDC-14.1
Required
R/CDC-14.1 PS: 7.1 R/CDC sends a Journal Verify that the R/CDC can F Prototype No Yes External
PS: 7.3 message to the IDE with send a Journal message Test Yes Yes External
TS3: 2.2.10 all valid Message containing a valid Journal Production N/A No N/A
TS3:2.3.10 parameters. (D) file.
Annex, page 52
Table 2.15

DC-15.0 PS: 7.1.7 DC1 sends a ship Position Report (Message Type 1) to DC2 through the IDE in response to standing orders from a Contracting
TS3:2.2.2 Government associated with DC2. All parameters associated with each message should be valid unless specified otherwise in a
TS3:2.3.4 given test case.
Required
DC-15.1 PS: 7.1.7 DC1 receives a position DC1 sends the appropriate F Prototype No Yes External
TS3:2.2.2 report from their ASP that is position report to DC2. (D) Test Yes Yes External
TS3:2.3.4 within the custom coastal Production N/A No N/A
polygon of a Contracting
Government associated
with DC2 with all valid
parameters. The ship
position is neither within the
internal waters of another
nor the territorial sea of the
whose flag the ship is
flying.
Annex, page 53
Required
DC-15.2 PS: 7.1.7 DC1 receives a position DC1 does not send any F Prototype No Yes External
TS3:2.2.2 report from their ASP that is position reports to DC2. Test Yes Yes External
position is within the
Contracting Government.
DC-15.3 PS: 7.1.7 DC1 receives a position DC1 does not send any F Prototype No Yes External
TS3:2.2.2 report from their ASP that is position reports to DC2. Test Yes Yes External
position is within the
territorial sea of the
whose flag the ship is
flying.
Annex, page 54
Table 2.16

DC-16.0 PS: 7.1.7 DC1 receives a port State request from a Contracting Government associated with DC2 for a ship that is going through the internal
TS3:2.2.2 waters of another Contracting Government. All parameters associated with each message should be valid unless specified otherwise
TS3:2.3.4 in a given test case.
Required
DC-16.1 PS: 7.1.7 DC1 receives a position Sending of position reports F Prototype No Yes External
TS3:2.2.2 report from their ASP of the to DC2 is temporarily Test Yes Yes External
TS3:2.3.4 ship that is tracked by the suspended and a receipt Production N/A No N/A
port State request and it is message with receipt code
within the internal waters of 0 is sent to DC2 with an
polygon of another appropriate description
Contracting Government. indicating that the reporting
has been suspended.
Annex, page 55
Required
DC-16.2 PS: 7.1.7 DC1 receives a position Sending of position reports F Prototype No Yes External
TS3:2.2.2 report from their ASP of the to DC2 is reactivated with Test Yes Yes External
TS3:2.3.4 ship that is tracked by the the same reporting rate or a Production N/A No N/A
port State request and it is less frequent reporting rate.
not within the internal
waters polygon of another
Contracting Government.
(Ship has just left the
and the port State request
had been suspended).
Annex, page 56
Appendix 2-A
LRIT DATA CENTRE TEST PROCEDURES AND CASES
Test Procedures and cases for the first Modification testing
Table 2-A.1

DC-17.0 PS: 7.1.7 DC1 receives a Ship Position Poll Request (Message Type 4, Access Type 5, Request Type 1) sent by another LRIT Data Centre
TS3: 2.2.3 (DC2) through IDE (C). Communication paths specified in parentheses for each test case. All parameters associated with each
message should be valid unless specified otherwise in a given test case.
Annex, page 57
Required
DC-17.1 PS: 7.1.7 DC1 receives a position DC1 sends the appropriate F/C Prototype N/A N/A N/A
TS3: 2.2.3 request Message from a position report. (D) All Test Yes Yes Internal
TS3:2.2.1.4 contracting government timestamps should be in Production N/A No N/A
with a valid port parameter accordance with the
(a port listed under the provision of TS3
special adminstrative
region of the contracting
government).
DC-17.2 PS: 7.1.7 DC1 receives a position DC1 sends a receipt F/C Prototype N/A N/A N/A
TS3: 2.2.3 request Message from a message with receipt code Test Yes Yes Internal
TS3:2.2.1.4 special administratvive 0 (not entitled to data). (D) Production N/A No N/A
region with an invalid port All timestamps should be in
parameter (a port listed accordance with the
under the contracting provision of TS3
government associated
with the special
adminstratvive region's
contracting government).
DC-17.3 PS: 7.1.7 DC1 receives a SAR DC1 sends the appropriate F/C Prototype N/A N/A N/A
TS3: 2.2.3 request Message with all position report or receipt for Test Yes Yes Internal
TS3:2.2.1.4 valid parameters. Tests each test case to DC2. (D) Production N/A No N/A
should be performed for all All timestamps should be in
test cases as stipulated in accordance with the
Table 2-A.1.1. (C) provision of TS3
Annex, page 58
Table 2-A.1.1
Test case
Access Request Port or port Distance Request Expected Result Pass/Fail
Type Type facility duration
6 7 Not valid zero (0) Valid DC1 sends the appropriate position reports to DC2 (D).
9 Not valid zero (0) Null DC1 sends the appropriate position report to DC2 (D).
Annex, page 59
Table 2-A.2

DC-8.0 PS: 7.4 DC1 sends a Pricing request message (Message Type 14) to the IDE. Communication paths specified in parentheses for each test
Test case DC-8.1
Required
DC-8.1 PS: 7.4 DC sends a pricing Verify correct transmission C Prototype N/A N/A N/A
TS3: 2.2.12 request message to the of message and no further Test Yes Yes External
IDE with all valid Message action required by DC. Production N/A Yes External
parameters. (D)
Annex, page 60
Appendix 3
International LRIT Data Exchange test procedures and cases
Table 3.1
Test procedures IDE-1.0

IDE-1.0 PS: 10.3.1 to IDE receives a position report from DC1. Communication paths specified in parentheses for each test case. All parameters
PS: 10.3.4 associated with each message should be valid unless specified otherwise in a given test case.
PS: 10.3.7 to
PS: 10.3.13
PS: 12.1
TS1: 2.1.1
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.2
TS3: 2.3.1
Annex, page 61
Test cases IDE-1.1 to IDE-1.22
Required
IDE-1.1 PS: 10.3.1 to IDE receives a position Message stored in F Prototype No Yes External
PS: 10.3.4 report with an invalid LRIT Journal, Receipt Message Test No Yes External
PS: 10.3.7 to Data User Requestor with Receipt code 7 is Production No No No
PS: 10.3.13 parameter. (D) sent to the originator (C)
TS1: 2.1.1 and no further action is
TS1: 3.2.1 taken.
TS3: 2.1.2
TS3: 2.2.2
TS3: 2.3.1
IDE-1.2 PS: 10.3.1 to IDE receives a position Message stored in F Prototype No Yes External
PS: 10.3.4 report with an invalid DDP Journal, Receipt Message Test No Yes External
PS: 10.3.7 to version number parameter with Receipt code 9 is Production No No No
PS: 10.3.13 (Not a SAR message). sent to the originator (C)
TS1: 2.1.1 (D) and no further action is
TS1: 3.2.1 taken.
TS3: 2.1.2
TS3: 2.2.2
TS3: 2.3.1
IDE-1.3 PS: 10.3.1 to The LRIT ID of the Data Message stored in F Prototype No Yes External
PS: 10.3.4 User Provider does not Journal, Receipt Message Test No Yes External
PS: 10.3.7 to correlate with the LRIT ID with Receipt code 7 is Production No No No
PS: 10.3.13 found in the certificate of sent to the originator (C)
PS: 12.1 the sender. (D) and no further action is
TS1: 2.1.1 taken.
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.2
TS3: 2.3.1
Annex, page 62
Required
IDE-1.4 PS: 10.3.1 to The LRIT ID of the Data Message stored in F Prototype No Yes External
PS: 10.3.4 User Provider is invalid. Journal, Receipt Message Test No Yes External
PS: 10.3.7 to (D) with Receipt code 7 (C) is Production No No No
PS: 10.3.13 sent to the originating DC
TS1: 2.1.1 as identified in the PKI
TS1: 3.2.1 certificate and no further
TS3: 2.1.2 action is taken.
TS3: 2.2.2
TS3: 2.3.1
IDE-1.5 PS: 10.3.1 to SAR periodic position Message stored in F Prototype No Yes External
PS: 10.3.4 report sent with all valid Journal and routed Test No Yes External
PS: 10.3.7 to parameters. (D) appropriately by IDE. (F) Production No Yes External
PS: 10.3.13
TS1: 2.1.1
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.2
TS3: 2.3.1
PS: 10.3.4 report sent with invalid Journal, Receipt Message Test No Yes External
PS: 10.3.7 to LRIT Data User with Receipt code 7 (C) is Production No No No
PS: 10.3.13 Requestor parameter. (D) sent to the originator and
TS1: 2.1.1 no further action is taken.
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.2
TS3: 2.3.1
Annex, page 63
Required
PS: 10.3.4 report sent with invalid Journal, position report Test No Yes External
PS: 10.3.7 to DDP version number routed to destination. (F) Production No No No
PS: 10.3.13 parameter. (D)
TS1: 2.1.1
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.2
TS3: 2.3.1
PS: 10.3.4 report sent with the LRIT Journal, Receipt Message Test No Yes External
PS: 10.3.7 to ID of the Data User with Receipt code 7 (C) is Production No No No
PS: 10.3.13 Provider not correlating sent to the originator and
PS: 12.1 with the LRIT ID found in no further action is taken.
TS1: 2.1.1 the certificate of the
TS1: 3.2.1 sender. (D)
TS3: 2.1.2
TS3: 2.2.2
TS3: 2.3.1
PS: 10.3.4 report sent with an invalid Journal, Receipt Message Test No Yes External
PS: 10.3.7 to Data User Provider with Receipt code 7 (C) is Production No No No
PS: 10.3.13 parameter. (D) sent to the originating DC
TS3: 2.2.2
TS3: 2.3.1
Annex, page 64
Required
PS: 10.3.4 report sent with an invalid Journal, Receipt Message Test No Yes External
PS: 10.3.7 to Data User Requestor with Receipt code 7 (C) is Production No No No
PS: 10.3.13 parameter. (D) sent to the originator and
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.2
TS3: 2.3.1
IDE-1.11 PS: 10.3.1 to Polled position report sent Message stored in F Prototype No Yes External
PS: 10.3.4 with an invalid DDP Journal, Receipt Message Test No Yes External
PS: 10.3.7 to version number with Receipt code 9 (C) is Production No No No
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.2
TS3: 2.3.1
PS: 10.3.4 with the LRIT ID of the Journal, Receipt Message Test No Yes External
PS: 10.3.7 to Data User Provider not with Receipt code 7 sent Production No No No
PS: 10.3.13 correlating with the LRIT to DC associated with the
PS: 12.1 ID found in the certificate Data User Provider and
TS1: 2.1.1 of the sender. (D) no further action is taken.
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.2
TS3: 2.3.1
Annex, page 65
Required
PS: 10.3.4 with an invalid Data User Journal, Receipt Message Test No Yes External
PS: 10.3.7 to Provider. (D) with Receipt code 7 (C) is Production No No No
PS: 10.3.13 sent to the originator and
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.2
TS3: 2.3.1
PS: 10.3.4 with all valid parameters. Journal, IDE routes Test No Yes External
PS: 10.3.7 to (D) position report to the Production No No No
PS: 10.3.13 appropriate DC. (F)
TS1: 2.1.1
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.2
TS3: 2.3.1
IDE-1.15 PS: 10.3.1 to SAR Polled position Message stored in F Prototype No Yes External
PS: 10.3.4 report (Message Type 2, Journal, Receipt Message Test No Yes External
PS: 10.3.7 to Response Type 4) sent with Receipt code 7 (C) is Production No No No
PS: 10.3.13 with an invalid LRIT Data sent to the originator and
TS1: 2.1.1 User Requestor no further action is taken.
TS1: 3.2.1 parameter. (D)
TS3: 2.1.2
TS3: 2.2.2
TS3: 2.3.1
Annex, page 66
Required
PS: 10.3.4 report (Message Type 2, Journal, IDE routes Test No Yes External
PS: 10.3.7 to Response Type 4) sent position report to the Production No No No
PS: 10.3.13 with an invalid DDP appropriate DC. (F)
TS1: 2.1.1 version number
TS3: 2.1.2
TS3: 2.2.2
TS3: 2.3.1
PS: 10.3.13 with the LRIT ID of the sent to the originator and
PS: 12.1 Data User Provider not no further action is taken.
TS1: 2.1.1 correlating with the LRIT
TS1: 3.2.1 ID found in the certificate
TS3: 2.1.2 of the sender. (D)
TS3: 2.2.2
TS3: 2.3.1
PS: 10.3.13 with an invalid Data User sent to the originating DC
TS1: 2.1.1 Provider parameter. (D) as identified in the PKI
TS3: 2.2.2
TS3: 2.3.1
Annex, page 67
Required
IDE-1.19 PS: 10.3.1 to SAR position report Message stored in F Prototype No Yes External
PS: 10.3.4 (Message Type 3) sent Journal, Receipt Message Test No Yes External
PS: 10.3.7 to with an invalid Data User with Receipt code 7 (C) is Production No No No
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.2
TS3: 2.3.1
PS: 10.3.4 (Message Type 3) sent Journal, IDE routes Test No Yes External
PS: 10.3.7 to with an invalid DDP position report to the Production No No No
PS: 10.3.13 version number appropriate DC. (F)
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.2
TS3: 2.3.1
PS: 10.3.7 to with the LRIT ID of the with Receipt code 7 (C) is Production No No No
PS: 10.3.13 Data User Provider not sent to the originator and
TS1: 2.1.1 correlating with the LRIT no further action is taken.
TS1: 3.2.1 ID found in the certificate
TS3: 2.1.2 of the sender. (D)
TS3: 2.2.2
TS3: 2.3.1
Annex, page 68
Required
PS: 10.3.7 to with an invalid Data User with Receipt code 7 (C) is Production No No No
PS: 10.3.13 Provider parameter. (D) sent to the originating DC
TS3: 2.2.2
TS3: 2.3.1
Annex, page 69
Table 3.2

IDE-2.0 PS: 10.3.1 to IDE receives a position request from DC1. Communication paths specified in parentheses for each test case.
PS: 10.3.4 All parameters associated with each message should be valid unless specified otherwise in a given test case.
PS: 10.3.7 to
PS: 10.3.11
PS: 12.1
TS1: 2.1.1
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.3
TS3: 2.3.1
TS3: 2.3.3
TS3: 2.3.5
TS3: 2.3.7
Annex, page 70
Required
IDE-2.1 PS: 10.3.1 to Ship Position Request Message stored in F Prototype No Yes External
PS: 10.3.4 Message (Message Journal, Receipt Message Test No Yes External
PS: 10.3.7 to Type 4) sent with an with Receipt code 7 (C) is Production No No No
PS: 10.3.11 invalid Data User sent to the originating DC
TS1: 2.1.1 Requestor. (D) as identified in the PKI
TS3: 2.2.3
TS3: 2.3.1
TS3: 2.3.3
TS3: 2.3.5
TS3: 2.3.7
PS: 10.3.7 to Type 4) sent with the LRIT with Receipt code 7 (C) is Production No No No
PS: 10.3.11 ID of the Data User sent to the originator and
PS: 12.1 Requestor not correlating no further action is taken.
TS1: 2.1.1 with the LRIT ID found in
TS3: 2.2.3
TS3: 2.3.1
TS3: 2.3.3
TS3: 2.3.5
TS3: 2.3.7
Annex, page 71
Required
PS: 10.3.7 to Type 4) with invalid DDP with Receipt code 9 (C) is Production No No No
PS: 10.3.11 version. (D) sent to the originator and
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.3
TS3: 2.3.1
TS3: 2.3.3
TS3: 2.3.5
TS3: 2.3.7
IDE-2.4 PS: 10.3.1 to SAR Poll Request Message stored in F Prototype No Yes External
PS: 10.3.11 invalid Data User sent to the originator and
TS1: 2.1.1 Requestor. (D) no further action is taken.
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.3
TS3: 2.3.1
TS3: 2.3.3
TS3: 2.3.7
Annex, page 72
Required
PS: 10.3.7 to Type 5) sent with the LRIT with Receipt code 7 (C) is Production No No No
PS: 10.3.11 ID of the Data User sent to the originator and
PS: 12.1 Requestor not correlating no further action is taken.
TS1: 2.1.1 with the LRIT ID found in
TS3: 2.2.3
TS3: 2.3.1
TS3: 2.3.3
TS3: 2.3.7
PS: 10.3.4 Message (Message Journal, IDE routes Test No Yes External
PS: 10.3.7 to Type 5) sent with an position request to the Production No No No
PS: 10.3.11 invalid DDP version. (D) appropriate DC. (F)
TS1: 2.1.1
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.3
TS3: 2.3.1
TS3: 2.3.3
TS3: 2.3.7
Annex, page 73
Required
PS: 10.3.11 invalid Data User Provider sent to the originator and
TS1: 2.1.1 parameter. (D) no further action is taken.
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.3
TS3: 2.3.1
TS3: 2.3.3
TS3: 2.3.7
IDE-2.8 PS: 10.3.1 to Valid SAR Poll Request Message stored in F Prototype No Yes External
PS: 10.3.4 Message (Message Journal, IDE routes Test No Yes External
PS: 10.3.7 to Type 5). (D) position request to the Production No Yes External
PS: 10.3.11 appropriate DC. (F)
TS1: 2.1.1
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.3
TS3: 2.3.1
TS3: 2.3.3
TS3: 2.3.7
Annex, page 74
Required
IDE-2.9 PS: 10.3.1 to Valid Ship Position Message stored in F Prototype No Yes External
PS: 10.3.4 Request Message, Journal, IDE routes Test No Yes External
PS: 10.3.7 to Coastal (Message Type 4, position request to the Production No No No
PS: 10.3.11 Access Type 1). (D) appropriate DC. (F)
TS1: 2.1.1
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.3
TS3: 2.3.1
TS3: 2.3.3
TS3: 2.3.5
TS3: 2.3.7
PS: 10.3.4 Request Message, Flag Journal, IDE routes Test No Yes External
PS: 10.3.7 to (Message Type 4, Access position request to the Production No No No
PS: 10.3.11 Type 2). (D) appropriate DC. (F)
TS1: 2.1.1
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.3
TS3: 2.3.1
TS3: 2.3.3
TS3: 2.3.5
TS3: 2.3.7
Annex, page 75
Required
PS: 10.3.4 Request Message, Port Journal, IDE routes Test No Yes External
PS: 10.3.7 to with distance trigger from position request to the Production No No No
PS: 10.3.11 port/port facility (Message appropriate DC. (F)
TS1: 2.1.1 Type 4, Access Type 3).
TS1: 3.2.1 (D)
TS3: 2.1.2
TS3: 2.2.3
TS3: 2.3.1
TS3: 2.3.3
TS3: 2.3.5
TS3: 2.3.7
PS: 10.3.7 to with distance trigger from position request to the Production No No No
PS: 10.3.11 coast (Message Type 4, appropriate DC. (F)
TS1: 2.1.1 Access Type 3). (D)
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.3
TS3: 2.3.1
TS3: 2.3.3
TS3: 2.3.5
TS3: 2.3.7
Annex, page 76
Required
PS: 10.3.7 to with time trigger (Message position request to the Production No No No
PS: 10.3.11 Type 4, Access Type 5). appropriate DC. (F)
TS1: 2.1.1 (D)
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.3
TS3: 2.3.1
TS3: 2.3.3
TS3: 2.3.5
TS3: 2.3.7
Annex, page 77
Table 3.3

IDE-3.0 PS: 10.3.1 to IDE receives a SAR SURPIC request from DC1. Communication paths specified in parentheses for each test case.
PS: 10.3.7 to
PS: 10.3.11
PS: 12.1
TS1: 2.1.1.1
TS1: 2.1.1.4.1
TS1: 2.1.1.6
TS1: 2.1.1.8
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.4
TS3: 2.2.4
Annex, page 78
Required
IDE-3.1 PS: 10.3.1 to SAR SURPIC Request Message stored in F Prototype No Yes External
PS: 10.3.4 (Message Type 6) with Journal, IDE routes Test No Yes External
PS: 10.3.7 to invalid Message type position request to all Production No No No
PS: 10.3.11 parameter. (D) DCs. (G)
TS1: 2.1.1
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.4
TS3: 2.3.1
PS: 10.3.7 to invalid Message ID position request all DCs. Production No No No
PS: 10.3.11 parameter. (D) (G)
TS1: 2.1.1
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.4
TS3: 2.3.1
Annex, page 79
Required
PS: 10.3.4 (Message Type 6) with Journal, Receipt Message Test No Yes External
PS: 10.3.7 to invalid LRIT Data with Receipt code 7 (C) is Production No No No
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.4
TS3: 2.3.1
PS: 10.3.7 to invalid SAR Circular Area position request all DCs. Production No No No
TS1: 2.1.1
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.4
TS3: 2.3.1
TS3: 2.3.6
Annex, page 80
Required
PS: 10.3.7 to invalid Number of position request all DCs. Production No No No
PS: 10.3.11 Positions parameter. (D) (G)
TS1: 2.1.1
TS1: 3.2.1
TS3: 2.1.2
TS3: 2.2.4
TS3: 2.3.1
TS3: 2.3.6
PS: 10.3.7 to invalid Time stamp position request all DCs. Production No No No
TS1: 2.1.1.1
TS1: 2.1.1.4.1
TS1: 2.1.1.6
TS1: 2.1.1.8
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.4
TS3: 2.2.4
Annex, page 81
Required
PS: 10.3.7 to invalid DDP version position request all DCs. Production No No No
PS: 10.3.11 number parameter. (D) (G)
TS1: 2.1.1.1
TS1: 2.1.1.4.1
TS1: 2.1.1.6
TS1: 2.1.1.8
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.4
TS3: 2.2.4
PS: 10.3.7 to invalid Test parameter. position request all DCs. Production No No No
PS: 10.3.11 (D) (G)
TS1: 2.1.1.1
TS1: 2.1.1.4.1
TS1: 2.1.1.6
TS1: 2.1.1.8
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.4
TS3: 2.2.4
Annex, page 82
Required
PS: 10.3.7 to invalid SAR Rectangular position request all DCs. Production No No No
PS: 10.3.11 Area parameter. (D) (G)
TS1: 2.1.1.1
TS1: 2.1.1.4.1
TS1: 2.1.1.6
TS1: 2.1.1.8
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.4
TS3: 2.2.4
IDE-3.10 PS: 10.3.1 to Valid SAR SURPIC Message stored in F Prototype No Yes External
PS: 10.3.4 Request (Message Journal, IDE routes Test No Yes External
PS: 10.3.7 to Type 6). (D) position request all DCs. Production No Yes External
PS: 10.3.11 (G)
TS1: 2.1.1.1
TS1: 2.1.1.4.1
TS1: 2.1.1.6
TS1: 2.1.1.8
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.4
TS3: 2.2.4
Annex, page 83
Table 3.4

IDE-4.0 PS: 10.3.1 to IDE receives a Receipt Message from DC1. Communication paths specified in parentheses for each test case.
PS: 10.3.7 to
PS: 10.3.11
PS: 12.1
TS1: 2.1.1.1
TS1: 2.1.1.4.1
TS1: 2.1.1.6
TS1: 2.1.1.8
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.4
TS3: 2.2.5
Annex, page 84
Required
IDE-4.1 PS: 10.3.1 to Receipt Message received Message stored in F Prototype No Yes External
PS: 10.3.4 with an invalid Message Journal, IDE routes to Test No Yes External
PS: 10.3.7 to type parameter. (D) appropriate DC. (F) Production No No No
PS: 10.3.11
TS1: 2.1.1.1
TS1: 2.1.1.4.1
TS1: 2.1.1.6
TS1: 2.1.1.8
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.4
TS3: 2.2.5
IDE-4.2 PS: 10.3.1 to Receipt Message received Message stored in journal, F Prototype No Yes External
PS: 10.3.4 with an invalid message IDE routes message to Test No Yes External
PS: 10.3.7 to ID parameter. (D) appropriate DC. (F) Production No No No
PS: 10.3.11
TS1: 2.1.1.1
TS1: 2.1.1.4.1
TS1: 2.1.1.6
TS1: 2.1.1.8
TS1: 3.2.1.1.1
TS1:3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.4
TS3: 2.2.5
Annex, page 85
Required
PS: 10.3.4 with an invalid reference IDE routes message to Test No Yes External
PS: 10.3.7 to ID parameter. (D) appropriate DC. (F) Production No No No
PS: 10.3.11
TS1: 2.1.1.1
TS1: 2.1.1.4.1
TS1: 2.1.1.6
TS1: 2.1.1.8
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.4
TS3: 2.2.5
PS: 10.3.4 with an invalid Receipt IDE routes message to Test No Yes External
PS: 10.3.7 to Code parameter. (D) appropriate DC. (F) Production No No No
PS: 10.3.11
TS1: 2.1.1.1
TS1: 2.1.1.4.1
TS1: 2.1.1.6
TS1: 2.1.1.8
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.4
TS3: 2.2.5
Annex, page 86
Required
PS: 10.3.4 with an invalid Destination Journal, Receipt Message Test No Yes External
PS: 10.3.7 to parameter. (D) with Receipt code 7 (C) is Production No No No
TS1: 2.1.1.1 no further action is taken.
TS1: 2.1.1.4.1
TS1: 2.1.1.6
TS1: 2.1.1.8
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.4
TS3: 2.2.5
PS: 10.3.4 with an invalid Originator Journal, Receipt Message Test No Yes External
TS1: 2.1.1.1 as identified in the PKI
TS1: 2.1.1.4.1 certificate and no further
TS1: 2.1.1.6 action is taken.
TS1: 2.1.1.8
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.4
TS3: 2.2.5
Annex, page 87
Required
PS: 10.3.4 with the LRIT ID in the Journal, Receipt Message Test No Yes External
PS: 10.3.7 to Originator parameter not with Receipt code 7 (C) is Production No No No
PS: 10.3.11 correlating with the LRIT sent to the originator and
TS1: 2.1.1.1 ID in the certificate. (D) no further action is taken.
TS1: 2.1.1.4.1
TS1: 2.1.1.6
TS1: 2.1.1.8
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.4
TS3: 2.2.5
PS: 10.3.4 with invalid Message Text. Journal, IDE routes Test No Yes External
PS: 10.3.7 to (D) message to appropriate Production No No No
PS: 10.3.11 DC. (F)
TS1: 2.1.1.1
TS1: 2.1.1.4.1
TS1: 2.1.1.6
TS1: 2.1.1.8
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.4
TS3: 2.2.5
Annex, page 88
Required
PS: 10.3.4 with an invalid Time stamp Journal, IDE routes Test No Yes External
PS: 10.3.7 to parameter. (D) message to appropriate Production No No No
PS: 10.3.11 DC. (F)
TS1: 2.1.1.1
TS1: 2.1.1.4.1
TS1: 2.1.1.6
TS1: 2.1.1.8
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.4
TS3: 2.2.5
TS1: 2.1.1.4.1
TS1: 2.1.1.6
TS1: 2.1.1.8
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.4
TS3: 2.2.5
Annex, page 89
Required
PS: 10.3.4 with an invalid Test Journal, IDE routes Test No Yes External
PS: 10.3.7 to parameter. (D) message to appropriate Production No No No
PS: 10.3.11 DC. (F)
TS1: 2.1.1.1
TS1: 2.1.1.4.1
TS1: 2.1.1.6
TS1: 2.1.1.8
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.4
TS3: 2.2.5
Annex, page 90
Table 3.5

IDE-5.0 PS: 10.3.1 to IDE receives a DDP Notification Message from the DDP server. Communication paths specified in parentheses for each test
PS: 10.3.4 case. All parameters associated with each message should be valid unless specified otherwise in a given test case.
PS: 10.3.7 to
PS: 10.3.11
PS: 10.3.14
TS1: 2.1.1.1
TS1: 2.1.1.4.1
TS1: 2.1.1.6
TS1: 2.1.1.8
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.5
TS3: 2.2.6
Annex, page 91
Required
IDE-5.1 PS: 10.3.14 DDP Notification Message Message stored in F Prototype No Yes External
TS1: 2.1.1.1 received with an invalid Journal, Receipt Message Test No Yes External
TS1: 2.1.1.4.1 Message type parameter. with Receipt code 7 (B) is Production No No No
TS1: 2.1.1.6 (A) sent to the originator and
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.5
TS3: 2.2.6
TS1: 2.1.1.4.1 Message ID parameter. with Receipt code 7 (B) is Production No No No
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.5
TS3: 2.2.6
Annex, page 92
Required
TS1: 2.1.1.4.1 Message parameter. (A) with Receipt code 7 (B) is Production No No No
TS1: 2.1.1.6 sent to the originator and
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.5
TS3: 2.2.6
TS1: 2.1.1.4.1 Time stamp parameter. with Receipt code 7 (B) is Production No No No
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.5
TS3: 2.2.6
Annex, page 93
Required
TS1: 2.1.1.4.1 DDP version number with Receipt code 9 (B) is Production No No No
TS1: 2.1.1.6 parameter (XML schema sent to the originator and
TS1: 2.1.1.8 validation only). (A) no further action is taken.
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.5
TS3: 2.2.6
TS1: 2.1.1.4.1 Test parameter. (A) with Receipt code 7 (B) is Production No No No
TS1: 2.1.1.6 sent to the originator and
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.5
TS3: 2.2.6
Annex, page 94
Required
IDE-5.7 PS: 10.3.1 to DDP Notification Message DDP notification will be F Prototype No Yes External
PS: 10.3.4 received with all valid broadcast to all DCs. Test No Yes External
PS: 10.3.7 to parameter. (A) A DDP Request will be Production No No No
PS: 10.3.11 sent to the DDP server.
PS: 10.3.14 All messages will be
TS1: 2.1.1.1 stored in Journal.
TS1: 2.1.1.4.1
TS1: 2.1.1.6
TS1: 2.1.1.8
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.5
TS3: 2.2.6
Annex, page 95
Table 3.6

IDE-6.0 PS: 10.3.1 IDE receives a DDP Update message from the DDP server. Communication paths specified in parentheses for each test case.
TS1: 2.1.1.1
TS1: 2.1.1.4.1
TS1: 2.1.1.6
TS1: 2.1.1.8
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.5
TS3: 2.2
Annex, page 96
Required
IDE-6.1 PS: 10.3.14 IDE receives a DDP Message stored in F Prototype No Yes External
TS1: 2.1.1.1 Update Message with an Journal, Receipt Message Test No Yes External
TS1: 2.1.1.4.1 invalid Message type with Receipt code 7 (B) Production No No No
TS1: 2.1.1.6 parameter. (A) sent to DDP server and no
TS1: 2.1.1.8 further action is taken.
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.5
TS3: 2.2.8
TS1: 2.1.1.4.1 invalid Message ID with Receipt code 7 (B) Production No No No
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.5
TS3: 2.2.8
Annex, page 97
Required
TS1: 2.1.1.4.1 invalid Message with Receipt code 7 (B) Production No No No
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.5
TS3: 2.2.8
TS1: 2.1.1.4.1 invalid Time stamp with Receipt code 7 (B) Production No No No
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.5
TS3: 2.2.8
Annex, page 98
Required
TS1: 2.1.1.4.1 invalid DDP version with Receipt code 9 (B) Production No No No
TS1: 2.1.1.6 number parameter (XML sent to DDP server and no
TS1: 2.1.1.8 Schema validation only). further action is taken.
TS1: 3.2.1.1.1 (A)
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.5
TS3: 2.2.8
TS1: 2.1.1.4.1 invalid file parameter. (A) with Receipt code 7 (B) Production No No No
TS1: 2.1.1.6 sent to DDP server and no
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.5
TS3: 2.2.8
Annex, page 99
Required
TS1: 2.1.1.4.1 invalid Test parameter. with Receipt code 7 (B) Production No No No
TS1: 2.1.1.6 (A) sent to DDP server and no
TS1: 3.2.1.1.1
TS1: 3.2.1.1.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.5
TS3: 2.2.8
IDE-6.8 PS: 10.3.1 IDE receives a DDP The following results F Prototype No Yes External
PS: 10.3.14 Update Message for a full occur: Test No Yes External
TS1: 2.1.1.1 DDP (DDP Update - Message stored in Production No No No
TS1: 2.1.1.4.1 Type 3) with all valid Journal.
TS1: 2.1.1.6 parameter. (A) - Routing tables are
TS1: 2.1.1.8 updated.
TS1: 3.2.1.1.1 - Update system DDP
TS1: 3.2.1.1.2 version (IDE local
TS1: 3.3.2 copy).
TS1: 3.3.3
TS1: 3.3.5
TS3: 2.2.8
Annex, page 100
Required
IDE-6.9 PS: 10.3.1 IDE receives a DDP The following results occur F Prototype No Yes External
PS: 10.3.14 Update Message for an immediately: Test No Yes External
TS1: 2.1.1.1 incremental, regular DDP - Message stored in Production No No No
TS1: 2.1.1.4.1 (DDP Update Type 0) with Journal.
TS1: 2.1.1.6 all valid parameter. (A) The following results occur
TS1: 2.1.1.8 at implementation time:
TS1: 3.2.1.1.1 - Routing tables are
TS1: 3.2.1.1.2 updated based
TS1: 3.3.2 - Update system DDP
TS1: 3.3.3 version (IDE local
TS1: 3.3.5 copy).
TS3: 2.2.8
TS1: 2.1.1.1 incremental immediate - Message stored in Production No No No
TS1: 2.1.1.4.1 DDP (DDP Update Journal.
TS1: 2.1.1.6 Type 1) with all valid The following results occur
TS1: 2.1.1.8 parameter. (A) at implementation time:
TS1: 3.2.1.1.1 - Routing tables are
TS1: 3.2.1.1.2 updated based
TS1: 3.3.5 copy).
TS3: 2.2.8
Annex, page 101
Required
TS1: 2.1.1.1 incremental all DDP (DDP - Message stored in Production No No No
TS1: 2.1.1.4.1 Update Type 2) with all Journal.
TS1: 2.1.1.6 valid parameter. (A) The following results occur
TS1: 2.1.1.8 at implementation time:
TS1: 3.2.1.1.1 - Routeing tables are
TS1: 3.2.1.1.2 updated [based]
TS1: 3.3.5 copy).
TS3: 2.2.8
Annex, page 102
Table 3.7

IDE-7.0 PS: 10.3.1 to IDE receives a System status message. Communication paths specified in parentheses for each test case. All parameters
PS: 10.3.7 to
PS: 10.3.11
PS: 10.3.14
TS3: 2.2.9
Required
IDE-7.1 PS: 10.3.1 to IDE receives a System Message stored in F Prototype No Yes External
PS: 10.3.4 Status Message with an Journal, Receipt Message Test No Yes External
PS: 10.3.7 to invalid Originator with Receipt code 7 (B Production No No No
PS: 10.3.11 parameter. (A and D) and C) is sent to the
PS: 10.3.14 originator as identified in
TS3: 2.2.9 the PKI certificate and no
further action is taken.
Annex, page 103
Required
IDE-7.2 PS: 10.3.1 to IDE receives a System Message stored in F Prototype No Yes External
PS: 10.3.4 Status Message with an Journal, Receipt Message Test No Yes External
PS: 10.3.7 to invalid Test parameter. with Receipt code 7 (B Production No No No
PS: 10.3.11 (A and D) and C) is sent to the
PS: 10.3.14 originator and no further
IDE-7.3 PS: 10.3.1 to IDE receives a System The following results F Prototype No Yes Internal
PS: 10.3.4 Status Message with all occur: Test No Yes External
PS: 10.3.7 to valid parameters. - Message stored in Production No Yes Internal
PS: 10.3.11 (A and D) Journal.
PS: 10.3.14 - Database updated.
TS3: 2.2.9 - Admin interface
reflects change in
status.
Annex, page 104
Table 3.8

IDE-8.0 PS: 10.3.1 to IDE receives a LRIT Journal message. Communication paths specified in parentheses for each test case. All parameters
PS: 10.3.7 to
PS: 10.3.11
PS: 10.3.6
TS3: 2.2.11
TS3: 2.2.13
Required
IDE-8.1 PS: 10.3.1 to LRIT Journal Message Message stored in F Prototype No Yes External
PS: 10.3.4 with an invalid Message Journal, Receipt Message Test No Yes External
PS: 10.3.7 to type. (D) with Receipt code 7 (C) is Production No No No
PS: 10.3.6 no further action is taken.
TS3: 2.2.11
TS3: 2.2.13
PS: 10.3.7 to ID. (D) with Receipt code 7 (C) is Production No No No
TS3: 2.2.11
TS3: 2.2.13
Annex, page 105
Required
PS: 10.3.4 with an invalid Message. Journal, Receipt Message Test No Yes External
TS3: 2.2.11
TS3: 2.2.13
PS: 10.3.4 with an invalid Time Journal, Receipt Message Test No Yes External
PS: 10.3.7 to stamp. (D) with Receipt code 7 (C) is Production No No No
TS3: 2.2.11
TS3: 2.2.13
PS: 10.3.4 with an invalid Originator. Journal, Receipt Message Test No Yes External
PS: 10.3.6 as identified in the PKI
PS: 10.3.4 with an invalid Journal file. Journal, Receipt Message Test No Yes External
TS3: 2.2.11
TS3: 2.2.13
Annex, page 106
Required
TS3: 2.2.11
TS3: 2.2.13
PS: 10.3.4 with an invalid Test Journal, Receipt Message Test No Yes External
TS3: 2.2.11
TS3: 2.2.13
IDE-8.9 PS: 10.3.1 to Valid LRIT Journal Message header stored in F Prototype No Yes Internal
PS: 10.3.4 Message. (D) Journal and message file Test No Yes External
PS: 10.3.7 to is processed (included into Production No No No
PS: 10.3.11 IDE own journal).
PS: 10.3.6
TS3: 2.2.11
TS3: 2.2.13
Annex, page 107
Table 3.9

IDE-9.0 PS: 10.3.1 to IDE receives a Pricing Request message. Communication paths specified in parentheses for each test case.
PS: 10.3.7 to
PS: 10.3.11
PS: 10.3.15
TS1: 3.2
TS1: 3.3.1
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.8
TS1: 3.9
TS3: 2.1
TS3: 2.2.1
TS3: 2.2.12
TS3: 2.3.11
Annex, page 108
Required
IDE-9.1 PS: 10.3.1 to Pricing Request Message Message stored in F Prototype No Yes External
PS: 10.3.7 to type parameter. (D) with Receipt code 7 (C) is Production No No No
TS1: 3.2
TS1: 3.3.1
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.8
TS1: 3.9
TS3: 2.1
TS3: 2.2.1
TS3: 2.2.12
TS3: 2.3.11
PS: 10.3.7 to ID parameter. (D) with Receipt code 7 (C) is Production No No No
TS1: 3.2
TS1: 3.3.1
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.8
TS1: 3.9
TS3: 2.1
TS3: 2.2.1
TS3: 2.2.12
TS3: 2.3.11
Annex, page 109
Required
IDE-9.3 PS: 10.3.1 to Pricing Request Message Message stored in F Prototype No Yes ExternalN/A
PS: 10.3.4 with an invalid Originator Journal, Receipt Message Test No Yes External
PS: 10.3.15 as identified in the PKI
TS1: 3.2 certificate and no further
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.8
TS1: 3.9
TS3: 2.1
TS3: 2.2.1
TS3: 2.2.12
TS3: 2.3.11
PS: 10.3.4 with an invalid Time stamp Journal, Receipt Message Test No Yes External
TS1: 3.2
TS1: 3.3.1
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.8
TS1: 3.9
TS3: 2.1
TS3: 2.2.1
TS3: 2.2.12
TS3: 2.3.11
Annex, page 110
Required
TS1: 3.2
TS1: 3.3.1
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.8
TS1: 3.9
TS3: 2.1
TS3: 2.2.1
TS3: 2.2.12
TS3: 2.3.11
TS1: 3.2
TS1: 3.3.1
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.8
TS1: 3.9
TS3: 2.1
TS3: 2.2.1
TS3: 2.2.12
TS3: 2.3.11
Annex, page 111
Required
IDE-9.7 PS: 10.3.1 to Valid Pricing Request Message stored in F Prototype No Yes External
PS: 10.3.4 Message. (D) Journal, pricing update Test No Yes External
PS: 10.3.7 to message (message Production No No No
PS: 10.3.11 type 15) is sent to the
PS: 10.3.15 requestor. (C)
TS1: 3.2
TS1: 3.3.1
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.8
TS1: 3.9
TS3: 2.1
TS3: 2.2.1
TS3: 2.2.12
TS3: 2.3.11
Annex, page 112
Table 3.10

IDE-10.0 PS: 10.3.1 to IDE receives a Pricing Update Message. Communication paths specified in parentheses for each test case.
PS: 10.3.7 to
PS: 10.3.11
PS: 10.3.15
TS1: 3.2
TS1: 3.3.1
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.8
TS1: 3.9
TS3: 2.1
TS3: 2.2.1
TS3: 2.2.13
TS3: 2.3.11
Annex, page 113
Required
IDE-10.1 PS: 10.3.1 to Pricing Update Message Message stored in F Prototype No Yes External
PS: 10.3.7 to type parameter. (D) with Receipt code 7 (C) is Production No No No
TS1: 3.2
TS1: 3.3.1
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.8
TS1: 3.9
TS3: 2.1
TS3: 2.2.1
TS3: 2.2.13
TS3: 2.3.11
PS: 10.3.7 to ID parameter. (D) with Receipt code 7 (C) is Production No No No
TS1: 3.2
TS1: 3.3.1
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.8
TS1: 3.9
TS3: 2.1
TS3: 2.2.1
TS3: 2.2.13
TS3: 2.3.11
Annex, page 114
Required
TS1: 3.2
TS1: 3.3.1
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.8
TS1: 3.9
TS3: 2.1
TS3: 2.2.1
TS3: 2.2.13
TS3: 2.3.11
PS: 10.3.4 with an invalid Time stamp Journal, Receipt Message Test No Yes External
TS1: 3.2
TS1: 3.3.1
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.8
TS1: 3.9
TS3: 2.1
TS3: 2.2.1
TS3: 2.2.13
TS3: 2.3.11
Annex, page 115
Required
TS1: 3.2
TS1: 3.3.1
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.8
TS1: 3.9
TS3: 2.1
TS3: 2.2.1
TS3: 2.2.13
TS3: 2.3.11
PS: 10.3.4 with an invalid Effective Journal, Receipt Message Test No Yes External
PS: 10.3.7 to Date parameter. (D) with Receipt code 7 (C) is Production No No No
TS1: 3.2
TS1: 3.3.1
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.8
TS1: 3.9
TS3: 2.1
TS3: 2.2.1
TS3: 2.2.13
TS3: 2.3.11
Annex, page 116
Required
PS: 10.3.4 with an Effective Date that Journal, Receipt Message Test No Yes External
PS: 10.3.7 to is before the current date. with Receipt code 7 (C) is Production No No No
PS: 10.3.11 (D) sent to the originator and
TS1: 3.2
TS1: 3.3.1
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.8
TS1: 3.9
TS3: 2.1
TS3: 2.2.1
TS3: 2.2.13
TS3: 2.3.11
PS: 10.3.4 with an Effective Date that Journal, Receipt Message Test No Yes External
PS: 10.3.7 to is equal to the current with Receipt code 7 (C) is Production No No No
PS: 10.3.11 date. (D) sent to the originator and
TS1: 3.2
TS1: 3.3.1
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.8
TS1: 3.9
TS3: 2.1
TS3: 2.2.1
TS3: 2.2.13
TS3: 2.3.11
Annex, page 117
Required
PS: 10.3.4 with an invalid Pricing File Journal, Receipt Message Test No Yes External
TS1: 3.2
TS1: 3.3.1
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.8
TS1: 3.9
TS3: 2.1
TS3: 2.2.1
TS3: 2.2.13
TS3: 2.3.11
TS1: 3.2
TS1: 3.3.1
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.8
TS1: 3.9
TS3: 2.1
TS3: 2.2.1
TS3: 2.2.13
TS3: 2.3.11
Annex, page 118
Required
IDE-10.11 PS: 10.3.1 to Valid Pricing Update Message stored in F Prototype No Yes External
PS: 10.3.4 Message. (D) Journal, pricing file is Test No Yes External
PS: 10.3.7 to processed and Pricing Production No No No
PS: 10.3.11 Notification message is
PS: 10.3.15 broadcast. (G)
TS1: 3.2
TS1: 3.3.1
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.8
TS1: 3.9
TS3: 2.1
TS3: 2.2.1
TS3: 2.2.13
TS3: 2.3.11
Annex, page 119
Appendix 3-A
INTERNATIONAL LRIT DATA EXCHANGE TEST PROCEDURES AND CASES
Test Procedures and cases for the first Modification testing
Table 3-A.1
Test procedure IDE-11.0

IDE-11.0 PS: 10.3.1 to IDE receives a Receipt Message from DC1. Communication paths specified in parentheses for each test case.
PS: 10.3.8 to
PS: 10.3.11
PS: 12.1
TS1: 2.1.1
TS1: 3.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.4
TS3: 2.2.5
Annex, page 120
Required
Test Required
type during
entering
IDE-11.1 PS: 10.3.1 to Receipt Message received Message stored in F Prototype N/A N/A N/A
PS: 10.3.4 with all valid message Journal, IDE routes Test No Yes Internal
PS: 10.3.8 to parameters addressed to message to the Production No No N/A
PS: 10.3.11 a Data Centre. (D) appropriate DC. (F)
PS: 12.1
TS1: 2.1.1
TS1: 3.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.4
TS3: 2.2.5
IDE-11.2 PS: 10.3.1 to SAR SURPIC Receipt Message stored in F Prototype N/A N/A N/A
PS: 10.3.4 message received Journal, IDE routes Test No Yes Internal
PS: 10.3.8 to (Message type 7 with message to the Production No No N/A
PS: 10.3.11 ReceiptCode = 1, 'no ship appropriate DC. (F)
PS: 12.1 in SAR SURPIC area')
TS1: 2.1.1 with invalid DDP version
TS1: 3.2 number parameter (D)
TS1: 3.3.2.3
TS1: 3.3.3
TS1: 3.3.4
TS3: 2.2.5
Annex, page 121
Table 3-A.2
Test procedure IDE-12.0

IDE-12.0 PS: 10.3.1 to IDE receives a Pricing Request message. Communication paths specified in parentheses for each test case.
PS: 10.3.8 to
PS: 10.3.11
PS: 10.3.15
TS1: 2.1.1
TS1: 3.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.8
TS1: 3.9
TS3: 2.1
TS3: 2.2.1
TS3: 2.2.12
TS3: 2.3.11
Annex, page 122
Test case IDE-12.1
Required
Test Required
type during
entering
IDE-12.1 PS: 10.3.1 to Valid Pricing Request Message stored in F Prototype N/A N/A N/A
PS: 10.3.4 Message. (D) Journal, pricing update Test No Yes Internal
PS: 10.3.8 to message (message Production No Yes N/A
PS: 10.3.11 type 15) is sent to the
PS: 10.3.15 requestor. (C)
TS1: 2.1.1
TS1: 3.2
TS1: 3.3.2
TS1: 3.3.3
TS1: 3.3.8
TS1: 3.9
TS3: 2.1
TS3: 2.2.1
TS3: 2.2.12
TS3: 2.2.13
TS3: 2.3.11
Annex, page 123
Appendix 4
LRIT Data Distribution Plan server test procedure and cases
Table 4.1
Test procedure DDP-1.0

DDP-1.0 PS: 11.3 DDP server sends a DDP Notification Message in response to input from Contracting Governments. Communication paths specified
TS3: 2.2.6 in parentheses for each test case. All parameters associated with each message should be valid unless specified otherwise in a
TS4: 6.6.3 given test case.
Annex, page 124
Test cases DDP-1.1 to DDP-1.4
Required
DDP-1.1 PS: 11.3 DDP server sends a DDP Verify that the DDP server F Prototype No Yes External
TS3: 2.2.6 Notification Message with sends a DDP Notification Test N/A N/A N/A
TS4: 6.6.3 all valid Message Message with an immediate Production N/A N/A N/A
parameters in response to update type within the
submission of any specified time period. (A)
immediate DDP information
via the DDP web interface
by a Contracting
Government, within 3 min of
the submission. (A)
DDP-1.2 PS: 11.3 DDP server sends a DDP Verify that the DDP server F Prototype No Yes External
TS3: 2.2.6 Notification Message with sends a DDP Notification Test N/A N/A N/A
TS4: 6.6.3 all valid Message Message at the following Production N/A N/A N/A
parameters in response to 00:00 UTC with a regular
submission of any regular update type. (A)
DDP information within
3 min of the submission
from a Contracting
Government, at 00:00 UTC
following the day of
submission. (A)
Annex, page 125
Required
DDP-1.3 PS: 11.3 Upon performing test Verify that the DDP XML F Prototype No Yes External
TS3: 2.2.7 DDP-1.1, the DDP server contained with the Test N/A N/A N/A
TS3: 2.2.8 receives a DDPRequest DDPUpdate message Production N/A N/A N/A
TS4: 6.6 message and sends a corresponds to the change
and 6.7 DDPUpdate in response. made to the specific
TS4: 3.8 to immediate DDP information
3.15 via the web interface.
Also verify that the

published and
implementation times
specified within the
DDPUpdate message are
correct.
DDP-1.4 PS: 11.3 Upon performing test Verify that the DDP XML F Prototype No Yes External
TS3: 2.2.7 DDP-1.2, the DDP server contained with the Test N/A N/A N/A
TS3: 2.2.8 receives a DDPRequest DDPUpdate message Production N/A N/A N/A
TS4: 6.6 message and sends a corresponds to the
and 6.7 DDPUpdate in response. change(s) to regular DDP
TS4: 3.8 to information made via the
3.15 web interface.
Also verify that the

published and
implementation times
specified within the
DDPUpdate message are
correct.
Annex, page 126
Table 4.2

DDP-2.0 PS: 11.3 DDP server receives a DDP Request Message from a DC or the IDE. Communication paths specified in parentheses for each test
TS4: 6.6
and 6.7
Required
DDP-2.1 PS: 11.3 DDP server receives a DDP DDP server sends a receipt F Prototype No Yes External
TS3: 2.2.7 Request Message with Message with code 7 to the Test N/A N/A N/A
TS3: 2.2.5 Update Type other than 4, originator. (A, J) Production N/A N/A N/A
TS4: 3.6 and either the "Archived
and 3.7 DDP Version Number" or
TS4: 6.6 "Archived DDP Timestamp"
parameters or both, are
specified. (B, I)
TS3: 2.2.5 Update Type 4, and the originator. (A, J) Production N/A N/A N/A
TS4: 3.6 "Archived DDP Version
and 3.7 Number" parameter has an
TS4: 6.6 invalid value. (B, I)
Annex, page 127
Required
TS3: 2.2.5 Update Type 4, and the originator. (A, J) Production N/A N/A N/A
TS4: 3.6 "Archived DDP Time stamp"
and 3.7 parameter has a value that
TS4: 6.6 is not in the past. (B, I)
DDP-2.4 PS: 11.3 DDP server receives a DDP DDP server sends a DDP F Prototype No Yes External
TS3: 2.2.7 Request Message with Update Message with an Test N/A N/A N/A
TS3: 2.2.8 update type 0 and all valid Incremental Update Production N/A N/A N/A
TS4: 3.8 to parameters. (B, I) containing all changes to
3.20 regular DDP information
TS4: 6.6 between the version
and 6.7 implemented by the
originator and the most
recently published version
of the DDP as at the time of
request. (A, J)
3.20 immediate DDP information
TS4: 6.6 between the version
and 6.7 implemented by the
originator and the most
request. (A, J)
Annex, page 128
Required
3.20 the DDP between the
TS4: 6.6 version implemented by the
and 6.7 originator and the most
request. (A, J)
TS3: 2.2.7 Request Message with Update Message with the Test N/A N/A N/A
TS3: 2.2.8 update type 3 and all valid version of the Full DDP Production N/A N/A N/A
TS4: 3.6 parameters. (B, I) implemented within the
and 3.7 LRIT system at the time of
the request P. (A, J)
TS3: 2.2.8 update type 4 and all valid requested version of the Production N/A N/A N/A
TS4: 3.6 parameters, with the Full DDP. (A, J)
and 3.7 archived DDP version
TS4: 6.6 number parameter
specified. (B, I)
TS3: 2.2.8 update type 4 and all valid archived version of the Full Production N/A N/A N/A
TS4: 3.6 parameters, with the DDP implemented within
and 3.7 archived DDP Time stamp the LRIT system at the
TS4: 6.6 parameter specified. (B, I) specified time. (A, J)
Annex, page 129
Table 4.3

DDP-3.0 PS: 11.3 DDP server receives a System Status Message (Message Type 11) from the IDE. Communication paths specified in parentheses for
TS4: 6.6
Required
DDP-3.1 PS: 11.3 DDP server receives Verify reception of message F Prototype No Yes Internal
TS3: 2.2.9 System Status Message and no further action Test N/A N/A N/A
TS4: 6.6 from IDE with all valid required by DDP server. Production N/A N/A N/A
Message parameters. (B)
DDP-3.2 PS: 11.3 Message validation with A SOAP Fault or Receipt C Prototype No Yes External
TS3: 2.2.9 invalid Message parameter. Message with Receipt Test N/A N/A N/A
TS4: 6.6 (B) code 7 is sent with message Production N/A N/A N/A
rejection. (A)
Annex, page 130
Table 4.4

DDP-4.0 PS: 11.3 DDP server sends a System Status Message (Message Type 11) to the IDE. Communication paths specified in parentheses for
TS4: 6.6
Test cases DDP-4.1
Required
DDP-4.1 PS: 11.3 Check if DDP server sends Verify transmission of F Prototype No Yes External
TS3: 2.2.9 System Status Message message. Test N/A N/A N/A
TS4: 6.6 every 30 min to IDE with all Production N/A N/A N/A
valid Message parameters.
(A)
Annex, page 131
Table 4.5

DDP-5.0 PS: 11.3 DDP server receives a Receipt (Message Type 7) sent by a DC or the IDE. Communication paths specified in parentheses for each
TS3: 2.2.5 test case. All parameters associated with each message should be valid unless specified otherwise in a given test case.
TS4: 6.6
Required
DDP-5.1 PS: 11.3 DDP server receives Verify reception of message F Prototype No Yes Internal
TS3: 2.2.5 Receipt Message from IDE and no further action Test N/A N/A N/A
TS4: 6.6 or DC with all valid Message required by DDP server. Production N/A N/A N/A
parameters. (I, B)
DDP-5.2 PS: 11.3 Message validation with A SOAP Fault or Receipt C Prototype No Yes External
TS3: 2.2.5 invalid Message parameter. Message with Receipt Test N/A N/A N/A
TS4: 6.6 (I, B) code 7 is sent with message Production N/A N/A N/A
rejection. (J, A)
Annex, page 132
Appendix 5
MODEL OF A SUMMARY REPORT

(to be used by LRIT Data Centres when reporting test results after testing in the
prototype, testing and production environments)
Guidance Notes:
The following notes and instructions should be observed and adhered to as otherwise this may
lead to delays in considering the test results being reported:
(1.1) An electronic version of the Summary report may be obtained from the Secretariat upon
request.
(1.2) All entries other than signatures should be done electronically in word format. The part
containing the signature should be scanned after it has been signed and send to the
Secretariat together with the electronically completed Summary report.
(1.3) All dates in should be numeric in the format DD/MM/YY.
(1.4) All times should be UTC in the format HH:MM.
(2) Part I should be completed by the LRIT Data Centre which has completed the testing
process. It should be sent to the Secretariat together with the completed test
procedures and tests cases using appendix 2. An electronic version of appendix 2 in
word format may be obtained from the Secretariat upon request.
Section 3 should indicate the first and last date and time of testing
Section 4 should indicate the first and last date and time of testing with the LRIT Data
Centres assisting the testing, the International LRIT Data Exchange and the LRIT Data
Distribution Plan server so as to enable these to easily trace the test results and related
records at their end with a view to providing the external certification of the test results
requested of them.
(3.1) Part II should be completed by the first LRIT Data Centre assisting the testing process
(the 1st-ast-DC) and should be sent to the Secretariat. The Record of externally
certified test results should be completed first before completing and signing the
External certification of test results. Before completing this part please read notes (3.2)
and (7.1) to (7.4) below.
(3.2) Before completing the column headed Results in Table A in Part II in relation to test
case DC-2.1, Tables B and C in Part II should be completed first. The entry should be
Yes only if:
(a) all the tests for Message type 4 for the combinations of access type and
request type specified in Tables B; and
(b) all the tests for Message type 5 for the combinations of access type and
request type specified in Tables C,
have been conducted and what is specified in Tables 2.2.1 and 2.2.2 in appendix 2
under the column headed as Expected results against the corresponding combinations
have been achieved or happened.
Annex, page 133
Otherwise the entry should be No and related explanations should be provided using
Part VI with cross reference under comments to the combinations of access type and
request type the issue relates to.
(4) Part III should be completed by the second LRIT Data Centre assisting the testing
process (the 2nd-ast-DC), as far as test case DC-2.2, and should be sent to the
Secretariat. The Record of externally certified test results should be completed first
before completing and signing the External certification of test results. Before
completing this part please read notes (7.1) to (7.4) below.
(5) Part IV should be completed by the United States as provider of the International LRIT
Data Exchange (the IDE) on an interim basis and should be sent to the Secretariat.
The Record of externally certified test results should be completed first before
completing and signing the External certification of test results. Before completing this
part please read notes (7.1) to (7.4) below.
(6) Part V should be completed by the Secretariat as provider of the LRIT Data Distribution
Plan server (the DDP server). The Record of externally certified test results should be
completed first before completing and signing the External certification of test results.
Before completing this part please read notes (7.1) to (7.4) below.
(7.1) The Record of externally certified test results provided in Parts II to V should be
completed by the 1st-ass-DC, the 2nd-ass-DC, the United States and the Secretariat,
respectively, in support of the External certification of test results to be provided by
completing and signing Parts II to V.
(7.2) The entries to be made under column headed Results in the tables provided in Parts II
to V, under the heading Record of externally certified test results, should be either Yes
or No.
(7.3) Subject to note 3.2, entering Yes under column headed Results in the tables provided
in Parts II to V means that the related test case has been conducted and what is
specified in appendix 2 under the column headed as Expected results against the test
case has been achieved or happened.
(7.4) In case the entry under column headed Results in the tables provided in Parts II to V is
a No, Part VI (see note (8) below) should be completed in order to provide related
explanations citing the test case the issue relates to.
(8) Part VI should be used when test results can not be confirmed (i.e. any of the entries
any one of tables provided in Parts II to V is No) or when there is a need to provide
comments in relation to any of the test results or the confirmation provided by
completing the Parts II to V.
The user of this part should indicate Yes under the appropriate column in section 1 and
the rest of the columns should be left empty.
In section 2 further comment boxes may be added as necessary.
Annex, page 134
SUMMARY REPORT
Part I Statement of completion of testing and certification of test results

(to be completed by the LRIT Data Centre tested)
Environment Prototype/Testing/Production1
1 Details of the LRIT Data Centre (DC) tested
Contracting Government2
Type of LRIT Data Centre National/Regional/Cooperative3
Providing services also to4
LRIT ID (of DC)5
2 Dates and times (UTC) between which the testing was conducted
Started on Ended on
3 LRIT Data Centres (1st-ast-DC and 2nd-ast-DC (for test case DC-2.2 only)) which
assisted the testing
1st-ast-DC6
2nd-ast-DC7 (for test case DC-2.2
only)
4 Dates and times (UTC) between which the testing was conducted with the 1st-ast-DC,
the 2nd-ast-DC, the IDE and the DDP server
Testing
with 1st-ast-DC 2nd-ast-DC IDE DDP server
Started on
Ended on
1
Delete as appropriate.
2
In the space provided enter the name of the Contracting Government(s) establishing the LRIT Data Centre.
3
4
In the space provided enter the name(s) of the Contracting Government(s) (other than the Contracting
Government(s) establishing the LRIT Data Centre tested) to which the LRIT Data Centre is providing services.
5
In the space provided enter the LRIT ID used by DC during the testing.
6
In the space provided enter the name(s) of the Contracting Government(s) establishing the LRIT Data Centre.
7
In the space provided enter the name(s) of the Contracting Government(s) establishing the LRIT Data Centre.
Annex, page 135
5 Completion of testing and certification of test results (to be completed and signed by
the person and in charge of the operation of the LRIT Data Centre tested)
I hereby certify that all tests specified in appendix 2 of the Protocols have been conducted and
the results of the tests are those specified in appendix 2 of the Protocols under the column
headed Expected results against each of the test procedures and test cases. I also declare that
I am duly authorized to certify the conduct of the aforesaid tests and their results.
(Signature of the person) Date

Name, title and contact details (telephone and facsimile numbers and e-mail address) of the
person who signed above
Annex, page 136
Part II Confirmation of test results as far as this involved 1st-ast-DC

(To be completed and signed by the person in charge of the operation of 1st-ast-DC)
Record of externally certified test results
Table A
(In relation to test case DC-2.1, follow the instructions provided under note (8)
before entering Yes or No under the column headed Results)
Required in the
Prototype Test Production Test Results
Environment Environment Environment case (Yes/No)
Yes Yes No DC-2.1
Yes Yes No DC-2.2
Yes Yes No DC-2.4
Yes Yes No DC-2.5
Yes Yes No DC-2.6
Yes Yes No DC-2.7
Yes Yes No DC-2.8
Yes Yes No DC-2.9
Yes Yes No DC-3.1
Yes Yes No DC-3.2
Yes Yes No DC-15.1
Yes Yes No DC-15.2
Yes Yes No DC-15.3
Yes Yes No DC-16.1
Yes Yes No DC-16.2
Table B
Test case DC-2.1

(Message Type 4)
Combinations of access type and request type specified in Table 2.2.1
Required in the
Prototype Test Production Access Request Results
Environment Environment Environment Type Type (Yes/No)
Yes Yes No 0 1
Yes Yes No 0 2
Yes Yes No 0 3
Yes Yes No 0 4
Yes Yes No 0 5
Annex, page 137
Required in the
Yes Yes No 0 6
Yes Yes No 0 7
Yes Yes No 0 8
Yes Yes No 0 9
Yes Yes No 0 10
Yes Yes No 0 11
Yes Yes No 1 0
Yes Yes No 1 1
Yes Yes No 1 2
Yes Yes No 1 3
Yes Yes No 1 4
Yes Yes No 1 7
Yes Yes No 1 8
Yes Yes No 1 9
Yes Yes No 2 0
Yes Yes No 2 1
Yes Yes No 2 2
Yes Yes No 2 3
Yes Yes No 2 4
Yes Yes No 2 5
Yes Yes No 2 6
Yes Yes No 2 8
Yes Yes No 2 9
Yes Yes No 2 10
Yes Yes No 2 11
Yes Yes No 3 0
Yes Yes No 3 1
Yes Yes No 3 2
Yes Yes No 3 3
Yes Yes No 3 4
Yes Yes No 3 7
Yes Yes No 3 8
Yes Yes No 3 9
Yes Yes No 5 0
Yes Yes No 5 1
Yes Yes No 5 2
Annex, page 138
Required in the
Yes Yes No 5 3
Yes Yes No 5 4
Yes Yes No 5 7
Yes Yes No 5 8
Yes Yes No 5 9
Table C
Test case DC-2.1

(Message Type 5)
Combinations of access type and request type specified in Table 2.2.2
Required in the
Yes Yes No 6 1
Yes Yes No 6 9
External certification of test results
I hereby certify that [, subject to the information provided in Part VI,8] the information provided in
the above record are true and correct as far as the involvement of the 1st-ast-DC in the testing of
the LRIT Data Centre specified in Part I is concerned and I declare that I am duly authorized to
certify the conduct of the aforesaid tests and the related results.

8
To be included if necessary (refer to note (8)).
Annex, page 139
Part III Confirmation of test results as far as this involved 2nd-ast-DC

(To be completed and signed by the person in charge of the operation of 2nd-ast-DC)
Required in the
Yes Yes No DC-2.2
the above record are true and correct as far as the involvement of the 2nd-ast-DC in the testing
of the LRIT Data Centre specified in Part I is concerned and I declare that I am duly authorized
to certify the conduct of the aforesaid tests and the related results.

9
Annex, page 140
Part IV Confirmation of test results as far as this involved the IDE

(To be completed and signed on behalf of the United States)
Required in the
Yes Yes Yes DC-1.1
Yes Yes Yes DC-6.1
Yes Yes No DC-7.1
Yes Yes Yes DC-8.1
Yes Yes Yes DC-9.1
Yes Yes No DC-10.1
Yes Yes No DC-13.1
Yes Yes No DC-13.2
Yes Yes No DC-13.3
Yes Yes No R/CDC-14.1*
*
if applicable
the above record are true and correct as far as the involvement of the IDE in the testing of the
LRIT Data Centre specified in Part I is concerned and I declare that I am duly authorized to
certify the conduct of the aforesaid tests and the related results.

10
Annex, page 141
Part V Confirmation of test results as far as this involved the DDP server
(To be completed and signed by the Secretariat)
Required in the
Yes Yes No DC-11.1
Yes Yes No DC-11.2
Yes Yes Yes DC-12.1
the above record are true and correct as far as the involvement of the DDP server in the testing
of the LRIT Data Centre specified in Part I is concerned and I declare that I am duly authorized
to certify the conduct of the aforesaid tests and the related results.

11
Annex, page 142
Part VI Comments in relation to the external certification of test result

(for use, when necessary, by the 1st-ast-DC, the 2nd-ast-DC, the IDE and the DDP server as
outlined in note (8))
1 The following comments are submitted by:
1st-ast-DC 2nd-ast-DC IDE DDP server
2 The external certification provided in Part II/III/IV/V12 is subject to the following

comments:
Test case:
Comment(s):
Test case:
Comment(s):
Test case:
Comment(s):
12
Annex, page 143
Appendix 6
EXPLANATORY NOTES AND GUIDANCE

ON THE CONDUCT OF TESTING OF LRIT DATA CENTRES
1 The intent of this document is to provide explanatory notes and guidance on the
conduct testing of LRIT Data Centres in relation to the test cases stipulated in the Protocols
when a:
.1 National (NDC) LRIT Data Centres:
.1 is to undergo testing for first time and is contemplating to start

providing services to Contracting Government(s) other than that it is
establishing the centre;
.2 operating in production environment, is contemplating to start

providing services to Contracting Government(s) other than that
established the centre;
.3 operating in production environment, is contemplating to become a

RDC or a CDC; or
.4 operating in production environment and already providing services

to other Contracting Government(s), is contemplating to provide
services to Contracting Government(s) which was/were not included
in previous testing;
.2 Regional (RDC) or Cooperative (CDC) LRIT Data Centres:
.1 is to undergo testing for first time; or
.2 operating in production environment, is contemplating to provide

services to other Contracting Government(s) which was/were not
included in previous testing.
2 The explanatory notes and guidance set out in this document should always be read
together with the Protocols. Every reference to the Protocols constitutes at the same time a
reference to the explanatory notes and guidance set out in this document.
3 The explanatory notes and guidance set out in this document should be observed and
adhered to when conducting the test procedures and test cases specified in appendix 2 to the
annex of the Protocols as specified in the table set out below. The test cases referred to in the
aforesaid table are those specified in appendix 2 to the annex of the Protocols.
4 In the instances referred to in paragraph 1, when recording the results of a specific test
as specified in appendix 2 of the annex to the Protocols against a test case specified in the table
set out below, it is implied that the specific test case has been conducted subject to the
provisions of the explanatory notes and guidance set out in this document.
5 In the instances referred to in paragraph 1, when completing any one of the parts of the
Summary report provided in appendix 5 of the annex to the Protocols, it is implied that the test
cases specified in the table set out below have been conducted subject to the provisions of the
explanatory notes and guidance set out in this document.
Annex, page 144
6 When an NDC is contemplating to start providing services to Contracting

Government(s) other than that it is establishing the centre and an RDC or CDC before
commencement of any testing should ascertain that the polygons of the geographical areas
included by each of the Contracting Governments concerned in the testing and production
environments of the LRIT Data Distribution Plan fully complied with the constraints set out in
section 5 of the Technical specification for the LRIT Data Distribution Plan.
7 An NDC contemplating to start providing services to Contracting Government(s) other

than that it is establishing the centre and an RDC or CDC does not have to undergo all of the
test procedures and cases set out in the Protocols for each and every one of the Contracting
Government(s) associated with the LRIT Data Centre (DC) (i.e. establishing, or using the
services of, the DC), provided:
.1 test cases DC-1.1, DC-1.4 and DC-4.1 are carried out and satisfactorily
completed for all Contracting Governments associated with the DC (i.e. in
order to check the functionality of receiving a valid position report from the
IDE; ascertain that LRIT Data User (LDU) address is registered with the DC;
and verify that the DC can receive a valid receipt message from the IDE for
each LDU);
.2 test cases DC-2.1 and DC-15.1 are carried out and satisfactorily completed for
at least two Contracting Governments (which should preferably be the ones
presenting the more complexities in the testing process);
.3 additional further tests are carried out so as to test all possible foreseeable
operational scenarios taking into account the particularities associated with the
Contracting Government(s) which would be served by the DC; and
.4 a detailed test plan is submitted to the Organization before the

commencement of any tests. The Organization should in turn provide the
aforesaid information and a copy of the proposed test plan to the IDE, the DCs
which would be identified to assist its testing and to the LRIT Coordinator.
8 Table "Explanatory notes and guidance" provides the necessary guidance and
additional expected results in relation to the test cases stipulated in the Protocols for the testing
environment only.
9 A template with the necessary guidance to create the "Testing Plan" provided in
item 7.4 is given at final of this appendix.
Annex, page 145
Table
Explanatory notes and guidance
The explanatory notes and guidance applies

NDC2 already providing
services to other
Contracting
NDC is contemplating to Government(s),
start providing services NDC1 is contemplating and a RDC and CDC3,
to other Contracting either to start providing are contemplating to
Government(s) services to other provide services to a
and Contracting new4 Contracting
RDC or CDC is to Government(s) Government(s) which
Guidance undergo testing for the or to become an RDC or a was/were not included in
Expect results first time CDC previous testing
(in addition to those specified in appendix 2 of (Paragraphs 1.1.1 and (Paragraphs 1.1.2 and (Paragraphs 1.1.4 and
Test case the annex to the Protocols) 1.2.1) 1.1.3) 1.2.2)
DC-1.1 The specified test should be conducted for each Yes Yes Yes
DC-1.4 Contracting Government establishing or using (only as far as the new (only as far as the new
the services of the DC if is entitled to receive the Contracting Government(s) Contracting Government(s)
LRIT information. is/are concerned) is/are concerned)
The position report is only received by the

intended recipient.
1
Refers to an NDC operating in the production environment of the LRIT system.
2
Refers to an NDC operating in the production environment of the LRIT system.
3
Refers to an RDC or CDC operating in the production environment of the LRIT system.
4
The term new Contracting Government(s) in this column refers to Contracting Government(s) which was or were not included in the testing when the centre in question undergone
prototype testing or developmental and integration testing.
Annex, page 146

services to other
Contracting
DC-1.2 The specified test should be conducted once Yes No No
DC-1.3 using different LRIT Data Users.
DC-1.5
DC-1.6
DC-2.2 No additional expected results.
DC-2.3
DC-2.5 to DC-2.9
DC-3.3
DC-4.2
DC-5.1 and DC-5.2
DC-6.1
DC-7.1
DC-8.1
DC-9.1 and DC-9.2
DC-11.1 to DC-11.3
DC-12.1
DC-13.1 to DC-13.4
DC-15.2 to DC-16.2
Annex, page 147

services to other
Contracting
DC-2.1 The tests specified in tables 2.2.1 and 2.2.2 Yes Yes No
should be conducted twice using two ships (to be conducted only
chosen from two different Contracting once)
Governments.
No additional expected results.

DC-2.4 The specified test should be conducted once Yes Yes No
selecting one of the LRIT Data Users.
The test should be repeated using a test
scenario where the request message contains a
request for a ship that is registered to the DC but
not associated with the LRIT ID of the
Contracting Government specified in the Data
User Provider parameter.
Annex, page 148

services to other
Contracting
DC-3.1 The SAR SURPIC area should contain at least Yes Yes Yes
DC-3.2 one ship position from each Contracting (only as far as the new (only as far as the new
Government establishing or using the services of Contracting Government(s) Contracting Government(s)
the DC. is/are concerned) is/are concerned)

DC-4.1 The specified test should be conducted for each Yes Yes Yes
Contracting Government establishing or using (only as far as the new (only as far as the new
the services of the DC. Contracting Government(s) Contracting Government(s)
is/are concerned) is/are concerned)

DC-10.1 The specified test should be conducted once. Yes Yes Yes
The pricing file should include the list of prices of
all Contracting Governments establishing or
using the services of the DC.
Annex, page 149

services to other
Contracting
R/CDC-14.1 The specified test should be conducted if the Yes Yes No
R/CDC is routing internally LRIT messages.
The journal file should contain a minimum of ten
(10) LRIT messages.

DC-15.1 The specified test should be conducted twice Yes Yes No
using two ships chosen from (to be conducted only
two different Contracting Governments once)
establishing or using the services of
the DC.
Annex, page 150
DEVELOPMENTAL TESTING PHASE
TESTING PLAN
Environment Testing
1 Details of the LRIT Data Centre (DC) to be tested or tested
Contracting Government1
Type of LRIT Data Centre National/Regional/Cooperative2
Providing services also to3
Contracting Governments
covered by the testing4
LRIT ID (of DC)5
2 Details of the Contracting Governments to be used/used6 for each test required
Dates7 and times8(UTC)

between
which the testing was
conducted
(the columns below to be
completed during testing)
Name of the Contracting
Test case Government(s) to be used or used for Started on Ended on
the specific test
DC-1.1 [enter the name and LRIT ID of each of the
Contracting Governments establishing or
using the centre to be used for or used for
the test]
the test]
DC-1.2 [enter the name and LRIT ID of one of the
Contracting Governments to be used or
used for the test]
1
In the space provided enter the name of the Contracting Government(s) establishing the LRIT Data Centre.
2
3
In the space provided enter the name(s) of the Contracting Government(s) (other than the Contracting
Government(s) establishing the LRIT Data Centre tested) to which the LRIT Data Centre is providing services.
4
In the space provided enter the name(s) of the Contracting Government(s) for which the LRIT Data Centre is or
has been tested.
5
In the space provided enter the LRIT ID used by LRIT Data Centre during the testing.
6
7
All dates should be numeric in the format DD/MM/YY.
8
All times should be UTC in the format HH:MM.
Annex, page 151

between
conducted
the specific test
used for the test]
used for the test]
used for the test]
DC-2.1 [enter the name and LRIT ID of two
Contracting Governments, including into
brackets the IMO ship identification number
of the selected ship for each one of the
Contracting Governments, to be used or
used for the tests specified in Table 2.2.1
and 2.2.2 of the Protocols]
used for the test]
used for the test]
DC-2.4 [enter the name and LRIT ID of the
Contracting Government, including into
brackets the IMO Ship identification
number of a ship that is not associated with
the LRIT Data Centre, to be used or used
for the first test]
[enter the name and LRIT ID of the
Contracting Government, including into
brackets the IMO Ship identification
number of a ship that is associated with
other Contracting Government establishing
or using the services of the LRIT Data
Centre, to be used or used for the second
test]
used for the test]
used for the test]
used for the test]
Annex, page 152

between
conducted
the specific test
used for the test]
used for the test]
the test]
the test]
the test]
used for the test]
the test]
R/CDC-14.1 No additional details are required
DC-15.1 [enter the name and LRIT ID of two
Contracting Governments, including into
brackets the IMO ship identification number
of the selected ship for each one of the
Contracting Governments, to be used or
used for the test]
used for the test]
used for the test]
used for the test]
used for the test]
Annex, page 153
3 Comments9 in relation to the test cases specified in section 2 (for use, when necessary,
to provide additional details of the test or when a Contracting Government was not
considered for a specific test) (please include additional rows as necessary)
Test Name and LRIT ID of the Comment(s)

case Contracting Government(s)
4 Details of the person who submitting the plan/confirming that the above tests have been
carried out10
(Signature11 of the person) Date12

9
Further comment boxes may be added as necessary.
10
11
The part containing the signature should be scanned after it has been signed and sent to the Secretariat
together with the electronically completed report.
12
All dates should be numeric in the format DD/MM/YY.
Annex, page 154
ANNEX 2
PROCEDURES FOR THE

NOTIFICATION, REPORTING AND RECORDING OF
TEMPORARY SUSPENSIONS OF OPERATIONS OF,
OR REDUCTION OF THE SERVICE PROVIDED BY,
COMPONENTS OF THE LRIT SYSTEM
1 Introduction
1.1 Whilst the LRIT Data Centres (DCs), the International LRIT Data Exchange (IDE) and
the LRIT Data Distribution Plan server (DDP server) have been designed to ensure that
Contracting Governments and Search and rescue services are provided in a timely manner the
LRIT information they are entitled to receive upon request or as a result of standing orders, as
the case may be, it is recognized that from time to time they may need to temporarily suspend
their operations or to reduce the level of service provided in order to carry out, inter alia,
scheduled or unscheduled maintenance or upgrade of hardware or software in use or to manage
or control unforeseen events such as malicious network attacks or deal with external reasons
such as unavailability of, or access to, telecommunication networks or to the internet or to
conduct emergency or urgent repairs or maintenance which can not be differed to a later time.
1.2 The purpose of the present procedures is to set out the processes to be followed by
DCs, the IDE and the DDP server when providing salient information to the other components of
the LRIT system and the LRIT Coordinator in cases where they have to temporarily suspend
operations or to reduce the level of service in cases of scheduled or planned activities and
unforeseen events. In addition, the present procedures set out the records to be kept in such
circumstances and their availability.
1.3 The communication of information should be done by e-mail using the designated
points of contact provided in the LRIT Data Distribution Plan (DDP).
2 Scheduled or planned activities requiring temporary suspension of operations or

reduction of the level of service
2.1 The DC concerned, the IDE and the DDP server, as the case may be, should advise the
other components of the LRIT system and the LRIT Coordinator no later than five (5) days prior
to the temporary suspension of operations or reduction of the level of service on the impending
situation.
2.1.1 The advice should provide information on the planned or scheduled activities to be
conducted; indicate the dates and times between which the activities would take place; supply
information on the consequences of the activities for example the IDE would not be available to
provide services or the DDP server would be operating at a reduce rate; and advise, if possible,
any measures or arrangements which the other components of the LRIT system may need to
have to put in place in order to ensure the speedy and efficient resumption of normal operations
or to manage any adverse effects.
2.2 The DC concerned, the IDE and the DDP server should publish an advisory notice to be
posted in the case of:
.1 the IDE and the DDP server on the IDE Administrative web interface and the
DDP, respectively;
Annex, page 155
.2 a DC on its web interfaces, if such an interface exists and is accessible by the

other components of the LRIT system and the LRIT Coordinator or if the DC
concerned does not have such interface it should consult with the IDE and or
the DDP server with a view to posting the report on the IDE Administrative
web interface and/or the DDP,
providing the information specified in paragraphs 2.1 and 2.1.1 and should update the notice as
and when changes occur.
2.3 The DC concerned, the IDE and the DDP server, as the case may be, should remind
the other components of the LRIT system and the LRIT Coordinator of the impending activities
no later than 24 hours prior to the temporary suspension of operations or reduction of the level of
service on the impending situation.
2.3.1 The reminder should indicate any changes in the dates and times between which the
activities would take place and update the previously provided information in case any changes
have occurred in the meantime.
2.3.2 The advisory notices referred to in paragraph 2.2 should be updated accordingly.
2.4 When the DC concerned or the IDE or the DDP server resumes normal operation, it
should advise to this end the other components of the LRIT system and the LRIT Coordinator,
indicate the date and time as from which it has resumed normal system operational status.
2.4.1 The advisory notices referred to paragraph 2.2 should be removed.
2.5 The DC concerned, the IDE and the DDP server, as the case may be, should assist and
cooperate with the other components of the LRIT system with a view to enabling them to resume
or continue normal operations in case they encounter any difficulties which arise as a result of
the activities which it has conducted.
3 Unforeseen events requiring temporary suspension of operations or reduction of

the level of service
3.1 In case of any unforeseen events the first priorities of the DC concerned, the IDE or the
DDP server should be to bring the situation which affected its operation under control and to
implement measures which would enable it to resume or restore its normal operation and/or to
prevent the issues from spreading in the LRIT system and affecting the operation of other
components of the system.
3.2 As soon as the prevailing circumstances allow so, the DC concerned, the IDE and the
DDP server, as the case may be, should advise the other components of the LRIT system and
the LRIT Coordinator of the situation which has been, or is being, encountered and indicate
whether it would continue any temporary suspension of operations or reduction of the level of
service or whether it would temporarily suspend its operations or reduce the level of service.
3.2.1 As and when developments allow so, the DC concerned, the IDE and the DDP server,
as the case may be, should provide the other components of the LRIT system and the LRIT
Coordinator with updated the information.
3.2.2 In case the DC concerned, the IDE and the DDP server, as the case may be, identifies
that the unforeseen events it has encountered or continuous to encounter may affect the
operation of any of the other components of the LRIT system, should provide to the rest of the
components of the LRIT system and the LRIT Coordinator with salient information and advise
Annex, page 156
the measures or actions which has taken in order control or manage the situation and/or to
resume or restore its normal operation, if such information may be of benefit to the rest of the
components of the LRIT system.
3.3 If the circumstances allow so and subject to the duration of the period during which the
DC concerned, the IDE or the DDP server would need to continue any temporary suspension of
operations or reduction of the level of service or to temporarily suspend its operations or reduce
the level of service in order to address the situation which has been, or is being, encountered,
the DC concerned, the IDE and the DDP server should publish an advisory notice to be posted
in the case of:
DDP, respectively; and
.2 the DC concerned on its web interfaces, if such an interface existing and is

accessible by the other components of the LRIT system and the LRIT
Coordinator or if the DC concerned does not have such interface it should
consult with the IDE and or the DDP server with a view to posting such
advisory notice on the IDE Administrative web interface and/or the DDP,
providing the relevant information and should update such notices as and when developments
occur.
3.4 When the DC concerned or the IDE or the DDP server resumes or restores normal
operation, it should advise to this end the other components of the LRIT system and the LRIT
Coordinator, indicate the dates and times when it suspended and resumed normal system
operational status.
3.4.1 The advisory notices referred to in paragraph 3.3 should be removed.
3.5 The DC concerned, the IDE and the DDP server, as the case may be, should assist and
cooperate with the other components of the LRIT system with a view to enabling them to resume
or continue normal operations in case they encounter any difficulties which arise as a result of
the unforeseen event(s) which it has encountered or as a result of the measures or actions
which it has taken in order to control or manage the unforeseen event(s) and/or to resume or
restore its normal operation.
4 Reporting temporary suspension of operations and reduction of level of service
4.1 The DC concerned, the IDE and the DDP server, as the case may be, should prepare,
no later than 30 days after the end of the scheduled or planned activity or of an unforeseen
event which affected its operation, the report set out in appendix 1.
4.2 The aforesaid report should be made available in the case of:
DDP, respectively;
.2 a DC on its web interfaces, if such an interface exists and is accessible by the

other components of the LRIT system and the LRIT Coordinator or if the DC
concerned does not have such interface it should consult with the IDE and or
the DDP server with a view to posting the report on the IDE Administrative
web interface and/or the DDP.
Annex, page 157
4.3 All DCs, the IDE and the DDP server should establish the necessary procedures for the
preparation, review and approval of the required reports and for the authorization of their
publication.
5 Monthly recording of temporary suspension of operations and reduction of level

of service
5.1 The DC concerned, the IDE and the DDP server, as the case may be, should prepare
monthly records summarizing the temporary suspension of operations or reduction of the level of
service as set out in appendix 2.
5.2 All DCs, the IDE and the DDP server should establish the necessary procedures for the
preparation, review and approval of the required monthly reports and for the authorization of
their release to other parties.
Annex, page 158
Appendix 1
REPORT ON
TEMPORARY SUSPENSION OF OPERATIONS
OR REDUCTION OF LEVEL OF SERVICE
<enter name of the LRIT component for which this report is made1>
Report on Temporary suspension of operations/Reduction of the level of services provided2

Due to Scheduled or planned activity(ies)/Unforeseen event(s)2
Commenced (Date and time3)
on
Ended on (Date and time3)
Duration (Days, hours, minutes and seconds)
Description:
Provide a summary or a brief description of what has occurred.
Chronology:
Provide a timeline of events that occurred in chronological order.
Causes and evaluation:
Provide a summary or a brief description of what caused the issue to occur.
Corrective actions (taken or planned), if any:
Provide a summary or a brief description of the steps or actions taken to correct the issue and to
return LRIT component affected to normal operations.
Provide a summary or a brief description of any further steps or actions which are planned in
order to prevent reoccurrence.
Recommendation(s), if any:
Provide a summary or a brief description of any recommended action(s) which the LRIT system
should consider taking in order to prevent the issue from reoccurring in the component of the
LRIT system which has been affected or from occurring in other ones.
Lessons learned, if any:
Provide a summary or a brief description of the lessons learned from analysis of this occurrence.
1
For example National LRIT Data Centre of [], Regional/Cooperative LRIT Data Centre [], International
LRIT Data Exchange, LRIT Data Distribution Plan.
2
3
Universal Coordinated Time Delete as appropriate.
Annex, page 159
Pending issues:
Provide a summary or a brief description of issues which are still under investigation or have not
been resolved.
Supplementary information:
Provide any further information which is deemed useful or necessary in order to form a correct
understanding of this report.
Focal point:
Name, title and contact details (telephone and facsimile number and e-mail address) of a
person(s) who is authorized to provide clarification(s) or further information in relation to this
report.
Date:
Enter the date on which the report is issued.
Report reference:
Enter reference number of the report.
Annex, page 160
Appendix 2
MONTHLY RECORDS OF TEMPORARY SUSPENSION OF OPERATIONS OR REDUCTION OF THE LEVEL OF SERVICE

<enter name of the LRIT component for which this report is made1>
Notification
on
return to
Initial normal Advisory Report
Commence Ended notification operations notice reference9
Case Nature1 Reason2 on3 on4 Duration5 sent6 sent7 posted8 published10 Notes11
Guidance notes:
1 Enter T: Temporary suspension of operations or R: Reduction of the level of services provided.

2 Enter S: Scheduled or planned activity(ies) or U: /Unforeseen event(s).
3, 4 Enter Date and Universal Coordinated Time.
5 Enter Days, hours, minutes and seconds.
6 Enter Date and Universal Coordinated Time when the other components of the LRIT system and the LRIT Coordinator were advised in accordance with
paragraphs 2.1 or 3.2, as the case may be.
7 Enter Date and Universal Coordinated Time when the other components of the LRIT system and the LRIT Coordinator were advised in accordance with
paragraphs 2.4 or 3.4, as the case may be.
8 Enter Yes in case an advisory notice was posted in accordance with paragraphs 2.2 or 3.3, as the case may be, or otherwise enter No.
9 Enter The reference number of the report specified in section 4.1 which relates to the case.
10 Enter Date on which the report specified in section 4.1 was published in accordance with paragraph 4.2.
11 Enter Any other necessary information.
1
For example National LRIT Data Centre of [], Regional/Cooperative LRIT Data Centre [], International LRIT Data Exchange, LRIT Data Distribution Plan.
Annex, page 161
ANNEX 3
PROCEDURES FOR THE CONSIDERATION OF PROPOSALS FOR THE AMENDMENT

OF THE TECHNICAL SPECIFICATIONS FOR THE LRIT SYSTEM, THE XML SCHEMAS
AND THE TEST PROCEDURES AND CASES
1 APPLICATION
1.1 The present procedures have been developed to enable the correction of errors or
omissions in, and for the consideration and adoption of amendments to, the Technical
specifications for the LRIT system, including the XML schemas and the test procedures and
cases set out in the Protocols and arrangements for the prototype, development, integration and
modification testing phases of the LRIT system (collectively referred to below as "amendments"),
approved by the Committee, at its eighty-fifth session, which are necessary in order to ensure
the continuation of the establishment and efficient and correct functioning of the LRIT system.
1.1.1 The present procedures are in effect between 8 December 2008 and 15 May 2009 and
are only applicable between the Contracting Governments which established LRIT Data Centres
(DCs) which satisfactorily completed the prototype testing phase or DCs which are, or will be,
conducting testing during the developmental testing phase (collectively referred to below as
"Contracting Governments establishing DCs"), the International LRIT Data Exchange (IDE) and
the LRIT Data Distribution Plan (DDP) server.
1.1.2 Proposals for the consideration and adoption of amendments identified on or

after 16 May 2009 should be submitted no later than 22 May 2009 for consideration, if possible,
by the Committee at its eighty-sixth session.
1.1.2.1 The Secretariat should, following consultations with the Chairman and the Secretary of
the Committee, bring to the attention of the Committee any proposals submitted pursuant to
paragraph 1.1.2.
2 PROPOSALS
2.1 Proposals for the consideration and adoption of amendments, through correspondence,
should be submitted by Contracting Governments establishing DCs, IDE and DDP server to the
Secretariat by e-mail (LRIT@imo.org) using the request forms provided in appendices 1, 2 and
3, as the case may be, and should be accompanied by the documents and electronic files
specified therein.
2.2 Proposals for the consideration and adoption of amendments, by the Ad Hoc LRIT
Group, should be submitted by Contracting Governments establishing DCs, IDE and DDP server
to the Secretariat in accordance with the provisions of the Guidelines on the organization and
method of work of the MSC and MEPC and their subsidiary bodies (MSC-MEPC.1/Circ.2), using
the request forms provided in appendices 1, 2 and 3, as the case may be, and should be
accompanied by the documents and electronic files specified therein.
2.3 Copies of appendices 1 to 3, Technical specifications for the LRIT system, including the
XML schemas and test procedures and test cases from the Protocols and arrangements for the
prototype, development, integration and modification testing phases of the LRIT system may be
obtained from the Secretariat in word format upon request.
Annex, page 162
2.4 In case a proposal, which is to be considered through correspondence, is deemed to be

incomplete (i.e. it does not include all required information, documents and electronic files), the
Secretariat should advise accordingly the submitter.
2.5 When a proposal is to be considered through correspondence, the Secretariat should

forward by e-mail the proposal, in case it has been deemed to be complete (i.e. provide all
required information, documents and electronic files), to the Contracting Governments
establishing DCs, all DCs, the IDE, the DDP server (collectively referred below as "recipients of
the proposal") and the LRIT Coordinator as soon as it receives such proposals.
2.5.1 When a proposal is to be considered through correspondence, the Secretariat should

forward the proposal received to the person(s) who have been designated, in official
communications to the Organization, by the Contracting Government concerned as the national
point(s) of contact for LRIT-related matters (refer to paragraph 11.2.8 of the Performance
standards) and as the point of contact for matters relating to the DC being established by
Contracting Governments (refer to paragraph 11.2.11 of the Performance standards). The
arrangements for forwarding proposals to the IDE should be agreed between the United States
and the Secretariat.
3 CONSIDERATION OF PROPOSALS
3.1 General
3.1.1 Contracting Governments establishing DCs, the IDE and the DDP server may request
the consideration of a proposal either:
.1 through correspondence in accordance with the provisions of this procedure

(refer to paragraphs 3.1 to 3.2.7 and 4.1 to 4.7); or
.2 by the Ad Hoc LRIT Group within the framework of its terms of reference (refer
to paragraphs 3.3 to 4.7).
3.1.2 In all cases, those invited to consider the proposed amendments are required and
expected to satisfy themselves that the proposed amendment(s), including any consequential
one(s) are sound and reasonable. In addition, they are expected to test the electronic file(s) of
the amended XML schema(s), in case the proposed amendment(s) relate or entail consequential
amendment(s) to the XML schema(s) and satisfy themselves that the proposed amendment(s),
including any consequential one(s), are workable and improve the functionality and efficiency of
the LRIT system and that their acceptance would not adversely affect the continuation of the
establishment or the functioning of the LRIT system.
3.2 Consideration of proposals through correspondence
3.2.1 The Contracting Governments establishing DCs, the IDE and the DDP server
(collectively referred below as "interested parties") should, within two working days after the date
on which the proposal has been forwarded to them, advise the Secretariat by e-mail whether
they concur with the proposed amendment(s), including any consequential one(s).
3.2.1.1 The response of the Contracting Governments establishing DCs should originate from
the person(s) who have been designated, in official communications to the Organization, by the
Contracting Government concerned as the national point(s) of contact for LRIT-related matters
(refer to paragraph 11.2.8 of the Performance standards) or by a person who he/she has
authorized to act on his/her behalf and he/she has advised to this end the Secretariat and should
be copied to all recipients of the proposal.
Annex, page 163
3.2.2 In case a Contracting Government which has established or is in the process of

establishing a DC does not respond within the time period specified in paragraph 3.2.1, the
Secretariat should consider that the Contracting Government in question accepts the proposed
amendment(s).
3.2.3 The United States, in its capacity as provider of the IDE on an interim basis and
Secretariat, acting on behalf of the Organization as provider of the DDP server and of the Public
Keys Infrastructure (PKIs), should always expressly state their position on the proposed
amendment(s).
3.2.4 Subject to the provisions of paragraph 4.1, the proposed amendment(s), including any
consequential one(s), should be deemed accepted if and only if all interested parties have
communicated, subject to the provisions of paragraphs 3.2.2 and 3.2.3, to the Secretariat their
acceptance.
3.2.5 In case any one of the interested parties, subject to the provisions of paragraph 3.2.2,
is unable to accept the proposed amendment(s), including any consequential one(s), they should
advise by e-mail the Secretariat and the other recipients of the proposal the reason(s) to this
end.
3.2.5.1 In such cases, the interested parties should endeavour through consultations to resolve
the issue. If such consultations do not lead to a satisfactory resolution of the issue within two
working days after they have commenced, the Secretariat should advise the recipients of the
proposal that the proposed amendment(s), including any consequential one(s), have been
rejected.
3.2.6 In case any of the interested parties is only able to accept the proposed amendment(s),
including any consequential one(s), subject to the amendment(s) in question or any
consequential one(s) being modified, should advise by e-mail the Secretariat and the recipients
of the proposal to this end. In such cases, the party making its acceptance conditional on the
proposed amendment(s) or any consequential one(s) being modified should provide the
recipients of the proposal with salient information by forwarding together with its response a
completed request form, using the forms provided in annexes 1, 2 and 3, as the case may be,
together with the necessary accompanying documentation and electronic files.
3.2.6.1 In such cases, the interested parties should endeavour through consultations to resolve
the issue. If such consultations do not lead to a satisfactory resolution of the issue within two
working days after they have commenced, the Secretariat should advise the recipients of the
proposal that the proposed amendment(s), including any consequential one(s), have been
rejected.
3.2.7 In all cases, all correspondence relating to matters falling within the scope of this
procedure should be copied to all recipients of the proposal, the Secretariat (in case such
correspondence is not addressed to the Secretariat) and the LRIT Coordinator.
3.2.8 In case a proposal is rejected, nothing prevents those who have submitted it to submit it
for consideration by the Ad Hoc LRIT Group and/or the Committee, if they deem so appropriate.
3.3 Consideration of proposals by Ad Hoc LRIT Group
3.3.1 Consideration of proposed amendments by the Ad Hoc LRIT Group should be done by
the Group in accordance with its terms of reference.
Annex, page 164
4 ACCEPTANCE AND IMPLEMENTATION OF AMENDMENTS
4.1 The acceptance of any amendment(s), including any consequential one(s), under this
procedure, is on a provisional basis and subject to consideration and adoption of the related
amendment(s) by the Committee at its eighty-sixth session.
4.2 In case the proposed amendment(s), including any consequential one(s), have been
deemed accepted, the Secretariat should, as soon as possible, in case the amendment(s)
relate to:
.1 the technical specifications for the LRIT system and/or the test procedures
and cases, prepare a record of the amendment(s); or
.2 the XML schema, amend accordingly:
.1 the index record of the version control document of the XML

schemas to indicate the new version number and date of the XML
schema(s) being amended;
.2 the word format document of the XML schema(s) so as to incorporate

the accepted amendment(s) and to show the new version number
and date; and
.3 the related XSD file in the master XSD files so as to incorporate the
accepted amendment(s) and to show its new versions number and
date.
deemed accepted through correspondence, the Secretariat, in consultation with the United
States, in its capacity as provider of the IDE on an interim basis should establish the date and
time as from which the accepted amendment(s), including any consequential one(s), are to be
implemented.
4.4 In case the amendments(s) are deemed accepted by the Ad Hoc LRIT Group, the
Group should establish the date and time as from which the accepted amendment(s), including
any consequential one(s), are to be implemented.
deemed accepted, the Secretariat should forward the documents and electronic files referred to
in paragraph 4.2 to the Contracting Governments establishing DCs, all DCs, the IDE, the DDP
server and all those who have requested in writing and received from the Secretariat copies of
the XSD files as approved by the Committee, at its eighty-fifth session, and advise the date and
time as from which the accepted amendment(s), including any consequential one(s), are to be
implemented.
4.6 Notwithstanding the provisions of paragraph 4.1, in case the proposed amendment(s),
including any consequential one(s), have been deemed accepted, all DCs, the IDE and the DDP
server should implement the accepted amendment(s) and, in case these entail to any
amendments of the test procedures and/or test cases:
.1 in case, prototype, developmental or integration testing phases has already

been completed, conduct and satisfactorily complete all new or additional
required tests; or
Annex, page 165
.2 in case testing is in hand, repeat any test(s) which have already been
satisfactorily completed or conduct any pending test(s) in accordance with the
amended test procedures and cases.
4.7 In case any proposed amendment(s), including any consequential one(s), have been
deemed accepted through correspondence, the Secretariat should advise accordingly the
Committee, at its eighty-sixth session, for the Committee to consider the matter and formally
adopt the amendment(s), as it deems appropriate.
4.8 In case any of the interested parties experiences difficulties in implementing or

complying with any agreed amendment under this procedure, it may proposed that the LRIT
system reverts to the stage of operation it function prior to the implementation of the agreed
amendment.
4.8.1 To this end, the interested party concerned may propose the consideration and
adoption of amendments in accordance with the provisions of this procedure.
Annex, page 166
Appendix 1
REQUEST FOR THE CONSIDERATION OF

PROPOSED AMENDMENT(S) TO THE XML SCHEMA(S)
OR FOR THE MODIFICATION OF PROPOSED AMENDMENT(S)
Part I Submitter of the proposal
1 Submitted by
Part II Details of the proposed amendment(s) or of the proposed modification(s)
1 XML schema(s)
2 XML schema(s) requiring consequential amendment(s), if any
3 Proposed amendment(s)
4 Proposed consequential amendment(s), if any
5 Brief description of the proposed amendment(s)
6 Brief description of the proposed consequential amendment(s), if any
7 Reason(s) for proposing the amendment(s), including any consequential one(s)
8 Impact of not implementing the proposed amendment(s), including any consequential

one(s)
Annex, page 167
9 Consequential amendment(s) to the technical specifications for the LRIT system, if any
10 Consequential amendment(s) to the test procedures and/or cases, if any
11 Additional information (optional)
Part III Supporting documents and electronic files
1 The XML schema(s) in word format showing the proposed amendment(s) as track
changes
2 The XML schema(s) in their native format incorporating the proposed amendment(s)
3 The proposed amendment(s) to the technical specifications for the LRIT system,
if any (in case these are set out on separate sheet(s))
4 The proposed amendment(s) to the test procedure(s) and/or case(s)
5 Other document(s) (specify)
Part IV Contact details
1 Name, title and contact details (telephone and facsimile numbers and e-mail address)
of the person(s) who is authorized to provide clarification(s) or further information in
relation to this proposal:
of the person submitting the proposal:
Part V Declaration of authority
The undersigned declares that he/she is duly authorized to submit this proposal.
(Signature of the person submitting the proposal)
Date:
Annex, page 168
Guidance notes for completing the request
1 Submitted by
Enter the Contracting Government proposing the amendment(s) or the modification of

the proposed amendment(s); or the United States in the capacity of the IDE operator; or
the Secretariat.
1 XML schema(s)
Enter the file name of the XML schema(s), the version and date of the XSD file(s) which
requires amendment(s), for example Pricing.xsd, version 1.0 dated 22.08.2008.
2 XML schema(s) requiring consequential amendment(s), if any
In case any other XML schema(s) need to be amended as a result of the proposed
amendment(s) under item 3, enter the name(s) of the XML schema(s), the version and
date of the XSD file(s) which need to be also amended and complete accordingly
item 4, or otherwise enter None.
The following provides an illustrative example:
<xs:sequence>

<xs:element name="IDEInterfaceWebServiceLocation" type="xs:anyURI">
<xs:annotation>
<xs:documentation xml:lang="en">
This element indicates the location of the Web Services interface to IDE
communications
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="DDPInterfaceWebServiceLocation" type="xs:anyURI">
<xs:annotation>
This element indicates the location of the Web Services interface to DDP Server
communications
</xs:documentation>
</xs:annotation>
</xs:element>

</xs:sequence>
</xs:complexType>
For each of the XML schema(s) identified under item 2, enter the same level of
information as given in the example provided under item 3, or otherwise enter None.
Annex, page 169
Provide a narrative description of the amendment(s) proposed under item 3.
Provide a narrative description of the consequential amendment(s) proposed under

Provide justification and/or explain the reason(s) why the amendment(s) proposed
under items 3 and 4, if any, should be accepted.

one(s)
Provide information on the impact of the amendment(s) proposed under items 3 and 4,
if any, on the LRIT system, on the conduct of the testing of the system and on the
consequences in case the proposed amendment(s) were not to be accepted.
In case the proposed amendment(s) under items 3 and 4, if any, require the adoption of
consequential amendment(s) to the technical specifications for the LRIT system,
identify the technical specification(s) which need to be amended, the related
paragraph(s) thereto, provide a brief description of the required amendment(s) and set
out the proposed amendment(s), or otherwise enter None.
amendment(s) to the test procedure(s) and/or case(s), identify the test procedure(s)
and/or case(s) which need to be amended, provide a brief description of the required
amendment(s) and set out the proposed amendment(s) on a separate sheet, or
otherwise enter None.
In view of the number of columns involved, set out the proposed amendment(s) on a
separate sheet using track changes (related extract, in word format, from the Protocols
and arrangements for the prototype, development, integration and modification testing
phases of the LRIT system may be obtained from the Secretariat).
Provide any other additional information deemed necessary in support of the proposal
and/or explain the utility or reason(s) for forwarding the other document identified under
item 5 of part III, or otherwise enter None.
The request should always be accompanied by:
- the documents and electronic files referred to under items 1 and 2;
Annex, page 170
- the document referred to under item 3 if the entries under item 10 of part II is other
than None;
than None.
The documents and electronic files referred to under items 1 and 2 should be the
versions of those in effect at the time of the submission of the proposal and their
version number and date should not be altered.
In case any other documents are submitted, item 5 should indicate Yes and the utility or
reason(s) for forwarding these should be explained under item 11 of part II.
Enter Yes or No in the right column to identify the documents and electronic files which
accompany the proposal.
No guidance is provided.
The person(s) who have been designated by the Contracting Government concerned,
in official communications to the Organization, as the point(s) of contact for
LRIT-related matters (refer to paragraph 11.2.8 of the Performance standards) would
be automatically considered as being authorized to submit the request. Otherwise, the
authority of any other person submitting the request should be confirmed by the
aforesaid to the Organization.
Annex, page 171
Appendix 2

PROPOSED AMENDMENT(S) TO THE
TECHNICAL SPECIFICATIONS FOR THE LRIT SYSTEM
1 Submitted by
1 Technical specifications for the LRIT system
2 Technical specifications for the LRIT system requiring consequential amendment(s), if

any

one(s)
Annex, page 172
9 Consequential amendment(s) to the XML schemas, if any
changes, if any
2 The XML schema(s) in their native format incorporating the proposed
amendment(s), if any
3 The proposed amendment(s) to the technical specifications for the LRIT system
(in case these are set out in separate sheet(s))
4 The proposed amendment(s) to the test procedure(s) and/or case(s), if any
Date:
Annex, page 173
1 Submitted by

the Secretariat.
1 Technical specifications for the LRIT system
Enter the name of the technical specification for the LRIT system which requires
amendment(s), the related paragraph(s) thereto and the document which you are using
as reference for the proposal, for example Technical specifications for communications
within the LRIT system; paragraph 2.3.4.7.1 and table 14, reference document
MSC.1/Circ.[1259][.] on Interim revised technical specifications for the LRIT system.
2 Technical specifications for the LRIT system requiring consequential amendment(s),

if any
In case any other technical specifications for the LRIT system need to be amended as
a result of the proposed amendment(s) under item 3, enter the name(s) of the technical
specifications for the LRIT system which needs also to be amended, the related
paragraph(s) thereto, the document which you are using as reference for the proposal
and complete accordingly item 4, or otherwise enter None.
The following provide illustrative examples:
1 The following text is inserted at the end of paragraph 7.1.4.6 of part I:
"7.2 In case any of the geographical areas to be represented by the

polygons referred to in paragraph 7.1 straddles the meridian of 180 degrees
longitude, the geographical area in question should be represented by two
polygons having a common boundary along the 180 degrees longitude."
2 The existing paragraph 2.3.4.7.1 (previously paragraph 2.3.3.7.1) is amended

to read as follows:
".1 the DC to which the ship is transmitting LRIT information receives

ship position information at time point -5 5/6;"
For each of the technical specifications for the LRIT system identified under item 2,
enter the same level of information as given in the example provided under item 3, or
Annex, page 174


one(s)
amendment(s) to the XML schema(s), enter the name(s) of the XML schema(s) and the
version and date of the XSD file(s) which need to be also amended, provide a brief
description of the required amendment(s) and enter the proposed amendment(s) to the
XML schema(s) or otherwise enter None.
The following is an illustrative example:
Pricing.xsd, version 1.0 dated 22.08.2008
DDPRequest.xsd: This change will ensure that all DDPRequest messages sent to the DDP
Server in response to a DDPNotification message will indicate the source DDPNotification
message. Where a DDPRequest is not sent in response to a DDPNotification the ReferenceId
will be empty.
<xs:sequence>

<xs:annotation>
communications
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:annotation>
Annex, page 175
communications
</xs:documentation>
</xs:annotation>
</xs:element>

</xs:sequence>
</xs:complexType>
amendment(s) to the test procedure(s) and/or case(s), identify the test procedure(s)
and/or case(s) which need to be amendment, provide a brief description of the required
amendment(s) and set out the proposed amendment(s) on a separate sheet, or
- the documents and electronic files referred to under items 1 and 2 if the entries
under in item 9 of part II is other than None;
- the document referred to under item 4 if the entries under item 10 of part II
is other than None.
Annex, page 176
Annex, page 177
Appendix 3

PROPOSED AMENDMENT(S) TO THE
TEST PROCEDURES AND/OR CASES
1 Submitted by
1 Test procedure(s) or test case(s)
2 Test procedure(s) or test case(s) requiring consequential amendment(s), if any

one(s)
Annex, page 178
changes, if any
2 The XML schema(s) in their native format incorporating the proposed
amendment(s), if any
3 The proposed amendment(s) to the technical specifications for the LRIT system,
if any (in case these are set out in separate sheet(s))
4 The proposed amendment(s) to the test procedure(s) and/or case(s)
Date:
Annex, page 179
1 Submitted by

the Secretariat.
1 Test procedure(s) or test case(s)
Enter the name of the test procedure(s) and/or case(s) which requires amendment, and
the document which you are using as reference for the proposal, for example LRIT
Data Centre Test Procedures and Test Cases; Table 2.2, Test procedure DC-2.0, Test
case DC-2.2 and DC-2.4, reference document MSC 85/6/1/Add.1, annex 2, annex,
appendix 2.
2 Test procedure(s) or test case(s) requiring consequential amendment(s), if any
In case any other test procedure(s) and/or case(s) need to be amended as a result of
the proposed amendment(s) under item 3, enter the name(s) of the test procedure(s)
and/or case(s) which requires amendment(s), the document which you are using as
reference for the proposal, and complete accordingly item 4, or otherwise enter None.
For each of the test procedure(s) and/or case(s) identified under item 2, provide the
same level of information as indicated under item 3, or otherwise enter None.

Annex, page 180

one(s)
consequential amendment(s) to the technical specifications for the LRIT system,
identify the technical specification(s) which need to be amendment, the related
paragraph(s) thereto, provide a brief description of the required amendment(s) and set
out the proposed amendment(s), or otherwise enter None.
amendment(s) to the XML schema(s), enter the name(s) of the XML schema(s) and the
version and date of the XSD file(s) which need to be also amended, provide a brief
description of the required amendment(s) and enter the proposed amendment(s) to the
XML schema(s) or otherwise enter None.
The following is an illustrative example:
Pricing.xsd, version 1.0 dated 22.08.2008
DDPRequest.xsd: This change will ensure that all DDPRequest messages sent to the DDP
Server in response to a DDPNotification message will indicate the source DDPNotification
message. Where a DDPRequest is not sent in response to a DDPNotification the ReferenceId
will be empty.
<xs:sequence>

<xs:annotation>
communications
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:annotation>
communications
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
Annex, page 181
- the documents and electronic files referred to under items 1 and 2 if the entries
under item 10 of part II is other than None;
than None.
___________

IMO - MSC 1 - CIR 1294 REV 2 & CIR 1259 REV 4 - 15 fEB 2011 - LONG-RANGE IDENTIFICATION AND TRACKING SYSTEM TECHNICAL DOCUMENTATION PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IMO - MSC 1 - CIR 1294 REV 2 & CIR 1259 REV 4 - 15 fEB 2011 - LONG-RANGE IDENTIFICATION AND TRACKING SYSTEM TECHNICAL DOCUMENTATION PDF

Uploaded by

Copyright:

Available Formats

E

Ref. T2-OSS/1.4 MSC.1/Circ.1259/Rev.4

LONG-RANGE IDENTIFICATION AND TRACKING SYSTEM

INTERIM REVISED TECHNICAL SPECIFICATIONS FOR THE LRIT SYSTEM

1 The Maritime Safety Committee (the Committee), at its eighty-eighth session

.1 Technical specifications for the International LRIT Data Exchange;

.2 Technical specifications for the International LRIT Data Centre;

.3 Technical specifications for communications within the LRIT system;

.4 Technical specifications for the LRIT Data Distribution Plan;

consideration of proposed amendments through correspondence (refer to annex 3 to

8 SOLAS Contracting Governments, LRIT Data Centres acting through SOLAS

LONG-RANGE IDENTIFICATION AND TRACKING SYSTEM

INTERIM REVISED TECHNICAL SPECIFICATIONS FOR THE LRIT SYSTEM

1.1 Scope and background

.1 Annex 1 Technical specifications for the International LRIT Data

.2 Annex 2 Technical specifications for the International LRIT Data

.3 Annex 3 Technical specifications for communications within the

.4 Annex 4 Technical specifications for the LRIT Data Distribution Plan;

.6 Annex 6 XML schemas.

1.1.2.3 In operating the LRIT system, recognition should be given to international

1.2 General description of the system and definitions

1.2.1 LRIT system description

.1 the shipborne LRIT information transmitting equipment;

.2 the Communication Service Provider(s);

.3 the Application Service Provider(s);

.4 the DC(s), including any related Vessel Monitoring System(s);

.5 the LRIT Data Distribution Plan server;

.6 the IDE, and

.7 LRIT Data Users.

1.2.2 LRIT system operation

1.2.2.3 The Communication Service Provider (CSP) provides the communication

LRIT system architecture

Contracting Government ... Contracting Government ... Contracting Government ...

flag State flag State flag State

National Regional Cooperative International

LRIT LRIT LRIT LRIT

D/B D/B D/B D/B

One standard for data format,

1.2.3.1 Unless expressly provided otherwise:

.1 Convention means the International Convention for the Safety of Life at

.2 Regulation means a regulation of the Convention.

.3 Chapter means a chapter of the Convention.

.4 LRIT Data User means a Contracting Government or a Search and rescue

.5 Committee means the Maritime Safety Committee.

.6 High-speed craft means a craft as defined in regulation X/1.3.

.8 Organization means the International Maritime Organization.

.9 Vessel Monitoring System means a system established by a Contracting

.10 LRIT information means the information specified in regulation V/19-1.5.

.15 Contracting Government means a Contracting Government to the

.19 LRIT Component refers to 1.2.1.1.

1.2.4 Acronyms used within this document

.1 ASP Application Service Provider

.2 BIST Built in Self Test

.3 CSP Communication Service Provider

.4 DC LRIT Data Centre

.5 DDP LRIT Data Distribution Plan

.6 FAT Factory Acceptance Test

.7 HMAC Hash Message Authentication Code

.8 IDC International LRIT Data Centre

.9 IDE International LRIT Data Exchange

.10 IP Internet Protocol

.11 LES Land Earth Station

.12 LRIT Long-Range Identification and Tracking of ships