MSC.1/Circ.1259/Rev.9

29 November 2022

 

LONG-RANGE IDENTIFICATION AND TRACKING SYSTEM – TECHNICAL DOCUMENTATION (PART I)

 

1          The Maritime Safety Committee, at its 106th session, approved amendments to the Long-range identification and tracking system – Technical documentation (Part I) (MSC.1/Circ.1259/Rev.8) prepared by the Sub-Committee on Navigation, Communications and Search and Rescue, at its ninth session (NCSR 9/24/Add.1, annex 4). This circular incorporates the aforesaid amendments as well as additional editorial amendments and minor corrections.

 

2          The Long-range identification and tracking system – Technical documentation (Part I) 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          This circular 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 (resolution MSC.263(84), as amended) and the Long-range identification and tracking system – Technical documentation (Part II) (MSC.1/Circ.1294, as revised).

 

4          The XML schemas 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 may request them from the Secretariat by sending an email 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 and the International LRIT Data Exchange.

 

6          This circular revokes MSC.1/Circ.1259/Rev.8 issued on 8 April 2020. Any reference to MSC.1/Circ.1259/Rev.8 or any of its previous versions should be read as reference to the present circular.

 

ANNEX

(English only)

 

LONG-RANGE IDENTIFICATION AND TRACKING SYSTEM – TECHNICAL DOCUMENTATION (PART I)

 

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 revised Performance standards) adopted by resolution MSC.263(84), as amended.

 

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

 

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 the revised 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 revised 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).

 

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 revised 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 WGS 84 datum), time and identification, as described in table 1 of the revised 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 passes 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 State¹, port State², coastal State³ or Search and Rescue (SAR) service.

_____________

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

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

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

 

1.2.2.10  The LRIT Coordinator assists in the establishment of components of the LRIT system (namely the IDE and IDC), performs administrative functions, and reviews and audits 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.

 

Figure 1

LRIT system architecture

 

 

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.

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

.20     Passenger ship means a ship as defined in regulation I/2(f).

.21     Cargo ship means a ship as defined in regulation I/2(g).

.22     Tanker means a ship as defined in regulation I/2(h). 

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  The term "Ship Type" means type of the ship transmitting the LRIT information. The following main categories of ship-types are defined exclusively to be used for the purposes of the LRIT system, including the respective ship type codes:

 

.1       Passenger ship⁴ (ship type code 0100);

.2       Cargo ship^5,6,   (ship type code 0200);

.3       Tanker (ship type code 0300);

.4       Mobile offshore drilling unit (ship type code 0400); and

.5       Other ship⁷ (ship type code 9900). 

_____________

⁴     Including High-speed Passenger Craft.

⁵     Excluding Tanker.

⁶     Including High-speed Craft.

⁷     Ships which are not defined in other categories should be categorized as "other ship".

 

1.2.3.4  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

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

 

2.1.1.7  As stated in the revised 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 mapping 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

 

 

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.

 

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-17) and indicates whether the message is routed between DCs or broadcast to all DCs.

 

Table 1

Summary of LRIT messages¹

 

 

Note:

 

¹     Refer to paragraph 2.2 of the Technical specifications for communications within the for further information.

²     DC1 = requesting DC; DC2 = providing DC; DCx = all DCs; R/CDC1 = Regional or Co-operative LRIT Data Centre; TX= Transmitting; RX = Receiving.

³     Excludes Coastal SURPIC messages in which a DataUserProvider is specified.

 

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 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 (Access Type 6 only), and 7 where ReceiptCode = 1 (no ship in SAR SURPIC area)) should always be routed regardless of the DDP version used. 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 16) 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 12 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:

 

 

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;

.3       routeing the LRIT message to the appropriate DC or to all DCs in the case of broadcast messages (i.e. 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 online); 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 DDPserver, update the system status information by processing the SystemStatus parameter in the messages (i.e. if no message from a DC or the DDP server, or message with unrecognized values or incorrect DDP version number, generate a warning to the IDE Operator), and archive 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.

3.3.8    Message handling for Pricing messages (Messages 13 to 15)

 

3.3.8.1  Messages 13 to 15 have been removed from the LRIT system.

 

3.3.9    Message handling for Geographical area update (Messages 16)

 

3.3.9.1  The IDE should process the Geographical area update message by:

 

.1       Identifying the polygon(s) for technical validation by looking at the GML file parameter and performing the validation based on the constraints set out in section 5 of the Technical specifications for the DDP;

.2       Building a receipt message with the receipt code of:

-        7, if the Action Type parameter is not 0 or if one or more polygons do not pass technical validation for any reason; and

-        10, if all polygons pass technical validation; and

.3       Archiving all messages in the Journal(s). 

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

.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 revised 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 3.6.1.2, 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. DCs points of contact defined in the DDP may create sub-accounts with the same level of front end access. For this the DC operator should use a web interface;

.2       the DDP operator should have limited access so as to be able to perform any necessary queries for troubleshooting or system management functions. For this the DDP operator should use a web interface;

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

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

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

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

.14     Query the IDE for a message count (IDE operator, DC operator, LRIT Coordinator); and

.15     support the functionality described in annex 2 to the annex of MSC.1/Circ.1294, as revised (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 revised 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.

 

3.7.1.4  The Journal entries should be sent to the requesting entity, specified in paragraph 3.7.1.3, 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 five 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

 

 

Notes:

 

¹        All times should be indicated as Universal Coordinated Time (UTC).

²        Receiving.

³        Transmitting.

 

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.