Onderwerp: Bezoek-historie

1219 Interim LRIT technical specifications and other matters
Geldigheid:15-12-2006 t/m Status: Geldig vandaag

Dit onderwerp bevat de volgende rubrieken.

Interim LRIT technical specifications and other matters

  dd-mm-yyyy = Entry into force
DocumentMSC.1/Circ.121915-12-2006

Ingangsdatum: 15-12-2006

Interim LRIT technical specifications and other matters

  dd-mm-yyyy = Entry into force
DocumentMSC.1/Circ.121915-12-2006

Annex 01 Draft technical specifications

Annex 1 - Draft technical specifications for the international LRIT data exchange

Ingangsdatum: 15-12-2006
Annex 1 - Draft technical specifications for the international LRIT data exchange

01 General provisions

1 - General provisions

Ingangsdatum: 15-12-2006
1 - General provisions

01.01 Scope and Background

1.1 - Scope and Background

Ingangsdatum: 15-12-2006

1.1 - Scope and Background

01.01.01 Scope
Ingangsdatum: 15-12-2006

1.1.1 - Scope

1.1.1.1 The intent of this document is to outline the technical specifications for the International LRIT Data Exchange within the international Long-Range Identification and Tracking (LRIT) system as stated in the terms of reference of resolution MSC.210(81).

1.1.1.2 This document has been prepared by the Ad Hoc Working Group on Engineering Aspects of Long-Range Identification and Tracking of Ships.

1.1.1.3 In preparing the document, the Ad Hoc Working Group has taken into account the provisions of SOLAS regulation V/19-1 and resolution MSC.210(81),  "Performance Standards and Functional Requirements for the Long Range Identification and Tracking of Ships."

01.01.02 Background
Ingangsdatum: 15-12-2006

1.1.2 - Background

1.1.2.1 The Maritime Safety Committee, at its eighty-first session in May 2006, adopted amendments to chapter V of the SOLAS convention in relation of LRIT. These amendments will enter into force on 1 January 2008 provided that acceptance criteria have been fulfilled by 1 July 2007.

1.1.2.2 The LRIT system provides for the global identification and tracking of ships.

1.1.2.3 In operating the LRIT system, recognition shall be given to international conventions, agreements, rules or standards that provide for the protection of navigational information.

1.1.2.4 The specifications for the International LRIT Data Exchange within the international LRIT system will detail the routing of LRIT positional data and LRIT request messages between LRIT Data Centres.

1.1.2.5 The specifications for data security throughout the network and protocols required for transporting data from one network point to another are described in the document entitled "Draft Technical Specifications for Communications within the LRIT System Network."

1.1.2.6 The draft specifications for the International LRIT Data Exchange for the international LRIT system as outlined in this document will be established and recognized by the Committee.

01.02 General Description of the System

1.2 - General Description of the System and Definitions
Ingangsdatum: 15-12-2006
1.2 - General Description of the System and Definitions
01.02.01 LRIT System Description
Ingangsdatum: 15-12-2006

1.2.1 - LRIT System Description

1.2.1.1 As described in resolution MSC.210(81), sub-section 1.2, 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 LRIT Data Centre(s), including any related Vessel Monitoring System(s);

  5. the LRIT Data Distribution Plan;

  6. the International LRIT Data Exchange, and

  7. LRIT Data Users.

1.2.1.2 As described in resolution MSC.210(81), sub-section 1.2, certain aspects of the performance of the LRIT system are reviewed or audited by an LRIT Co-ordinator acting on behalf of all Contracting Governments.

01.02.02 LRIT System Operation
Ingangsdatum: 15-12-2006

1.2.2 - LRIT System Operation

1.2.2.1 Sub-sections 1.2.2.1 to 1.2.2.11 provide a high-level overview of the LRIT system architecture. The LRIT system performance standards, resolution MSC.210(81), 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 positional data 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 resolution MSC.210(81), Table 1.


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 will travel 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, will add additional information to the LRIT message and pass along the expanded message to its associated LRIT Data Centre. 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 the document entitled "Draft Technical Specifications for Communication within the LRIT System."

1.2.2.6 LRIT Data Centres will store all incoming LRIT information from ships instructed by their Administrations to transmit LRIT information to that Data Centre. LRIT Data Centres will disseminate LRIT information to LRIT Data Users according to the Data Distribution Plan (DDP).

1.2.2.7 The LRIT Data Distribution Plan will contain the information required by the Data Centres for determining how LRIT information will be distributed to the various Contracting Governments. The DDP will contain information such as standing orders from Contracting Governments and geographical polygons relating to Contracting Governments¿ coastal waters and ports and port facilities.

1.2.2.8 The Data Centres will process all LRIT messages to and from the International LRIT Data Exchange (IDE). The IDE will process all LRIT messages between LRIT Data Centres. The IDE will route the message to the appropriate Data Centre based upon the information contained within the DDP. The IDE will neither process nor store the positional data contained within LRIT messages.

1.2.2.9 LRIT Data Users may 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.

1.2.2.10 The LRIT Co-ordinator assists in the establishment of the international components of the LRIT system, performs administrative functions, and reviews and audits certain components of the LRIT system.

1.2.2.11 Figure 1 provides an illustration of the LRIT system architecture.

 

Figure 1 - Typical LRIT system architecture

01.02.03 Definitions
Ingangsdatum: 15-12-2006

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 may also collect from the ships information specified by the Contracting Government(s) that has established it.

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

  11. IDC operator means the individual responsible for the daily operation and maintenance of the International LRIT Data
    Centre.

1.2.3.2 The term "ship," when used in the present Performance standards and functional requirements for long-range identification and tracking of ships, includes mobile offshore drilling units and high-speed craft as specified in SOLAS 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.

01.02.04 Acronyms Used Within This Document
Ingangsdatum: 15-12-2006

1.2.4 - Acronyms Used Within This Document

1.2.4.1 The acronyms that appear within this document shall have the meanings assigned to them in this Article:

1ASP

Application Service Provider

 

2CSP

Communication Service Provider

 

3DC

Data Centre

 

4DDP

Data Distribution Plan

 

5IDC

International Data Centre

 

6IDE

International LRIT Data Exchange

 

7LES

Land Earth Station

 

8MMSI

Maritime Mobile Service Identity

 

9RFP

Request for Proposal

 

10SAR

Search and Rescue

 

11SAR SURPIC

Search and Rescue Surface Picture

 

12SOLAS

International Convention for the Safety of Life at Sea

 

13SSL

Secure Sockets Layer

 

14VPN

Virtual Private Network

 

15VMSVessel Monitoring System

02 Role of the international LRIT data exchange

2 - Role of the international LRIT data exchange

Ingangsdatum: 15-12-2006
2 - Role of the international LRIT data exchange

02.01 Overview

2.1 - Overview

2.1.1 International LRIT Data Exchange

2.1.1.1 The International LRIT Data Exchange is a message handling service that facilitates the exchange of LRIT data amongst LRIT Data Centres to enable LRIT Data Users to obtain that LRIT positional data which they are entitled to receive. The IDE routes information between LRIT Data Centres.

2.1.1.2 The second function of the International LRIT Data Exchange is to store and archive message information in a Journal(s) that will be used for audit, billing and statistical analysis.

2.1.1.3 The International LRIT Data Exchange does not:

  1. provide information directly to a LRIT Data User;

  2. read the LRIT positional data contained in LRIT messages; and

  3. store or archive any LRIT positional data.

2.1.1.4 The application of standing orders and other information contained within the Data Distribution Plan is a function of individual LRIT Data Centres.

2.1.1.5 The International LRIT Data Exchange uses the ID of the destination LRIT Data User included in the messages to determine where to route the message. The IDE maps the LRIT Data User ID to the Internet address of the Data Centre holding the information using the mapping information from the Data Distribution Plan.

Ingangsdatum: 15-12-2006

2.1 - Overview

2.1.1 International LRIT Data Exchange

2.1.1.1 The International LRIT Data Exchange is a message handling service that facilitates the exchange of LRIT data amongst LRIT Data Centres to enable LRIT Data Users to obtain that LRIT positional data which they are entitled to receive. The IDE routes information between LRIT Data Centres.

2.1.1.2 The second function of the International LRIT Data Exchange is to store and archive message information in a Journal(s) that will be used for audit, billing and statistical analysis.

2.1.1.3 The International LRIT Data Exchange does not:

  1. provide information directly to a LRIT Data User;

  2. read the LRIT positional data contained in LRIT messages; and

  3. store or archive any LRIT positional data.

2.1.1.4 The application of standing orders and other information contained within the Data Distribution Plan is a function of individual LRIT Data Centres.

2.1.1.5 The International LRIT Data Exchange uses the ID of the destination LRIT Data User included in the messages to determine where to route the message. The IDE maps the LRIT Data User ID to the Internet address of the Data Centre holding the information using the mapping information from the Data Distribution Plan.

02.01.01 International LRIT Data Exchange
Ingangsdatum: 15-12-2006

2.1.1 - International LRIT Data Exchange

2.1.1.1 The International LRIT Data Exchange is a message handling service that facilitates the exchange of LRIT data amongst LRIT Data Centres to enable LRIT Data Users to obtain that LRIT positional data which they are entitled to receive. The IDE routes information between LRIT Data Centres.

2.1.1.2 The second function of the International LRIT Data Exchange is to store and archive message information in a Journal(s) that will be used for audit, billing and statistical analysis.

2.1.1.3 The International LRIT Data Exchange does not:

  1. provide information directly to a LRIT Data User;

  2. read the LRIT positional data contained in LRIT messages; and

  3. store or archive any LRIT positional data.

2.1.1.4 The application of standing orders and other information contained within the Data Distribution Plan is a function of individual LRIT Data Centres.

2.1.1.5 The International LRIT Data Exchange uses the ID of the destination LRIT Data User included in the messages to determine where to route the message. The IDE maps the LRIT Data User ID to the Internet address of the Data Centre holding the information using the mapping information from the Data Distribution Plan.

03 Functionality of the international LRIT data exchange

3 - Functionality of the international LRIT data exchange

Ingangsdatum: 15-12-2006
3 - Functionality of the international LRIT data exchange

03.01 Composition

3.1 - Composition

Ingangsdatum: 15-12-2006

3.1 - Composition

03.01.01 General Composition of the International LRIT Data Exchange
Ingangsdatum: 15-12-2006

3.1.1 - General Composition of the International LRIT Data Exchange

3.1.1.1 The general composition of the International LRIT Data Exchange is illustrated in Figure 2.

 

Figure 2 - Block diagram of IDE data flow

03.02 Data Centre Interface

3.2 - Data Centre Interface
Ingangsdatum: 15-12-2006
3.2 - Data Centre Interface
03.02.01 Overview
Ingangsdatum: 15-12-2006

3.2.1 - Overview

3.2.1.1 The International LRIT Data Exchange shall:

  1. receive LRIT information from all LRIT Data Centres participating in the international LRIT system; and

  2. establish a secure communication connection based upon the communication and data security protocols outlined in the "Draft Technical Specifications for Communication in the LRIT System."
03.02.02 Message Summary
Ingangsdatum: 15-12-2006

3.2.2 - Message Summary

3.2.2.1 Table 1 provides a summary of all LRIT messages (Messages 1-11) and indicates whether the message is routed between Data Centres or broadcast to all Data Centres.

Table 1 - Summary of LRIT messages

Message
Type

Message Name

Message Description/Purpose

TX(1)

RX(1)

Broadcast

LRIT positional data (position report) messages

1

Periodic Position ReportRegular periodic ship position reports.DC2IDENo
IDEDC1

2

Polled Position ReportShip position report as a result of a poll requestDC2IDENo
IDEDC1

3

SAR Position ReportShip's position report; for a special purpose (SAR); reported by Data Centres with ships in the area.DCxIDENo
IDEDC1
LRIT request messages

4

Ship Position RequestTo enable a LRIT Data Centre to request LRIT positional data for ships being monitored by another LRIT Data Centre (following request from a LRIT Data User).DC1IDENo
IDEDC2

5

SAR Poll
Request
Specific ship poll.
Received from polling Data Centre and routed to ship's DC using Register information (addressed).
Data poll is always addressed to a specific ship using MMSI. Can be a "send once" or "send at rate."
DC1IDENo
IDEDC2

6

SAR SURPIC RequestArea poll; routed to all Data Centres.DC1IDEYes
IDEDCx
Other messages

7

Error messageError message relating to an inability to process a LRIT request messageDC2IDENo
IDEDC1

8

Receipt messageTo enable a Providing LRIT Data Centre to confirm the receipt and processing status of a Request Message from a Requesting LRIT Data Centre.DC2IDENo
IDEDC1

9

Data
Distribution
Plan (DDP)
Update
This is a routine update of the DDP by the DDP server sent to all Data Centres and the IDE.DDPDCx
IDE
Does not
get routed
by the IDE

10

Data
Distribution
Plan Request
This is a request for the DDP server to send
a copy of the current DDP.
DCx
IDE
DDPDoes not
get routed
by the IDE

11

System Status messageTo enable the International LRIT Data Exchange to communicate a status message every [30] minutes to each Data Centre advising that the system is "healthy" and receive status messages from the DCs.IDEDCxYes
DCxIDE


Note:
(1) DC1 = requesting DC; DC2 = providing DC; DCx = all DCs

03.02.03 Message Handling
Ingangsdatum: 15-12-2006

3.2.3 - Message Handling

3.2.3.1 The generic process described in 3.2.3.2 shall be followed for all LRIT messages (Messages 1-11) received by the International LRIT Data Exchange. Further details on specific message types are described in subsequent sub-sections.

3.2.3.2 The International LRIT Data Exchange shall process all LRIT messages (Message types 1-8) received from the various Data Centres by:

  1. looking at the message type parameter to identify the destination LRIT Data User parameter in the message or broadcast messages;

  2. mapping the LRIT Data User ID to the Internet address of the Data Centre holding the information using the mapping information from the Data Distribution Plan, and routeing all LRIT messages to the appropriate Data Centre(s);

  3. routeing the message to all connected Data Centres in the case of broadcast messages (i.e. SAR SURPIC request message); and

  4. archiving everything in the messages except for the LRIT shipborne equipment parameters of messages 1, 2 and 3 as defined in Table 2 of the "Draft Technical Specifications for Communication within the LRIT System."

3.2.3.3 The process whereby a Contracting Government seeks LRIT positional data from its LRIT Data Centre for a ship being monitored via another LRIT Data Centre is - as an example - summarized in figure 3.

Figure 3 - Contracting government seeks LRIT positional data

03.02.04 Data Distribution Plan Interface
Ingangsdatum: 15-12-2006

3.2.4 - Data Distribution Plan Interface

3.2.4.1 The International LRIT Data Exchange shall interface with the Data Distribution Plan (DDP) and:

  1. receive updates to the DDP through Message 9 automatically, decode the received DDP and update the map of Internet addresses accordingly;

  2. initiate a request (Message 10) for a copy of the most recent DDP, when required, to the DDP server; and

  3. archive everything in the messages in the Journal(s).
03.02.05 Error Message Handling
Ingangsdatum: 15-12-2006

3.2.5 - Error Message Handling

3.2.5.1 Error messages are either:

  1. routed by the International LRIT Data Exchange upon receipt from a Data Centre (see 3.2.3); or

  2. created by the International LRIT Data Exchange when a message cannot be routed to the Receiving Data Centre due to a problem in either the Data Centre or the IDE itself. The IDE shall then transmit an error message to the requesting Data Centre indicating the message reference and error code.

03.03 Quality of Service Monitoring

3.3 - Quality of Service Monitoring
Ingangsdatum: 15-12-2006
3.3 - Quality of Service Monitoring
03.03.01 System Status Message (Message 11)
Ingangsdatum: 15-12-2006

3.3.1 - System Status Message (Message 11)

3.3.1.1 The International LRIT Data Exchange shall:

  1. send out a status message (Message 11) every 30 minutes to each Data Centre 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 Data Centres, process all System Status Messages by updating the system status (i.e. if no message from a Data Centre or the Data Distribution Plan, generate a warning to the operator), archiving everything in the messages in the Journal(s).
03.03.02 Quality Reporting
Ingangsdatum: 15-12-2006

3.3.2 - Quality Reporting

3.3.2.1 The International LRIT Data Exchange shall monitor the communication connections to all Data Centres and:

  1. respond to quality-related requests from the International LRIT Data Exchange operator and the LRIT Co-ordinator;

  2. provide to the LRIT Co-ordinator the required level of access to management, charging, technical and operational data to enable the satisfactory completion of an audit of the International LRIT Data Exchange performance; and

  3. provide sufficient information to an International LRIT Data Exchange operator for daily operation at required levels of reliability, maintenance and availability.

3.3.2.2 The archived LRIT information should provide a complete record of the activities of the International LRIT Data Exchange between two consecutive annual audits of its performance.

3.3.2.3 The International LRIT Data Exchange shall be able to measure Quality of Service as defined in resolution MSC.210(81).

04 LRIT journal(s)

4 - LRIT journal(s)

Ingangsdatum: 15-12-2006
4 - LRIT journal(s)

04.01 Purpose of the Journal(s)

4.1 - Purpose of the Journal(s)

Ingangsdatum: 15-12-2006

4.1 - Purpose of the Journal(s)

04.01.01 Overview
Ingangsdatum: 15-12-2006

4.1.1 - Overview

4.1.1.1 As per resolution MSC.210(81), sub-section 10.3.4., the International LRIT Data Exchange should automatically maintain Journal(s) containing message header information only, meaning that the LRIT shipborne equipment parameters of messages 1, 2 and 3 as defined in Table 2 of the "Draft Technical Specifications for Communication within the LRIT System, "shall not be stored.

4.1.1.2 The purpose of the Journal(s) is to enable the International LRIT Data Exchange 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 for the entity responsible for distributing the associated costs under its billing arrangements; and

  4. usage and performance statistics.

4.1.1.3 Data from the Journal(s) may be requested through the LRIT Co-ordinator by: LRIT Data Users, the auditing entity, LRIT Data Centres, approved Application Service Providers and Communications Service Providers [and the billing entity(ies)].

4.1.1.4 It should be noted that the LRIT Co-ordinator should provide an access framework describing the appropriate authorization levels.

04.01.02 Journal Contents
Ingangsdatum: 15-12-2006

4.1.2 - Journal Contents

4.1.2.1 The International LRIT Data Exchange will log all messages relating to the request for LRIT positional data 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 LRIT Data Centres;

  2. the communications with other LRIT Data Centres; and

  3. the subsequent delivery of the Response Message to the Requesting LRIT Data Centre.

4.1.2.2 In particular, the Journal(s) should include:

  1. Time Stamp of receiving a message;

  2. Time Stamp of transmitting a message; and

  3. the complete message contents except for the LRIT shipborne equipment parameters of messages 1, 2 and 3 as defined in Table 2 of the "Draft Technical Specifications for Communication within the LRIT System."

4.1.2.3 The format for the Journal is outlined in Table 2.

Table 2 - Format for journal

Parameters

Data Field

Rx (2) time stampTime (1) of receiving a message.
Not available for messages only transmitted by IDE (Messages 10, 11) and not routed.
Tx (3) time stampTime (1) of transmitting the message (routing to the
appropriate DC).
Not available for messages only received by IDE
(Messages 9, 11) and not routed.
Message contentsComplete message contents except for the LRIT shipborne equipment parameters of Messages 1, 2 and 3 (refer to 4.1.2.2.3).

Notes:
(1) All times should be indicated as Universal Co-ordinated Time (UTC).
(2) Receiving
(3) Transmitting

04.01.03 Archiving
Ingangsdatum: 15-12-2006

4.1.3 - Archiving

4.1.3.1 The International LRIT Data Exchange shall 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 Co-ordinator¿s annual report of the audit of its performance.

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

4.1.3.3 Key requirements for archiving include:

  1. redundancy -  should include hot swapping and the capability to move to an off-site centre within 1 hour;

  2. resiliency - communications shall have more than one physical path;

  3. recovery - the data can be retrieved in a convenient form;

  4. restore - the data can be restored to its original format for reprocessing; and

  5. integrity - the data is preserved in its original state.
04.01.04 Confidentiality/Security of Data
Ingangsdatum: 15-12-2006

4.1.4 - Confidentiality/Security of Data

4.1.4.1 The International LRIT Data Exchange shall only provide access to the database or Journal(s) information within the guidelines provided by the LRIT Co-ordinator. Any access or release of information shall include an audit trail of access to, modification of, or deletions made.

4.1.4.2 It should be noted that the LRIT Co-ordinator needs to provide the guidelines.

04.01.05 Reporting for Billing Purposes
Ingangsdatum: 15-12-2006

4.1.5 - Reporting for Billing Purposes

4.1.5.1 The International LRIT Data Exchange shall monitor the interfaces with all Data Centres for billing transactions and related data. All the relevant data is included in the LRIT messages and shall be stored in the Journal(s) as described in 4.1.3, above.

4.1.5.2 Further to 4.1.5.1, the International LRIT Data Exchange shall generate reports to Data Centres, the LRIT Co-ordinator and the [billing entity(ies)].

4.1.5.3 [This sub-section will be specified in detail when the billing concept of the LRIT System is agreed upon.]

4.1.5.4 [The billing entity(ies) will require additional information (e.g. communications air time, investment and operational costs) to allocate costs appropriately to LRIT Data Users.]

05 International LRIT data exchange system performance

5 - International LRIT data exchange system performance

Ingangsdatum: 15-12-2006
5 - International LRIT data exchange system performance

05.01.01 Overview of IDE System Performance

Ingangsdatum: 15-12-2006
5.1.1 - Overview of IDE System Performance

05.01.02 General

Ingangsdatum: 15-12-2006

5.1.2 - General

5.1.2.1 The International LRIT Data Exchange shall process and handle any input within 30 seconds of the receipt of the input and shall give the appropriate output.

5.1.2.2 The International LRIT Data Exchange shall be capable of receiving and processing at least 100 reports per second.

05.01.03 Availability and Reliability

Ingangsdatum: 15-12-2006

5.1.3 - Availability and Reliability

5.1.3.1 The International LRIT Data Exchange shall provide data to the LRIT system 24 hours per day 7 days per week with better than 99.9% availability measured over a year and better than 95% availability per day.

05.01.04 Maintainability

Ingangsdatum: 15-12-2006

5.1.4 - Maintainability

5.1.4.1 International LRIT Data Exchange equipment should be so designed that the main units can be replaced readily, without elaborate re-calibration or readjustment.

5.1.4.2 International LRIT Data Exchange equipment should be so constructed and installed that it is readily accessible for inspection and maintenance purposes.

Annex 02 Draft technical specifications

Annex 2 - Draft technical specifications for the International LRIT Data centre

Ingangsdatum: 15-12-2006
Annex 2 - Draft technical specifications for the International LRIT Data centre

01 General provisions

1 - General provisions

Ingangsdatum: 15-12-2006
1 - General provisions

01.01 Scope and background

1.1 - Scope and background
Ingangsdatum: 15-12-2006
1.1 - Scope and background
01.01.01 Scope
Ingangsdatum: 15-12-2006

1.1.1 - Scope

1.1.1.1 The intent of this document is to outline the technical specifications for the International LRIT Data Centre within the international Long-Range Identification and Tracking (LRIT) system as stated in the terms of reference of resolution MSC.210(81).

1.1.1.2 This document has been prepared by the Ad Hoc Working Group on Engineering Aspects of Long-Range Identification and Tracking of Ships.

1.1.1.3 In preparing the document, the Ad Hoc Working Group has taken into account the provisions of SOLAS regulation V/19-1 and resolution MSC.210(81), "Performance Standards and Functional Requirements for the Long Range Identification and Tracking of Ships."

01.01.02 Background
Ingangsdatum: 15-12-2006

1.1.2 - Background

1.1.2.1 The Maritime Safety Committee, at its eighty-first session in May 2006, adopted amendments to chapter V of the SOLAS convention in relation of LRIT. These amendments will enter into force on 1 January 2008 provided that acceptance criteria have been fulfilled by 1 July 2007.

1.1.2.2 The LRIT system provides for the global identification and tracking of ships.

1.1.2.3 In operating the LRIT system, recognition shall be given to international conventions, agreements, rules or standards that provide for the protection of navigational information.

1.1.2.4 The International LRIT Data Centre is an element of the International LRIT System that receives, stores and disseminates LRIT information on behalf of Governments. In the context of the LRIT system architecture, this document addresses the functional specifications for the International LRIT Data Centre.

1.1.2.5 The International LRIT Data Centre shall be established and recognized by the Committee.

1.1.26 The International LRIT Data Centre shall be capable of receiving and processing LRIT information from all ships, other than those that are required to transmit LRIT information to a National, Regional or Co-operative LRIT Data Centre.

1.1.2.7 The International LRIT Data Centre shall accommodate any LRIT Data User not participating in a national, Regional or Co-operative LRIT Data Centre.

01.02 General Description of the System and Definitions

1.2 - General Description of the System and Definitions
Ingangsdatum: 15-12-2006
1.2 - General Description of the System and Definitions
01.02.01 LRIT System Description
Ingangsdatum: 15-12-2006

1.2.1 - LRIT System Description

1.2.1.1 As described in resolution MSC.210(81), sub-section 1.2, 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 LRIT Data Centre(s), including any related Vessel Monitoring System(s);

  5. the LRIT Data Distribution Plan;

  6. the International LRIT Data Exchange; and

  7. LRIT Data Users.

1.2.1.2 As described in resolution MSC.210(81), sub-section 1.2, certain aspects of the performance of the LRIT system are reviewed or audited by an LRIT Co-ordinator acting on behalf of all Contracting Governments.

01.02.02 LRIT System Operation
Ingangsdatum: 15-12-2006

1.2.2 - LRIT System Operation

1.2.2.1 Subsections 1.2.2.1 to 1.2.2.11 provide a high-level overview of the LRIT system architecture. The LRIT system performance standards, resolution MSC.210(81), 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 positional data 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 resolution MSC.210(81), Table 1.

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 will travel 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, will add additional information to the LRIT message and pass along the expanded message to its associated LRIT Data Centre. 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 the "Draft Technical Specifications for Communication within the LRIT System."

1.2.2.6 LRIT Data Centres will store all incoming LRIT information from ships instructed by their Administrations to transmit LRIT information to that Data Centre. LRIT Data Centres will disseminate LRIT information to LRIT Data Users according to the Data Distribution Plan (DDP).

1.2.2.7 The LRIT Data Distribution Plan will contain the information required by the Data Centres for determining how LRIT information will be distributed to the various Contracting Governments. The DDP will contain information such as standing orders from Contracting Governments and geographical polygons relating to Contracting Governments' coastal waters and ports and port facilities.

1.2.2.8 The Data Centres will process all LRIT messages to and from the International LRIT Data Exchange (IDE). The IDE will process all LRIT messages between LRIT Data Centres. The IDE will route the message to the appropriate Data Centre based upon the information contained within the DDP. The IDE will neither process nor store the positional data contained within LRIT messages.

1.2.29 LRIT Data Users may 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.

1.2.2.10 The LRIT Co-ordinator assists in the establishment of the international components of the LRIT system, performs administrative functions, and reviews and audits certain components of the LRIT system.

1.2.2.11 Figure 1 provides an illustration of the LRIT system architecture.

Figure 1 - Typical LRIT system architecture

01.02.03 Definitions
Ingangsdatum: 15-12-2006

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 may also collect from the ships information specified by the Contracting Government(s) that has established it.

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

  11. IDC operator means the individual responsible for the daily operation and maintenance of the International LRIT Data Centre.

1.2.3.2 The term "ship," when used in the present Performance standards and functional requirements for long-range identification and tracking of ships includes mobile offshore drilling units and high-speed craft as specified in SOLAS 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.

01.02.04 Acronyms Used Within This Document
Ingangsdatum: 15-12-2006

1.2.4 - Acronyms Used Within This Document

1.2.4.1 The acronyms that appear within this document shall have the meanings assigned to them in this Article:

1ASP

Application Service Provider

 

2CSP

Communication Service Provider

 

3DC

LRIT Data Centre

 

4DDP

LRIT Data Distribution Plan

 

5IDC

International LRIT Data Centre

 

6IDE

International LRIT Data Exchange

 

7LES

Land Earth Station

 

8MMSI

Maritime Mobile Service Identity

 

9RFP

Request for Proposal

 

10SAR

Search and Rescue

 

11SAR SURPIC

Search and Rescue Surface Picture

 

12SOLAS

International Convention for the Safety of Life at Sea

 

13SSL

Secure Sockets Layer

 

14VPN

Virtual Private Network

 

15VMSVessel Monitoring System

02 Description of the International LRIT Data Centre (IDC)

2 - Description of the International LRIT Data Centre (IDC)

Ingangsdatum: 15-12-2006
2 - Description of the International LRIT Data Centre (IDC)

02.01 LRIT Data Centre Description

2.1 - LRIT Data Centre Description
Ingangsdatum: 15-12-2006
2.1 - LRIT Data Centre Description
02.01.01 System Functions
Ingangsdatum: 15-12-2006

2.1.1 - System Functions

2.1.1.1 The general functionality of the International LRIT Data Centre is addressed in resolution MSC.210(81).

02.02 LRIT Information Reporting

2.2 - LRIT Information Reporting
Ingangsdatum: 15-12-2006
2.2 - LRIT Information Reporting
02.02.01 Data Requirements
Ingangsdatum: 15-12-2006

2.2.1 - Data Requirements

2.2.1.1 Shipborne equipment shall:

  1. transmit position, identification and time, and

  2. be capable of automatically and without human intervention on board the ship transmitting the ship's LRIT information at 6-hour intervals to an LRIT Data Centre.

2.2.1.2 In addition to the provisions specified in paragraph 4.1 of MSC.210(81), shipborne equipment shall provide the functionality specified in table 1 of this document.

02.02.02 System Capacity
Ingangsdatum: 15-12-2006

2.2.2 - System Capacity

2.2.2.1 The International LRIT Data Centre shall be capable of processing data from 50,000 SOLAS Class ships. Based on the requirement for ships to transmit LRIT information four times per day, this results in 50,000 x 4 reports per day = 200,000 reports per day.

2.2.2.2 System capacity shall be sufficient to perform archival and retrieval of LRIT information as specified in resolution MSC.210(81), paragraph 7.1, for a period of at least one year.

Table 1 - Data to be transmitted from the shipborne equipment

ParameterComments

Shipborne equipment Identifier

 

The identifier used by the shipborne equipment.
Positional data

The GNSS position (latitude and longitude) of the ship (based on the WGS 84 datum).

Position: The equipment should be capable of transmitting the GNSS position (latitude and longitude) of the ship (based on WGS 84 datum) as prescribed by SOLAS regulation V/19-1, without human interaction on board the ship.

On-demand (1) position reports: The equipment should be capable of responding to a request to transmit LRIT information on demand without human interaction onboard the ship, irrespective of where the ship is located.

Pre-scheduled (2) position reports: The equipment should be capable of being remotely configured to transmit LRIT information at intervals ranging from a minimum of 15 minutes to periods of 6 hours to the LRIT Data Centre, irrespective of where the ship is located and without human interaction on board the ship.

 

Time Stamp 1The date and time (3) associated with the GNSS position. The equipment should be capable of transmitting the time (3) associated with the GNSS position with each transmission of LRIT information.


Notes:
(1)On-demand position reports means transmission of LRIT information as a result of either receipt of polling command or of remote configuration of the equipment so as to transmit at intervals other than the preset ones.
(2)Pre-scheduled position reports means transmission of LRIT information at the preset transmit intervals.
(3)All times should be indicated as Universal Co-ordinated Time (UTC).

03 System Architecture / High Level Design

3 - System Architecture / High Level Design

Ingangsdatum: 15-12-2006
3 - System Architecture / High Level Design

03.01 High level overview of system architecture

3.1 - High level overview of system architecture
Ingangsdatum: 15-12-2006
3.1 - High level overview of system architecture
03.01.01 General
Ingangsdatum: 15-12-2006

3.1.1 - General
3.1.1.1
This section provides a high-level overview of the system architecture. The flow of data is captured in Figure 2.

 
Note:(1) REQ = Request; FS = Flag State; PS= Port State; CS = Coastal State

03.02 Functional Requirements

3.2 - Functional Requirements
Ingangsdatum: 15-12-2006
3.2 - Functional Requirements
03.02.01 General
Ingangsdatum: 15-12-2006

3.2.1 - General

3.2.1.1 The International LRIT Data Centre shall receive, store and disseminate LRIT information. MSC.1/Circ.1219

3.2.1.2 The International LRIT Data Centre shall perform the requirements outlined in section 3.2 of this document.

3.2.1.3 The International LRIT Data Centre shall:

  1. verify communications and provide for data security using methods such as uthorization; authentication; confidentiality; integrity and as specified in the Draft Technical Specifications for Communication in the LRIT System";

  2. maintain a record of the ships that transmit LRIT information to the International RIT Data Centre including name of ship, IMO Ship Identification Number, Call Sign and Maritime Mobile Service Identity (MMSI), and current reporting intervals (as requested by the various LRIT Data Users); and

  3. maintain a current list of ships no longer transmitting data to the International LRIT Data Centre (e.g. change of flag, taken out of service).

3.2.1.4 The International LRIT Data Centre shall amend the information above upon the transfer of a flag of a ship to include the following:

  1. the effective date and time (UTC) of the transfer; and

  2. the Administration whose flag the ship was formally entitled to fly, if known.

3.2.1.5 The International LRIT Data Centre shall ensure, using appropriate hardware and software, that LRIT information is:

  1. backed-up at regular intervals;

  2. stored at suitable off-site location(s); and

  3. available as soon as possible in the event of disruption to ensure continuity of service.

3.2.1.6 The International LRIT Data Centre shall maintain a list of ASPs connected to the Data Centre.

03.02.02 ASP Interface Function
Ingangsdatum: 15-12-2006

3.2.2 - ASP Interface Function

3.2.2.1 The International LRIT Data Centre shall process the incoming LRIT information from the ASP, and route polling.

3.2.2.2 Further to 3.2.2.1, the International LRIT Data Centre shall:

  1. receive LRIT information from ships instructed by their Administrations to transmit the LRIT information to the International LRIT Data Centre;

  2. add the appropriate data identified in table 2 of this document to each transmission of LRIT information collected by the International LRIT Data Centre; and

  3. execute requests received from LRIT Data Users for polling of LRIT information or for change(s) in the interval(s) of transmission of LRIT information by a ship or a group of ships transmitting the information to the International LRIT Data Centre.
03.02.03 LRIT Information Storage and Handling Function
Ingangsdatum: 15-12-2006

3.2.3 - LRIT Information Storage and Handling Function

3.2.3.1 The International LRIT Data Centre shall be audited by the LRIT Co-ordinator.

3.2.3.2 The International LRIT Data Centre shall archive LRIT information from ships that transmit the information to the IDC, for at least one year and until such time as the Committee reviews and accepts the annual report of the audit of its performance by the LRIT Co-ordinator.

3.2.3.3 Further to the above, the International LRIT Data Centre shall perform database storage and retrieval in accordance with the following schedule:

  1. for LRIT information archived within the last 4 days, sends the LRIT information within 30 minutes of receiving a request;

  2. for LRIT information archived between 4 and 30 days (including 30th day) previously, sends the LRIT information within 1 hour of receiving a request; and

  3. for LRIT information archived more than 30 days previously, sends the LRIT information within 5 days of receiving a request.
03.02.04 IDC LRIT Data User Function
Ingangsdatum: 15-12-2006

3.2.4 - IDC LRIT Data User Function

3.2.4.1 The International LRIT Data Centre shall process polling, requests, and standing orders directly from Contracting Governments whose ships are reporting to the International LRIT Data Centre.

3.2.4.2 Further to 3.2.4.1, the International LRIT Data Centre shall:

  1. perform authentication based on the LRIT Data Distribution Plan;

  2. establish and continuously maintain systems that ensure, at all times, that LRIT Data Users are only provided with the LRIT information they are entitled to receive as specified in SOLAS regulation V/19-1;

  3. when requested, disseminate to Contracting Governments the LRIT information they are entitled to receive in accordance with the agreed arrangements and notify the LRIT Data User and the Administration when a particular ship stops transmitting LRIT information; and

  4. prohibit the dissemination of LRIT information to Contracting Governments in accordance with SOLAS regulation V/19-1.9.1 and as provided in the LRIT Data Distribution Plan.

3.2.4.3 The International LRIT Data Centre shall provide to Search and Rescue (SAR) services, LRIT information transmitted by all ships located within the geographic area specified by the SAR service requesting the information so as to permit the rapid identification of ships that may be called upon to provide assistance in relation to the search and rescue of persons in distress at sea.

3.2.4.4 The LRIT information referenced in 3.2.4.3 shall be provided:

  1. irrespective of the location of the geographic area; and

  2. even if the geographic area is outside the SAR region associated with the SAR service requesting the information (SOLAS regulation V/19-1.12 refers).
03.02.05 IDE Interface Function
Ingangsdatum: 15-12-2006

3.2.5 - IDE Interface Function

3.2.5.1 The International LRIT Data Centre shall:

  1. respond to all queries from all other Data Centres through the International LRIT Data Exchange;

  2. communicate with LRIT Data Centres through the International LRIT Data Exchange in accordance with the "Draft Technical Specifications for the International LRIT Data Exchange," and the "Draft Technical Specifications for Communications within the LRIT System;

  3. perform authentication based on the LRIT Data Distribution Plan;

  4. establish and continuously maintain systems that ensure, at all times, that Contracting Governments are only provided with the LRIT information they are entitled to receive as specified in SOLAS regulation V/19-1;

  5. obtain, when requested, LRIT information transmitted by ships other than those that transmit information to the International LRIT Data Centre, LRIT information from other LRIT Data Centres through the International LRIT Data Exchange;

  6. make available, when requested by one of its LRIT Data Users to provide LRIT information transmitted by ships other than those associated with the International LRIT Data Centre, LRIT information transmitted to the International LRIT Data Centre from other LRIT Data Centres through the International LRIT Data Exchange;

  7. relay, when required, requests received from LRIT Data Users through the International LRIT Data Exchange to the other LRIT Data Centres for polling of LRIT information or for change(s) in the interval(s) of transmission of LRIT information by a ship or a group of ships not transmitting the information to the International LRIT Data Centre;

  8. upon request, disseminate to LRIT Data Users the LRIT information they are entitled to receive in accordance with the agreed arrangements and notify the LRIT Data User and the Administration when a particular ship stops transmitting LRIT information;

  9. prohibit the dissemination of LRIT information to Contracting Governments in accordance with SOLAS regulation V/19-1.9.1 and as provided in the LRIT Data Distribution Plan; and

  10. provide to Search and Rescue (SAR) services, LRIT information transmitted by all ships located within the geographic area specified by the SAR service requesting the information so as to permit the rapid identification of ships that may be called upon to provide assistance in relation to the search and rescue of persons in distress at sea. The LRIT information shall be provided irrespective of the location of the geographic area and shall be provided even if the geographic area is outside the SAR region associated with the SAR service requesting the information (SOLAS regulation V/19-1.12 refers).
03.02.06 Quality of Service Monitoring Function
Ingangsdatum: 15-12-2006

3.2.6 - Quality of Service Monitoring Function

3.2.6.1 The International LRIT Data Centre shall monitor the ASP, IDC, and IDE interfaces.

3.2.6.2 Further to 3.2.6.1 the International LRIT Data Centre shall:

  1. respond to quality-related requests from the IDC operator and the LRIT Co-ordinator;

  2. provide to the LRIT Co-ordinator the required level of access to management, charging, technical and operational data to enable the satisfactory completion of an audit of the IDC performance; and

  3. provide sufficient information to an IDC operator for daily operation at required levels of reliability, maintenance and availability.

3.2.6.3 The archived LRIT information should provide a complete record of the activities of the International LRIT Data Centre between two consecutive annual audits of its performance.

3.2.6.4 The International LRIT Data Centre shall be able to measure Quality of Service as defined in resolution MSC.210(81).

3.2.6.5 The International LRIT Data Centre will send a System Status Message to the International LRIT Data Exchange every 30 minutes.

03.02.07 Billing Handling Function
Ingangsdatum: 15-12-2006

3.2.7 - Billing Handling Function

3.2.7.1 The International LRIT Data Centre shall monitor the ASP, IDC, and IDE interfaces for billing transactions and related data.

3.2.7.2 Further to 3.2.7.1, the International LRIT Data Centre shall:

  1. ensure relevant data are processed; and

  2. generate reports to the International LRIT Data Exchange and invoices to Contracting Governments.

3.2.7.3 [This subsection will be specified in detail when the billing concept of the international LRIT system is agreed upon].

03.03 International LRIT Data Centre System Performance

3.3 - International LRIT Data Centre System Performance
Ingangsdatum: 15-12-2006
3.3 - International LRIT Data Centre System Performance
03.03.01 General
Ingangsdatum: 15-12-2006

3.3.1 - General

3.3.1.1 The International LRIT Data Centre shall process and handle any input within 60 seconds of the receipt of the input and shall give the appropriate output. This output may be a direct response to the request or it may be a request for information from another part of the LRIT system. This shall include validation of requests in accordance with the Data Distribution Plan, if necessary.

3.3.1.2 The International LRIT Data Centre shall be capable of receiving and storing at least 5 reports per second.

03.03.02 Availability and Reliability
Ingangsdatum: 15-12-2006

3.3.2 - Availability and Reliability

3.3.2.1 The International LRIT Data Centre shall provide data to the LRIT system 24 hours per day 7 days per week with better than 99.9% availability measured over a year and better than 95% availability per day.

03.03.03 Maintainability
Ingangsdatum: 15-12-2006

3.3.3 - Maintainability

3.3.3.1 International LRIT Data Centre equipment should be so designed that the main units can be replaced readily, without elaborate recalibration or readjustment.

3.3.3.2 International LRIT Data Centre equipment should be so constructed and installed that it is readily accessible for inspection and maintenance purposes.

03.04 IDC External Interfaces

3.4 - IDC External Interfaces
Ingangsdatum: 15-12-2006
3.4 - IDC External Interfaces
03.04.01 Application Service Providers Interface
Ingangsdatum: 15-12-2006

3.4.1 - Application Service Providers Interface

3.4.1.1 The International LRIT Data Centre shall interact with Communication Service Providers through a communications protocol provided by an Application Service Provider to enable the following minimum functionality:

  1. remote integration of the shipborne equipment into the International LRIT Data Centre;

  2. automatic configuration of transmission of LRIT information;

  3. automatic modification of the interval of transmission of LRIT information;

  4. automatic suspension of transmission of LRIT information;

  5. on demand transmission of LRIT information; and

  6. automatic recovery and management of transmission of LRIT information.

3.4.1.2 The International LRIT Data Centre shall:

  1. provide an integrated transaction management system for the monitoring of LRIT information throughput and routeing; and

  2. ensure that LRIT information is collected, stored and routed in a reliable and secure manner.

3.4.1.3 The International LRIT Data Centre shall be capable of receiving and processing the data in table 2, below, added by an ASP (where used) to each transmission of LRIT information.

Table 2 - Data to be added by an application service provider and at the LRIT data centre

ParametersComments
Ship Identity (1)The IMO ship identification number (1) and MMSI for the ship. (Ship name optional.)
Time Stamp 2The date and time (2) the position report is received by the ASP (if used).
Time Stamp 3The date and time (2) the position report is forwarded from the ASP (if used) to the appropriate LRIT Data Centre.
LRIT Data Centre IdentifierThe identity of the LRIT Data Centre to be clearly indicated by a Unique Identifier.
Time Stamp 4The date and time (2) the position report is received by the LRIT Data Centre.
Time Stamp 5The date and time (2) the position report is forwarded from the LRIT Data Centre to an LRIT Data User.
 

Notes:
(1) See SOLAS regulation XI-1/3 and resolution A.600(15) on IMO ship identification number scheme.
(2) All times should be indicated as Universal Co-ordinated Time (UTC).

03.04.02 LRIT Data User Interface
Ingangsdatum: 15-12-2006

3.4.2 - LRIT Data User Interface

3.4.2.1 The interface between LRIT Data Users and the International LRIT Data Centre shall be a national IDC application interface.

3.4.2.2 The LRIT Data User is responsible for obtaining the application interface that will communicate with the IDC using the protocols defined in the "Draft Technical Specifications for Communications in the LRIT System."

3.4.2.3 The LRIT Data User must comply with all layers of the communication protocol defined within the "Draft Technical Specifications for Communications in the LRIT System."

03.04.03 Interface With The International LRIT Data Exchange
Ingangsdatum: 15-12-2006

3.4.3 - Interface With The International LRIT Data Exchange

3.4.3.1 The International LRIT Data Centre shall interface with the International LRIT Data Exchange.

3.4.3.2 The International LRIT Data Centre shall send a System Status message to the International LRIT Data Exchange every 30 minutes.

03.04.04 Interface With The Data Distribution Plan
Ingangsdatum: 15-12-2006

3.4.4 - Interface With The Data Distribution Plan

3.4.4.1 The International LRIT Data Centre shall interface with the Data Distribution Plan and receive updates to the Data Distribution Plan automatically.

3.4.4.2 A request for a copy of the most recent Data Distribution Plan can be initiated by the International LRIT Data Centre when required.

03.05 LRIT Co-ordinator

3.5 - LRIT Co-ordinator
Ingangsdatum: 15-12-2006
3.5 - LRIT Co-ordinator
03.05.01 General
Ingangsdatum: 15-12-2006

3.5.1 - General

3.5.1.1 As required by the LRIT Co-ordinator, the International LRIT Data Centre shall:

  1. co-operate and make available to the LRIT Co-ordinator the information required to enable the satisfactory completion of an audit of its performance;

  2. grant access to the LRIT Co-ordinator for management, charging, technical and operational data as applicable by the International LRIT Data Centre; and

  3. send compiled IDC statistics, error reports, and other required information to the LRIT Co-ordinator
03.06.01 Description Language
Ingangsdatum: 15-12-2006

3.6.1 - Description Language

3.6.1.1 The detailed description of the International LRIT Data Centre can include a set of SDL (Specification and Description Language) diagrams or other suitable Event-Based Architecture Description Language intended for complex software systems.

03.06 Proposal for Further Specification of the IDC

Ingangsdatum: 15-12-2006
3.6 - Proposal for Further Specification of the IDC

04 User Cases

4 - User Cases

Ingangsdatum: 15-12-2006
4 - User Cases

04.01 Overview of Contracting Government User Cases

4.1 - Overview of Contracting Government User Cases
Ingangsdatum: 15-12-2006
4.1 - Overview of Contracting Government User Cases
04.01.01 General
Ingangsdatum: 15-12-2006

4.1.1 - General

4.1.1.1 A Contracting Government, from a flag, port, or coastal state perspective, may receive LRIT information pursuant to the provisions of SOLAS regulation V/19-1 (resolution MSC.202(81)). Specifically, reference should be made to:

  1. section 8.1.1 for flag State entitlement;

  2. section 8.1.2 for port State entitlement; and

  3. section 8.1.3 for coastal State entitlements.

4.1.1.2 A Contracting Government, from a Search and Rescue perspective, may receive LRIT information pursuant to the provisions of SOLAS regulation V/19-1 (resolution MSC.202(81)), section 12.

4.1.1.3 The basic performance standards and functional requirements related to 4.1.1.1 and 4.1.1.2 are as stated in resolution MSC.202(81).

4.1.1.4 References in part 4 of this document to a Contracting Government communicating with its Data Centre are prescriptive when the Data Centre is the International LRIT Data Centre, and descriptive when it is any other Data Centre (i.e. National or Regional/Co-operative).

4.1.1.5 References in part 4 of this document to communications between Data Centres, the IDE and the DDP are prescriptive.

04.02 Flag Request

4.2 - Flag Request

Ingangsdatum: 15-12-2006

4.2 - Flag Request

04.02.01 General
Ingangsdatum: 15-12-2006

4.2.1 - General

4.2.1.1 A Contracting Government that wishes to receive LRIT information on one of its registered ships can either:

  1. send a request message to the Data Centre to which it is connected; or

  2. submit standing orders regarding the criteria for receiving LRIT information to the LRIT Data Centre to which it is connected, which are included in the Data Distribution Plan.

4.2.1.2 The standing order information should include the ship name, IMO ship identification number and reporting rate.

4.2.1.3 The Contracting Government may use LRIT request messages to start tracking, stop tracking or alter the reporting rate of the LRIT information.

04.03 Port State Access to LRIT Information

4.3 - Port State Access to LRIT Information
Ingangsdatum: 15-12-2006
4.3 - Port State Access to LRIT Information
04.03.01 General
Ingangsdatum: 15-12-2006

4.3.1 - General

4.3.1.1 A Port State request is always triggered by a Notice of Arrival.

4.3.1.2 A Contracting Government that wishes to receive LRIT information as a port State can send either:

  1. a request message including all applicable port state parameters; or

  2. a request message referring the Receiving Data Centre to the standing orders applicable to that Port State contained within the Data Distribution Plan.

4.3.1.3 The standing order criteria may include a combination of: ship name, IMO ship identification number, flag, reporting rate, and the distance from the Contracting Government¿s port or the distance from the coastline, or a point in time (null values will provide flexibility).

4.3.1.4 If the Contracting Government wishes to stop receiving LRIT information, it must actively send a request message to the ship¿s Data Centre instructing the Data Centre to stop sending reports. This can also be done automatically if it is correctly entered into the Data Distribution Plan.

04.03.02 Example: Port State Request With Port Parameters
Ingangsdatum: 15-12-2006

4.3.2 - Example: Port State Request With Port Parameters

4.3.2.1 Ship A approaching port State X without Standing Order makes a request message (including all applicable port state parameters).

NOA lists the flag associated with ship A. DC X of port State X sends the Position Request message to the IDE, identifying Receiving LRIT Data User A (in this case Contracting Government) associated with ship A.

The IDE maps LRIT Data User A to its DC (in this case DC A), and routes the request to Receiving DC A.

DC A starts to transmit LRIT position reports based upon the specified criteria contained in the port State perimeters as requested to the IDE, addressing the Receiving LRIT Data User (Data User X).

IDE maps Data User X to DC X and routes the message to DC X, storing Journal data.

DC X forwards information to LRIT Data User X.

04.03.03 Example: Port State Request Referring to a Standing Order
Ingangsdatum: 15-12-2006

4.3.3 - Example: Port State Request Referring to a Standing Order

4.3.3.1 Ship A approaching port State X and sending NOA to port authority.

NOA lists the flag associated with ship A. DC X of port State X sends the Position Request message to the IDE, identifying Receiving LRIT Data User A (in this case Contracting Government) associated with ship A.

The IDE maps LRIT Data User A to its DC (in this case DC A), and routes the request to Receiving DC A.

DC A checks the DDP and extracts the applicable information from the Standing Orders in the DDP.

DC A starts to transmit LRIT position reports as requested to the IDE, addressing the Receiving LRIT Data User (Data User X).

IDE maps Data User X to DC X and routes the message to DC X, storing Journal data.

DC X forwards information to LRIT Data User X.

04.04 Coastal State Access to LRIT Information

4.4 - Coastal State Access to LRIT Information
Ingangsdatum: 15-12-2006
4.4 - Coastal State Access to LRIT Information
04.04.01 General
Ingangsdatum: 15-12-2006

4.4.1 - General

4.4.1.1 A Contracting Government that wishes to receive LRIT information as a coastal State must submit standing orders regarding the criteria for receiving LRIT information, which are included in the Data Distribution Plan.

4.4.1.2 The standing order criteria should include: the distance from its coast within which the Contracting Government wishes to track ships, reporting rate and, optionally, the flag of ships it does not (or does) wish to track. Thus, Data Centres will be capable of filtering LRIT data reports based upon a ship¿s distance from the Contracting Government's coast as well as the flag of the ship.

4.4.1.3 All Data Centres will check the incoming LRIT position reports of their registered ships against the standing orders and geographical boundaries contained in the Data Distribution Plan. Once the Data Centre has discovered a match, it will begin transmitting LRIT information to the entitled Contracting Government.

4.4.1.4 If the Contracting Government wishes to stop receiving LRIT information, it must either:

  1. actively send a request message to the ship's Data Centre instructing the Data Centre to stop sending reports for this transit through the coastal state area; or

  2. within the Data Distribution Plan only request that the first regular position message inside the coastal State area be transmitted to the Contracting Government.
04.04.02 Example: Coastal State Request
Ingangsdatum: 15-12-2006

4.4.2 - Example: Coastal State Request

4.4.2.1 Ship A approaching coastal waters of LRIT Data User X (entering area that is included in the DDP requesting scheduled transmissions).

DC A (to which ship A belongs) checks the DDP to verify that ship A entered the area covered by the adopted standing orders related to LRIT Data User X in the DDP.

DC A starts to transmit LRIT position reports as requested to the IDE, addressing the Receiving LRIT Data User X.

IDE maps Data User X to DC X and routes the message to DC X and stores Journal data.

DC X forwards information to LRIT Data User X.

04.05 SAR Request

4.5 - SAR Request
Ingangsdatum: 15-12-2006
4.5 - SAR Request
04.05.01 General
Ingangsdatum: 15-12-2006

4.5.1 - General

4.5.1.1 A Contracting Government that wishes to receive LRIT information as a SAR entity can use either a SAR SURPIC Request Message or a Poll Request Message to obtain information.

4.5.1.2 A SAR SURPIC is typically used in the first stage of responding to a SAR incident. The SAR SURPIC will provide the SAR authority with the ships within a requested vicinity.

4.5.1.3 The SAR SURPIC message will be sent to the International LRIT Data Exchange by the Data Centre associated with the SAR Authority. The IDE will broadcast the message to all Data Centres. Only Data Centres with a ship or ships with the specified SURPIC will respond to the SAR SURPIC message.

4.5.1.4 SAR Authorities may use a SAR poll request message to retrieve additional positional data on ships in the vicinity of a SAR incident.

04.05.02 Example: SAR Request
Ingangsdatum: 15-12-2006

4.5.2 - Example: SAR Request

4.5.2.1 As per SOLAS regulation V/19.1 paragraph 12: Ship B in distress falling under the responsibility of an RCC of State X.

RCC wants to check for ships in vicinity.

DC X associated to RCC X sends the SAR SURPIC Request message to the IDE.

IDE broadcasts this request to all DCs.

Every DC checks its database to determine whether an associated ship is within radius of incident.

If yes, DC responds with SAR position reports as requested with LRIT Data User X as the destination address.

If no, DC sends a receipt message indicating "no ships in radius."

IDE maps Data User X to DC X and routes the received messages from one or multiple DC's to Requesting DC X.

DC X forwards information to LRIT Data User X.

RCC decides to track one (or more) ship A in SAR radius at higher rate.

DC X associated to with RCC X sends the SAR Polling Request message addressed to ship A with destination LRIT Data User A to the IDE.

IDE maps LRIT Data User A to DC A and routes the message to DC A.

DC A starts to transmit SAR position reports as requested to IDE addressing the receiving LRIT Data User X.

IDE maps LRIT Data User X to DC X and routes the message to DC X.

DC X forwards information to LRIT Data User X.

Annex 03 Technical specifications for communication in the LRIT system

Annex 3 - Technical specifications for communication in the LRIT system

Ingangsdatum: 15-12-2006
Annex 3 - Technical specifications for communication in the LRIT system

01 General provisions

1 - General Provisions

Ingangsdatum: 15-12-2006
1 - General Provisions

01.01 Scope and Background

1.1 - Scope and Background
Ingangsdatum: 15-12-2006
1.1 - Scope and Background
01.01.01 Scope
Ingangsdatum: 15-12-2006

1.1.1 - Scope

1.1.1.1 The intent of this document is to outline the technical specifications for communication within the international Long-Range Identification and Tracking (LRIT) system as stated in the terms of reference of resolution MSC.210(81).

1.1.1.2 This document has been prepared by the Ad Hoc Working Group on Engineering Aspects of Long-Range Identification and Tracking of Ships.

1.1.1.3 In preparing the document, the Ad Hoc Working Group has taken into account the provisions of SOLAS regulation V/19-1 and resolution MSC.210(81), "Performance Standards and Functional Requirements for the Long Range Identification and Tracking of Ships."

01.01.02 Background
Ingangsdatum: 15-12-2006

1.1.2 - Background

1.1.2.1 The Maritime Safety Committee, at its eighty-first session in May 2006, adopted amendments to chapter V of the SOLAS convention in relation of LRIT. These amendments will come into force on 1 January 2008 provided that acceptance criteria have been fulfilled by 1 July 2007.

1.1.2.2 The LRIT system provides for the global identification and tracking of ships.

1.1.2.3 In operating the LRIT system, recognition shall be given to international conventions, agreements, rules or standards that provide for the protection of navigational information.

1.1.2.4 Communication specifications within the international LRIT system will 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.1.2.5 The draft specifications for Communications for the International LRIT system as outlined in this document will be established and recognized by the Committee.

01.02 General Description of the System and Definitions

1.2 - General Description of the System and Definitions
Ingangsdatum: 15-12-2006
1.2 - General Description of the System and Definitions
01.02.01 LRIT System Description
Ingangsdatum: 15-12-2006

1.2.1 - LRIT System Description

1.2.1.1 As described in resolution MSC.210(81), sub-section 1.2, 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 LRIT Data Centre(s), including any related Vessel Monitoring System(s);

  5. the LRIT Data Distribution Plan;

  6. the International LRIT Data Exchange; and

  7. LRIT Data Users.

1.2.1.2 As described in resolution MSC.210(81), sub-section 1.2, certain aspects of the performance of the LRIT system are reviewed or audited by an LRIT Co-ordinator acting on behalf of all Contracting Governments.

01.02.02 LRIT System Operation
Ingangsdatum: 15-12-2006

1.2.2 - LRIT System Operation

1.2.2.1 Subsections 1.2.2.1 to1.2.2.11 provide a high-level overview of the LRIT system architecture. The LRIT system performance standards, resolution MSC.210(81), 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 positional data 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 resolution MSC.210(81), Table 1.

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 will travel 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, will add additional information to the LRIT message and pass along the expanded message to its associated LRIT Data Centre. 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 this document .

1.2.2.6 LRIT Data Centres will store all incoming LRIT information from ships instructed by their Administrations to transmit LRIT information to that Data Centre. LRIT Data Centres will disseminate LRIT information to LRIT Data Users according to the Data Distribution Plan (DDP).

1.2.2.7 The LRIT Data Distribution Plan will contain the information required by the Data Centres for determining how LRIT information will be distributed to the various Contracting Governments. The DDP will contain information such as standing orders from Contracting Governments and geographical polygons relating to Contracting Governments' coastal waters and ports and port facilities.

1.2.2.8 The Data Centres will process all LRIT messages to and from the International LRIT Data Exchange (IDE). The IDE will process all LRIT messages between LRIT Data Centres. The IDE will route the message to the appropriate Data Centre based upon the information contained within the DDP. The IDE will neither process nor store the positional data contained within LRIT messages.

1.2.2.9 LRIT Data Users may be entitled to receive or request LRIT information in their capacity as a flag State, port State, coastal State or Search and Rescue (SAR) services.

1.2.2.10 The LRIT Co-ordinator assists in the establishment of the international components of the LRIT system, performs administrative functions, and reviews and audits certain components of the LRIT system.

1.2.2.11 Figure 1 provides an illustration of the LRIT system architecture.

Figure 1 - Typical LRIT system architecture

 

01.02.03 Definitions
Ingangsdatum: 15-12-2006

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 may also collect from the ships information specified by the Contracting Government(s) that has established it.

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

  11. IDC operator means the individual responsible for the daily operation and maintenance of the International LRIT Data Centre.

1.2.3.2 The term "ship," when used in the present Performance standards and functional requirements for long-range identification and tracking of ships, includes mobile offshore drilling units and high-speed craft as specified in SOLAS 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.

01.02.04 Acronyms
Ingangsdatum: 15-12-2006

1.2.4 - Acronyms

1.2.4.1 The acronyms that appear within this document shall have the meanings assigned to them in this Article:

1ASP

Application Service Provider

 

2CSP

Communication Service Provider

 

3DCLRIT

Data Centre

 

4DDP

LRIT Data Distribution Plan

 

5IDC

International LRIT Data Centre

 

6IDE

International LRIT Data Exchange

 

7LES

Land Earth Station

 

8MMSI

Maritime Mobile Service Identity

 

9RFP

Request for Proposal

 

10SAR

Search and Rescue

 

11SAR SURPIC

Search and Rescue Surface Picture

 

12SOLAS

International Convention for the Safety of Life at Sea

 

13SSL

Secure Sockets Layer

 

14VPN

Virtual Private Network

 

15VMSVessel Monitoring System

 

02 Communications within the LRIT System

2 - Communications within the LRIT System

Ingangsdatum: 15-12-2006
2 - Communications within the LRIT System

02.01 Overview and Message Types

2.1 - Overview and Message Types
Ingangsdatum: 15-12-2006
2.1 - Overview and Message Types
02.01.01 Overview
Ingangsdatum: 15-12-2006

2.1.1 - Overview

2.1.1.1 Communication within the LRIT system is described in Parts 2 to 5 of this document.

02.01.02 Message Types
Ingangsdatum: 15-12-2006

2.1.2 - Message Types

2.1.2.1 Communication within the LRIT system is based upon three types of messages flowing between the various LRIT system components: LRIT request messages; LRIT positional data messages; and other ancillary, system messages.

2.1.2.2 Request messages are those requesting specific LRIT information.

2.1.2.3 Positional data messages are those containing LRIT ship positional data.

2.1.2.4 Other messages managed by the system include: error messages; receipt messages; Data Distribution Plan update messages; Data Distribution Plan request messages; and System Status messages.

2.1.2.5 Parts 2 to 5 of this document outline 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 system component referenced in 1.2.1.1 will have its own unique identifier that will enable other components within the LRIT network to identify that particular component.

2.1.2.7 Figure 2 illustrates the LRIT system components as well as the various communications segments (A to E) in the LRIT network.

 

Figure 2 - LRIT Communications segments

02.02 LRIT Messaging Format Summary

2.2 - LRIT Messaging Format Summary
Ingangsdatum: 15-12-2006
2.2 - LRIT Messaging Format Summary
02.02.01 Summary of LRIT Messages
Ingangsdatum: 15-12-2006

2.2.1 - Summary of LRIT Messages

2.2.1.1 Table 1 provides a summary of all LRIT messages.

Table 1 - Summary of LRIT Messages

Message
Type

Message Name

Message Description

LRIT Positional Data (position report) Messages
1Periodic Position ReportRegular periodic ship position report.
2Polled Position ReportShip position report as a result of a poll request.
3SAR Position ReportShip position report as a result of a SAR request.
LRIT Request Messages
4Ship Position RequestRequest for polled ship position report.
5SAR Poll RequestSAR request for poll of specific ship¿s position.
6SAR SURPIC RequestSAR request for poll of ships in specific area.
Other Messages
7ErrorError message relating to an inability to process a LRIT request message.
8ReceiptReceipt message relaying ability to process a LRIT request or report message (e.g. Time Stamp).
9Data Distribution Plan UpdateInformation used to update the Data Distribution Plan.
10Data Distribution Plan RequestRequest for current copy of the Data Distribution Plan.
11System StatusRoutine 30 minute status message from the International LRIT Data Exchange to each Data Centre, advising that the system is "healthy."


2.2.1.2 Sections 2.2.2 to 2.2.9 describe each of the LRIT messages. Each messages is presented in tabular format with the following columns:

  1. the "Parameter Added By" column indicates the particular LRIT component that inserts the parameter into the LRIT message;

  2. the "Parameter" column lists the various parameter names contained within the LRIT message;

  3. the "Values" column lists the potential values of each associated parameter;

  4. the "Description" column provides brief information pertaining to each of the various parameters in the LRIT message; and

  5. the "LRIT Segments" column indicates which of the LRIT communications segments of Figure 2 contain each parameter.
02.02.02 LRIT Ship Position Reports (Messages 1, 2 and 3)
Ingangsdatum: 15-12-2006

2.2.2 - LRIT Ship Position Reports (Messages 1, 2 and 3)

2.2.2.1 Table 2 outlines the parameters associated with the positional data messages (ship position reports).

2.2.2.2 The parameters added by the LRIT shipborne equipment include the latitude, longitude, Time Stamp when the position was generated, and the shipborne equipment identifier.

2.2.2.3 The parameter "ASP ID#" table 2 provides the unique LRIT component ID of the ASP that has received the LRIT positional data.

2.2.2.4 The "Message type" parameter in table 2 indicates the type of message of the associated LRIT message. The LRIT components such as the LRIT Data Centres can use this parameter to distinguish between the various LRIT messages listed in table 1.

2.2.2.5 The "Message ID#" parameter in table 2 is a unique identification number that LRIT components can use to identify individual messages within the LRIT network. The Message ID# is generated by using a concatenation of the following parameters: message type, IMO #, ASP ID# and Time Stamp. All these parameters are necessary in order to generate a unique ID number.

2.2.2.6 The "Reference ID#" parameter in table 2 will either be a message ID of an associated request message or a 0 value. The 0 value is populated if the message is not the result of a request message whereas a valid "Message ID" value indicates that a request message has initiated the LRIT positional data report.

2.2.2.7 The "IMO#" and "MMSI#" parameters in table 2 are the IMO ship identification number and Maritime Mobile Service Identity (MMSI) number of the ship being tracked respectively.

2.2.2.8 The "Time Stamp 2" and "Time Stamp 3" parameters in table 2 represent the date and time associated with when the ASP received and transmitted the positional data message.

2.2.2.9 The "Other" parameter is reserved for future parameters.

2.2.2.10 The parameter "DC ID#" in table 2 provides the unique LRIT component ID of the Data Centre receiving the LRIT positional data.

2.2.2.11 The "Time Stamp 4" and "Time Stamp 5" parameters in table 2 represent the date and time associated with when the Data Centre received and transmitted the positional data message.

2.2.2.12 The "Response type" parameter in table 2 provides information on why the designated LRIT Data User (Requestor) is receiving the LRIT positional data. The LRIT Data User will be entitled to receive the LRIT positional data report based upon functioning as: a flag State; a port State; a coastal State; or a SAR service.

2.2.2.13 The "LRIT Data User (Requestor)" parameter in table 2 represents the LRIT Data User that is originating the request message.

2.2.2.14 The "Ship Name" parameter in table 2 represents the ship name.

2.2.2.15 The "LRIT Data User (Provider)" parameter in table 2 is a unique identification number associated with the Contracting Government to which the ship is registered. This parameter is used to identify the destination of the request message. The International LRIT Data Exchange will look at this parameter during processing of the request message and use it to correctly route the message to the appropriate Data Centre(s).

2.2.2.16 If responding to a SAR request, the response type would be SAR; if responding to a port request, the response type would be Port; if responding to a coastal request, the response type would be Coastal; if responding to a flag request, the response type would be Flag.

 

Table 2 - LRIT positional data (position report) messages

Parameter
Added By

Parameter

Values

Description

LRIT
Segments

 

LRIT
Shipborne
equipment

LatitudeLatLatitude position of the ship.A, B, C, D
LongitudeLongLongitude position of the ship.A, B, C, D
Time Stamp 1Time1Date and time when position was taken.A, B, C, D
Shipborne equipment identifierEquip#Unique LRIT shipborne equipment (terminal) number used for communication.A, B, C, D

 

 

LRIT ASP

ASP ID#ASP#LRIT ASP unique identification number.
All Data Centres must ensure that all of their ASPs have a unique number.
B, C, D
Message type1, 2, 3Message identification number:
1 - Periodic Report
2 - Polled Report
3 - SAR Report
B, C, D
Message ID#Unique
number
Unique message number generated by using:
Message type, IMO ship identification number of ship being tracked, ASP ID# and Time Stamp 2.
B, C, D
Reference ID#Unique
number
The message ID of the associated request message. It is only valid for a response to a request message (a 0 value indicates the message is not a result of a request message).B, C, D
IMO#IMO#IMO ship identification number of the ship being tracked.B, C, D
MMSI#MMSI#Maritime Mobile Service Identity number of the ship being tracked.B, C, D
Time Stamp 2Time2Date and time ASP receives message.B, C, D
Time Stamp 3Time3Date and time ASP transmits message.B, C, D
OtherOtherReserved field that may include price or billing specific information.B, C, D, E

 

 

LRIT Data
Centre

DC ID#DC#LRIT Data Centre unique identification number.D, C
Time Stamp 4Time4Date and time when the Data Centre receives message from ASP.D, C
Time Stamp 5Time5Date and time when the Data Centre transmits a message to a LRIT Data User.D, C
Response typeCoastal Flag Port SAROne of these four values is added by the Data Centre when the message is transmitted.D, C
LRIT Data User
(Requestor)
UserID#Unique identification number identifying Requesting LRIT Data User. Every participating LRIT Data User has a unique number.
For a coastal State the request is part of the Standing Order in the Data Distribution Plan.
B, C, D
Ship NameNameName of ship associated with position report.D, C
LRIT Data User
(Provider)
UserID#Unique identification number identifying Contracting Government to which the ship is registered.B, C, D
 

02.02.03 LRIT Ship Position Request Messages (Message 4 and 5)
Ingangsdatum: 15-12-2006

2.2.3 - LRIT Ship Position Request Messages (Message 4 and 5)

2.2.3.1 Table 3 outlines the parameters associated with the ship position request messages.

2.2.3.2 The "Message type" parameter in table 3 indicates the type of message of the associated LRIT message. The LRIT components such as the LRIT Data Centres can use this parameter to distinguish between the various LRIT messages listed in table 1.

2.2.3.3 The "Message ID#" parameter in table 3 is a unique identification number that LRIT components can use to identify individual messages within the LRIT network. The Message ID# is generated by using a concatenation of the following parameters: message type, IMO ship identification #, LRIT Data User ID# and Time Stamp. All these parameters are necessary in order to generate a unique ID number.

2.2.3.4 The "IMO#" and "Ship name" parameters in table 3 are the IMO number of the ship being tracked and the ship name respectively.

2.2.3.5 The "LRIT Data User (Provider)" parameter in table 3 is a unique identification number associated with the Contracting Government to which the ship is registered. This parameter is used to identify the destination of the request message. The International LRIT Data Exchange will look at this parameter during processing of the request message and use it to correctly route the message to the appropriate Data Centre(s).

2.2.3.6 The "Request type" parameter indicates the requesting Contracting Government' entitlement to receive the LRIT data. The Contracting Government may be requesting the LRIT data as: a flag State; a port State; a coastal State; or a SAR service.

2.2.3.7 The "Port or Port facility" parameter in table 3 identifies the particular port or port facility which the ship is intending to enter. If the "Request type" parameter is set to "Port" and the "Port or Port facility" parameter is not specified, then the "Distance from port" parameter indicates the distance off the Contracting Government's coastline where the tracking of the ship is intended to begin.

2.2.3.8 The "Distance from Port or Port facility or coastline" parameter in table 3 indicates the distance from a port or port facility or coastline where the requesting Contracting Government wishes to track the designated ship. This parameter is only valid when the "Requesting type" parameter is set to "Port" If the "Requesting type" parameter is set to "Port" and the "Distance from Port or Port facility" parameter is not specified, then the LRIT Data Centre processing the request message should refer to the standing order information contained within the Data Distribution Plan.

2.2.3.9 The "Request duration" parameter in table 3 provides criteria with respect to the data information requested on the ship. This parameter may be set to a value of : "Poll"; "Periodic"; "Archived dates" or "Stop." The "Poll" value is used to initiate a one time poll of the shipborne equipment. The "Periodic" value will indicate the start and stop time as well as the reporting rate for a given ship. The processing ASP will use this information to either reconfigure the shipborne equipment or simulate reconfiguration of the equipment by issuing individual polling of the ship. The "archived dates" value will include the start and end dates which the requested data encompasses.

2.2.3.10 The "LRIT Data User (Requestor)" parameter in table 3 represents the LRIT Data User originating the request message.

2.2.3.11 The "Time Stamp" parameter in table 3 represents the date and time associated with the generation of the LRIT request message.

 

Table 3 - LRIT position request messages

Parameter
Added By

Parameter

Value

Description

LRIT
Segment

 

LRIT Data
User

Message type4, 5Message type number:
4 - Ship position request
5 - SAR poll request
B, C, D
Message ID#Unique numberUnique message number generated by using: Message type, IMO ship identification #, LRIT Data User ID# and Time Stamp.B, C, D
IMO#IMO#IMO ship identification number of the ship being tracked.B, C, D
Ship nameShip Name, UnknownName of the ship intended to be tracked, if available. (Unknown value if the ship name is not available.)B, C, D
LRIT Data User
(Provider)
UserID#Unique identification number identifying Contracting Government to which the ship is registered.B, C, D
Request typeCoastal, Flag
Port, or SAR
This LRIT parameter is set based upon the LRIT Data User's entitlement to receive LRIT data.B, C, D
Port or Port facilityUN/LOCODEAcknowledged naming scheme for urban centres, including ports and port facilities (latitude and longitude).
If nothing is specified, this means distance from the coast.
B, C, D
Distance from Port or Port facility or coastlineNumberThis is the distance from the Port or Port facility where tracking should commence, or the applicable distance from the coast when tracking should commence.
If nothing is specified, this means refer to Standing Order.
B, C, D
Request durationPeriodic Rate,
or
Poll is a one time poll of the ship.
Periodic Rate (ship report rate with start and end date for period) is a request to set the position reporting rate.
B, C, D
Archived DateArchived Date (start and end date) is a request for archived data. (Start date can be in future.)
(ASPs may decide to use polling or variable reporting rate modification to obtain additional position reports.)
StopA LRIT Data User can request a stop in tracking of a ship by using this parameter within a request message.
LRIT Data User
(Requestor)
UserID#Unique identification number identifying Requesting LRIT Data User. Every participating LRIT Data User has a unique number.B, C, D
Time StampTimeDate and time when LRIT Data User transmits message to its DC.B, C, D

02.02.04 SAR SURPIC Request (Message 6)
Ingangsdatum: 15-12-2006

2.2.4 - SAR SURPIC Request (Message 6)

2.2.4.1 Table 4 outlines the SAR SURPIC request message.

2.2.4.2 This SURPIC gets data from the databases within the Data Centres. Real time data is requested via Message 5.

2.2.4.3 The "Message type" parameter in table 4 indicates the type of message of the associated LRIT message. The LRIT components such as the LRIT Data Centres can use this parameter to distinguish between the various LRIT messages listed in table 1.

2.2.4.4 The "Message ID#" parameter in table 4 is a unique identification number that LRIT components can use to identify individual messages within the LRIT network. The Message ID# is generated by using a concatenation of the following parameters: Message type, LRIT Data User ID and Time Stamp. All these parameters are necessary in order to generate a unique ID number.

2.2.4.5 The "SAR geographical area" parameter in table 4 contains information relating to a geographical area for which a SAR authority requests LRIT positional data for all ships within that area. The area may be either a circle defined by a radius and a centre or, alternatively, a rectangle defined by two corners.

2.2.4.6 The "Number of Positions" parameter in table 4 indicates the number of the most recent LRIT positional data reports requested. If, for example, the value is 2, then the requesting SAR service is asking for the last two positional data reports of all ships within the defined SAR geographical area.

2.2.4.7 The "LRIT Data User (Requestor)" parameter in table 4 represents the LRIT Data User originating the request message.

2.2.4.8 The "Time Stamp" parameter in table 4 represents the date and time associated with the generation of the LRIT SAR SURPIC request message.

 

Table 4 - SAR surpic request

Parameter
Added By

Parameter

Value

Description

LRIT
Segment

 

LRIT Data User

Message type6Message Identification number:
6 -  SAR SURPIC request
B, C, D
Message IDUnique
number
Unique message number generated by using: Message type, LRIT Data User ID and Time Stamp.B, C, D
SAR
geographical area
Circle centre and Radius, Rectangle top left, bottom rightCircle (centre position, radius), Rectangle (2 corners)
The latitude and longitude would be provided for circle centre or rectangle top left and bottom right points.The circle radius would be the distance in nautical miles.
B, C, D
Number of PositionsNumberLast N positions of ship.B, C, D
LRIT Data User
(Requestor)
UserID#Unique identification number identifying requesting LRIT
Data User. Every participating LRIT Data User has a unique number.
B, C, D
Time StampTimeDate and time when LRIT Data User transmits SAR SURPIC message.B, C, D

02.02.05 Error Message (Message 7)
Ingangsdatum: 15-12-2006

2.2.5 - Error Message (Message 7)

2.2.5.1 Table 5 outlines the error message.

2.2.5.2 Error messages within the LRIT network are generated when a particular network component detects that an error or fault has occurred within the LRIT system. The network component that has detected the error will build an error message and route the message to the appropriate LRIT network component. Table 5 outlines the various parameters to be included in the error message.

2.2.5.3 The "Message type" parameter in table 5 indicates the type of message of the associated LRIT message. The LRIT components such as the LRIT Data Centres can use this parameter to distinguish between the various LRIT messages listed in table 1.

2.2.5.4 The "Message ID#" parameter in table 5 is a unique identification number that LRIT components can use to identify individual messages within the LRIT network. The Message ID# is a concatenation of the message type, LRIT network component ID and Time Stamp.

2.2.5.5 The "Reference ID" parameter in table 5 will either be a Message ID of an associated request message, or a 0 value. The 0 value is populated if the message is not the result of a request message, whereas a valid "Message ID" value indicates that a request message has initiated the error message.

2.2.5.6 The "Error Code" parameter in table 5 provides details with respect to the specific type of error fault that has occurred in the LRIT system. Each code will help identify where the problem has occurred. The following sub-sections will provide additional information pertaining to the function of each error code.

  1. Error Code 0 -  "IDE not available" is generated when the International LRIT Data Exchange is not available for any reason. The error message will typically be generated by a Data Centre in order to indicate that the International LRIT Data Exchange is off line. A Data Centre can detect this type of error by using the System Status message transmitted from the IDE.

  2. Error Code 1 - "IDC not available" is generated when a Data Centre is not available. The International LRIT Data Exchange is responsible for determining if all Data Centres are on line. This is achieved with the help of the System Status message.

  3. Error Code 2 - "CSP not available" is generated when a Data Centre has determined a CSP is off line. The Data Centre would be responsible for detecting when the CSP is not available.

  4. Error Code 3 - "Ship not responding" can be generated by any Data Centre. All Data Centres will be responsible for detecting if ships registered to that Data Centre are transmitting normal LRIT position reports. If a LRIT Data User requests LRIT reports from a ship that is not responding, then the Data Centre to which the ship is registered should generate an error message with text content
    stating how long the ship has not been responding.

  5. Error Code 4 - "Ship not available" will be generated by a Data Centre when a request has been made for position reports associated with a ship registered to that Data Centre that is permanently not reporting.

  6. Error Code 5 - "Communications protocol problem" is generated when a LRIT network component detects a problem with the communication layer.

  7. Error Code 6 - "Could not load DDP" is generated when a Data Centre or the International LRIT Data Exchange is unable to process a receipt of the Data Distribution Plan. The message will typically be sent to the DDP administrator for appropriate action.

2.2.5.7 The "IMO#" parameter in table 2 is the IMO ship identification number of the ship being tracked.

2.2.5.8 The "Ship name" parameter in table 5 represents the ship name.

2.2.5.9 The "Destination" parameter in table 5 is a unique identification number associated with the LRIT component to which the error message is destined.

2.2.5.10 The "Originator" parameter in table 5 is a unique identification number associated with the LRIT component generating the error message. This parameter is used to identify where the error message originated.

2.2.5.11 The "Message" parameter in table 5 can contain ASCII text information relating to the nature of the error.

2.2.5.12 The "Time Stamp" parameter in table 5 represents the date and time associated with when the originator transmits the error message.

 

Table 5 - Error message

Parameter
Added By

Parameter

Value

Description

LRIT
Segment

 

 

LRIT network
component:
Data Centre,
ASP, or LRIT

Message type7Message Identification number:
7 -  Error message
B, C, D, E
Message ID#Unique numberUnique message number generated by using: Message type, LRIT network ID of the originator and Time Stamp.B, C, D, E
Reference ID0, Message ID of a request messageThe reference ID (if not 0) is the message ID of a request message that has failed. Only valid for a response to a request message (0 value indicates that the message is not a result of a request).B, C, D, E
Error Code0 - 60 - IDE not available1 - DC not available2 - CSP not available3 - Ship not responding4 - Ship not available5 - Communications protocol problem6 - Could not load DDPB, C, D, E
IMO#IMO#IMO ship identification number of the ship being tracked. (Optional.)B, C, D
Ship nameShip nameName of ship intended to be tracked. (Optional.)B, C, D
DestinationLRIT network component IDID of intended recipient (ASP, DC, IDE, LRIT Data User, or LRIT Co-ordinator) of the error message.B, C, D, E
OriginatorLRIT network component IDID of issuer (ASP, DC, IDE, LRIT Data User) of error
message.
B, C, D, E
MessageTextText message indicating the nature of the error message.B, C, D, E
Time StampTimeDate and time when LRIT node transmits error messageB, C, D, E

02.02.06 Receipt Message (Message 8)
Ingangsdatum: 15-12-2006

2.2.6 - Receipt Message (Message 8)

2.2.6.1 Table 6 outlines the receipt message.

2.2.6.2 The "Message type" parameter in table 6 indicates the type of message of the associated LRIT message. The LRIT components such as the LRIT Data Centres can use this parameter to distinguish between the various LRIT messages listed in table 1.

2.2.6.3 The "Message ID#" parameter in table 6 is a unique identification number that LRIT components can use to identify individual messages within the LRIT network. The Message ID# is a concatenation of the message type, LRIT network component ID, and Time Stamp.

2.2.6.4 The "Reference ID" parameter in table 6 will either be a Message ID# of an associated request message or a 0 value. The 0 value is populated if the message is not the result of a request message, whereas a valid "Message ID#" value indicates that a request message has initiated the error message.

2.2.6.5 The "Receipt code" parameter in table 6 provides information with respect to the specific receipt message that has been generated.

  1. Receipt code 0  "Not entitled to data" receipt message is generated by a Data Centre when it determines that the requesting LRIT Data User is not entitled to receive the data it has requested.

  2. Receipt code 1 - "No ship in SAR SURPIC area" message can be generated in response to a recently received SAR SURPIC request message. If a Data Centre that is processing a LRIT SAR SURPIC request message determines that there are no ships contained within the geographical area defined in the SAR SURPIC message, then the Data Centre will transmit a Receipt message with a Receipt code of 1.

2.2.6.6 The "IMO#" parameter in table 6 is the IMO ship identification number of the ship being tracked.

2.2.6.7 The "Ship name" parameter in table 6 represents the ship name.

2.2.6.8 The "Destination" parameter in table 6 is a unique identification number associated with the LRIT component to which the receipt message is destined.

2.2.6.9 The "Originator" parameter in table 6 is a unique identification number associated with the LRIT component generating the receipt message. This parameter is used to identify where the receipt message originated.

2.2.6.10 The "Message" parameter in table 6 can contain ASCII text information relating to the nature of the receipt.

2.2.6.11 The "Time Stamp" parameter in table 6 represents the date and time associated with when the originator transmits the receipt message.

 

Table 6 - Receipt message

Parameter
Added By

Parameter

Value

Description

LRIT
Segment

 

LRIT network
component:
Data Centre,
ASP, or LRIT
Data User

Message type8Message Identification number:
8 - Receipt message
B, C, D, E
Message ID#Unique numberUnique message number generated by using: Message type, LRIT network ID of the originator and Time Stamp.B, C, D, E
Reference ID0, Message ID of a request messageThe reference ID is the message ID of a request message that has been received.B, C, D, E
Receipt Message0 - 10 - Not entitled to data
1 - No ships in SAR SURPIC area
B, C, D, E
IMO#IMO#IMO ship identification number of the ship being tracked (optional).B, C, D
Ship nameShip nameName of ship intended to be tracked (optional).B, C, D
DestinationLRIT network component IDID of intended recipient (ASP, DC, IDE, LRIT Data User, or LRIT Co-ordinator) of the receipt message.B, C, D, E
OriginatorLRIT network component IDID of issuer (ASP, DC, IDE, LRIT Data User) of receipt
message.
B, C, D, E
MessageTextText message indicating the nature of the receipt message.B, C, D, E
Time StampTimeDate and time when LRIT node transmits receipt messageB, C, D, E

02.02.07 Data Distribution Plan Update (Message 9)
Ingangsdatum: 15-12-2006

2.2.7 - Data Distribution Plan Update (Message 9)

2.2.7.1 Table 7 outlines the Data Distribution Plan (DDP) Update message.

2.2.7.2 The DDP Update message is transmitted directly from the DDP web server to the IDE and Data Centres.

2.2.7.3 The "Message type" parameter in table 7 indicates the type of message of the associated LRIT message. LRIT components such as the LRIT Data Centres can use this parameter to distinguish between the various LRIT messages listed in table 1.

2.2.7.4 The "Message ID" parameter in table 7 is a unique identification number that LRIT components can use to identify individual messages within the LRIT network. The message ID# is a concatenation of the Message type and Time Stamp.

2.2.7.5 The "Message" parameter in table 7 can contain ASCII text information relating to the nature of the DDP Update message.

2.2.7.6 The "Time Stamp" parameter in table 7 represents the date and time associated with when the originator transmits the receipt message.

2.2.7.7 The "DDP file" parameter is a file attachment containing the data distribution plan.

 

Table 7 - Data distribution plan update message

Parameter
Added By

Parameter

Value

Description

LRIT
Segment

Administrator
of Data
Distribution
Plan

Message type9Message Identification number:
9 - Data Distribution Plan update
D, E
Message ID#Unique
number
Message type, Time Stamp.D, E
MessageTextText message indicating the nature of the update with respect to the Data Distribution Plan.D, E
Time StampTimeDate and time when administrator transmits Data Distribution Plan message.D, E
DDP filefileUpdated Data Distribution Plan file.D, E

02.02.08 Data Distribution Plan Request (Message 10)
Ingangsdatum: 15-12-2006

2.2.8 - Data Distribution Plan Request (Message 10)

2.2.8.1 Table 8 outlines the Data Distribution Plan Request message.

2.2.8.2 The DDP Request message is transmitted directly from the IDE and Data Centres to the DDP web server.

2.2.8.3 The "Message type" parameter in table 8 indicates the type of message of the associated LRIT message. LRIT components such as the LRIT Data Centres can use this parameter to distinguish between the various LRIT messages listed in table 1.

2.2.8.4 The "Message ID#" parameter in table 8 is a unique identification number that LRIT components can use to identify individual messages within the LRIT network.

2.2.8.5 The "Time Stamp" parameter in table 8 represents the date and time associated with when the originator transmits the receipt message.

 

Table 8 - Data distribution plan request message

Parameter
Added By

Parameter

Value

Description

LRIT
Segment

Administrator
of Data
Distribution
Plan

Message type10Message Identification number:
10 -  Data Distribution Plan request
D, E
Message IDUnique numberMessage type, LRIT Network ID, Time stamp.D, E
OriginatorLRIT network component IDID of issuer (DCs, IDE).B, C, D, E
Time StampTimeDate and time when administrator transmits Data Distribution Plan message.D, E

02.02.09 System Status Message (Message 11)
Ingangsdatum: 15-12-2006

2.2.9 - System Status Message (Message 11)

2.2.9.1 Table 9 outlines the System Status message.

2.2.9.2 Required functionality is as described in the Performance standards.

2.2.9.3 The "Message type" parameter in table 9 indicates the type of message of the associated LRIT message. LRIT components such as the LRIT Data Centres can use this parameter to distinguish between the various LRIT messages listed in table 1.

2.2.9.4 The "Message ID#" parameter in table 9 is a unique identification number that LRIT components can use to identify individual messages within the LRIT network. The Message ID# is a concatenation of the Message type, LRIT network ID, and Time Stamp.

2.2.9.5 The "Time Stamp" parameter in table 9 represents the date and time associated with when the originating LRIT network component transmits the System Status message.

2.2.9.6 The "System Status" parameter in table 9 provides information pertaining to the operational status of the LRIT network component (IDE or DC) 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.

2.2.9.7 The "Originator" parameter in table 9 is a unique identification number associated with the LRIT component generating the System Status message. This parameter is used to identify where the System Status message originated.

 

Table 9 - System status message

Parameter
Added By

Parameter

Value

Description

LRIT
Segment

International
LRIT Data
Exchange and
Data Centres
Message type11Message Identification number:
11 - System Status message
D
Message ID#Unique
number
Message type, LRIT network ID,Time Stamp.D
Time StampTimeDate and time.D
DDP versionVersion #The current version of the DDP as received from the DDP web server.D
System Status0 or 1This is sent by both the IDE and all DCs. A value of 0 means normal function; a value of 1 means not able to provide functionality as described in the Performance standards.D
OriginatorLRIT network component IDID of issuer (DCs and IDE).D

03 Communication Protocol Strategy

3 - Communication Protocol Strategy

Ingangsdatum: 15-12-2006
3 - Communication Protocol Strategy

03.01 General

3.1 - General
Ingangsdatum: 15-12-2006
3.1 - General
03.01.01 Overview
Ingangsdatum: 15-12-2006

3.1.1 - Overview

3.1.1.1 An illustration of the various communication links in the LRIT system is shown in Figure 2. LRIT messages, as discussed earlier, will flow through the LRIT network and along each communication link. Communication protocols will be the mechanism that ensures LRIT messages are transported from one LRIT component to the next.

3.1.1.2 The following sections will provide details associated with the communication protocols and strategies for each of the communication links.

3.1.1.3 The functional description for the communication strategy of messages along all communication links will be discussed and all communication links will have to comply with the functional details. Specific communication protocols that adhere to the functional description will be outlined for the majority of the communication links. However, Contracting Governments that implement their own Data Centre are free to choose specific communication protocols for communication links 1, 2 and 3. It should also be noted that the ASP to CSP link (Communication link type 1) can be implemented with communication protocols other than those specified in this document.

 

Figure 2 - LRIT Communication links

03.01.02 Functional Communication Strategy
Ingangsdatum: 15-12-2006

3.1.2 - Functional Communication Strategy

3.1.2.1 The functional specifications associated with communication within the LRIT system are primarily stated in the Performance standards, resolution MSC.210(81). Each communication layer must use reliable technology that ensures the entire LRIT system meets the Performance standards.

03.01.03 Specific Communication Protocols
Ingangsdatum: 15-12-2006

3.1.3 - Specific Communication Protocols

3.1.3.1 The communication protocols specified in the following sub-sections are specific standards based on the functional description of the communication strategy outlined in resolution MSC.210(81) as well as mentioned above. The specific protocols relate to Communication links 2, 3 and 4 for the International LRIT Data Centre. LRIT Data Users that choose to implement their own Data Centre or that are part of a Regional/Co-operative Data Centre are only responsible for implementing Communication link 4 with respect to the specific communication protocols.

03.01.04 Physical Layer
Ingangsdatum: 15-12-2006

3.1.4 - Physical Layer

3.1.4.1 The physical medium that the LRIT data 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 all applicable (examples only).

03.01.05 Data Link Layer
Ingangsdatum: 15-12-2006

3.1.5 - Data Link Layer

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

03.01.06 Network Layer
Ingangsdatum: 15-12-2006

3.1.6 - Network Layer

3.1.6.1 The network layer shall be based upon version 4 (IPv4) of the Internet Protocol specification. Later versions of the Internet Protocol specification are also acceptable. Each component (e.g International LRIT Data Exchange, Data Centres) in the LRIT network will have its own unique IP address.

03.01.07 Transport Laye
Ingangsdatum: 15-12-2006

3.1.7 - Transport Layer

3.1.7.1 The transport layer will be based upon the Transmission Control Protocol (TCP).

03.01.08 Application Layer
Ingangsdatum: 15-12-2006

3.1.8 - Application Layer

3.1.8.1 The application layer will be built upon transporting XML-based messages between the various LRIT components. The SOAP protocol will be used to provide the mechanism for transmitting XML messages.

03.02 SOAP Overview

3.2 - SOAP Overview
Ingangsdatum: 15-12-2006
3.2 - SOAP Overview
03.02.01 General
Ingangsdatum: 15-12-2006

3.2.1 - General

3.2.1.1 The application layer for exchanging LRIT messages amongst the LRIT components within the LRIT network will be based up version 1.2 of the Simple Object Access Protocol (SOAP).

03.02.02 Soap Nodes
Ingangsdatum: 15-12-2006

3.2.2 - Soap Nodes

3.2.2.1 The Data Centres, International LRIT Data Exchange and ASPs following the specific communication protocol strategy will functionally operate as SOAP nodes. Two asynchronous one way message connections will be established between each connecting node. The LRIT messages as defined earlier will flow between SOAP nodes across the communication links illustrated in figure 2.

3.2.2.2 There will only be two nodes associated with the relaying of any SOAP message: the initial sender and the ultimate receiver. Thus, there will be zero intermediary SOAP nodes in the routing path of any SOAP message.

03.03 SOAP Messages

3.3 - SOAP Messages
Ingangsdatum: 15-12-2006
3.3 - SOAP Messages
03.03.01 Examples of LRIT Messages encoded into SOAP
Ingangsdatum: 15-12-2006

3.3.1 - Examples of LRIT Messages encoded into SOAP

3.3.1.1 Sub-sections 3.3.2 to 3.3.6 contain examples of LRIT messages encoded into the SOAP specific messaging format.

03.03.02 LRIT Ship Position Report Soap Message
Ingangsdatum: 15-12-2006

3.3.2 - LRIT Ship Position Report Soap Message

3.3.2.1 The following is an example of the LRIT ship position report encoded into a SOAP message. The values of the various parameters may be different. The example provided is based upon a Canadian ship (hypothetical Canadian LRIT Data Centre has a network component ID of 111) entering the LRIT coastal waters of country A (LRIT network component ID of 100). The ASP (LRIT network component ID of 099) starts building the message and passes it along to the LRIT Canadian Data Centre. The Canadian Data Centre processes the message and recognizes that country A is entitled to the data.


<?xml version='1.0' ?>

<env:Envelope xmlns: env= 'http://www.w3.org/2003/05/soap-envelope'>

<env: Body>

<m:LRIT Shipborne Equipment>

<m:Latitude> 47.37.00 N</m:Latitude>

<m:Longitude> 52.40.00 W </m:Longitude>

<m:TimeStamp1> 2006.07.15.23.00.00 </m:TimeStamp1>

<m:UniqueShipEquipNum> 123456789 </m:UniqueShipEquipNum>

</m:LRIT Shipborne Equipment>

<m:LRIT ASP>

<m:Message type> 1 </m:Message type>

<m:Message ID> 11234567809920060715230000 </m:Message ID>

<m:Reference ID> 0 </m:Reference ID>

<m:IMONum> 12345678 </m:IMONum>

<m:MMSINum> 123453467123 </m:MMSINum>

<m:TimeStamp2> 2006.07.15.23.01.00 </m:TimeStamp2>

<m:TimeStamp3> 2006.07.15.23.01.30 </m:TimeStamp3>

</m:LRIT ASP>

<m:LRIT Data Centre>

<m:DC ID>111 </m:DC ID>

<m:TimeStamp4> 2006.07.15.23.04.00 </m:TimeStamp4>

<m:TimeStamp5> 2006.07.15.23.04.30 </m:TimeStamp5>

<m:ResponseType> Coastal </m:ResponseType>

<m:LRITEndUser> 100 </m:LRITEndUser>

<ShipName> MapleLeaf </m:ShipName>

<FlagState> Canada </m:FlagState>

</m:LRIT Data Centre>

</env: Body>

</env:Envelope>

03.03.03 LRIT Ship Position Request Message
Ingangsdatum: 15-12-2006

3.3.3 - LRIT Ship Position Request Message

3.3.3.1 The following is an example of the LRIT ship position request message encoded into a SOAP message. The values of the various parameters may be different. The example provided is based upon a Canadian ship (Canada has a LRIT network component ID of 112) entering a port of country A (LRIT network component ID of 100). Country A has requested LRIT reports at 1 hr intervals for the next 24 hours. The request was issued on July 15, 2006 at 23:00:00.

<?xml version='1.0' ?>

<env:Envelope xmlns: env= 'http://www.w3.org/2003/05/soap-envelope'>

<env: Body>

<p:LRIT Data User>

<m:Message type> 4 </m:Message type>

<p:Message ID> 41234567810020060715230000 </p:Message ID>

<p:IMONum> 12345678 </p:IMONum>

<p:ShipName> MapleLeaf </p:ShipName>

<p:ShipFlag> 112 </p:ShipFlag>

<p:RequestType> Port <p:RequestType>

<p:Dur> 1hr, 2006.07.15.23.00.00 2006.07.16.23.00.00 </p:Dur>

<p:Request Country> 100 </p:Request Country>

<p:TimeStamp> 2006.07.15.23.00.00 </p:TimeStamp>

</p:LRIT Data User>

<p:LRIT ASP>

<p:UniqueShipEquipNum> 123456789 </p:UniqueShipEquipNum>

</p:LRIT ASP>

</env: Body>

</env:Envelope>

03.03.04 SAR SURPIC Request Message
Ingangsdatum: 15-12-2006

3.3.4 - SAR SURPIC Request Message

3.3.4.1 The following is an example of a SAR SURPIC request message encoded into a SOAP message. The values of the various parameters may be different. The example provided is based upon Canada (with a LRIT network component ID of 112) requesting a SAR SURPIC on July 15, 2006 at 23:00:00. Canada has requested data from a start date of July 15, 2006 at 20:00:00 to July 15, 2006 at 23:00:00. The geographical area for the SAR SURPIC is 5 nautical miles with a centre located at 47.37.00 N, 52.40.00 W.

<?xml version='1.0' ?>

<env:Envelope xmlns: env= 'http://www.w3.org/2003/05/soap-envelope'>

<env: Body>

<p:LRIT Data User>

<p:Message type> 6 </p:Message type>

<p:Message ID> 611220060715230000 </p:Message ID>

<p:SARArea>

<p:CircleCentre> 47.37,00 N, 52.40.00 W </p:CircleCentre>

<p :CircleRadius> 5 </p :CircleRadius>

</p:SARArea>

<p:Dur> 2006.07.15.20.00.00 , 2006.07.15.23.00.00 </p:Dur>

<p:RequestCountry> 112 </p:RequestCountry>

<p:TimeStamp> 2006.07.15.23.00.00 </p:TimeStamp>

</p:LRIT Data User>

<p:LRIT ASP>

<p:UniqueShipEquipNum> 123456789 </p:UniqueShipEquipNum>

</p:LRIT ASP>

</env: Body>

</env:Envelope>

03.03.05 LRIT Error Message
Ingangsdatum: 15-12-2006

3.3.5 - LRIT Error Message

3.3.5.1 The following is an example of a LRIT error message encoded into a SOAP message. The values of the various parameters may be different. The example is based upon a Canadian Ship (MapleLeaf) that has not been communicating LRIT reports for the last 26 hours. Country A (with a LRIT network component ID of 100) has requested (through the International LRIT Data Exchange) polled responses from the LRIT Canadian Data Centre (LRIT network component ID of 111). The date and time is July 15, 2006, 23:00:00. The Canadian Data Centre will build the SOAP message below and transmit it to the International LRIT Data Exchange, which in turn will send it to the Data Centre associated with country A.

<?xml version='1.0' ?>

<env:Envelope xmlns: env= 'http://www.w3.org/2003/05/soap-envelope'>

<env: Body>

<p:LRIT Network Component>

<p:Message type> 7 </p:Message type>

<p:Message ID> 711120060715230000 </p:Message ID>

<p:Reference ID> 41234567810020060715230000 </p;Reference ID>

<p:Error code> 3 </p:Error code>

<p:IMONum> 12345678 </p:IMONum>

<p:ShipName> MapleLeaf </p:ShipName>

<p:Destination> 100 </p:Destination>

<p:Orginator> 111 </p:Orginator>

<p:Message> Ship not responding for last 26 hrs.</p:Message>

<p:TimeStamp> 2006.07.15.23.00.00 </p:TimeStamp>

</p:LRIT Network Component>

</env: Body>

</env:Envelope>

03.03.06 LRIT Data Distribution Plan Update
Ingangsdatum: 15-12-2006

3.3.6 - LRIT Data Distribution Plan Update

3.3.6.1 The following is an example of the LRIT Data Distribution Plan update message encoded into a SOAP message. The values of the various parameters may be different.

<?xml version='1.0' ?>

<env:Envelope xmlns: env= 'http://www.w3.org/2003/05/soap-envelope'>

<env: Body>

<p:LRIT DDP Admin>

<p:Message type> 8 </p:Message type>

<p:Message ID> 820060715230000 </p:Message ID>

<p:Message> New DDP attached. </p:Message>

<p:TimeStamp> 2006.07.15.23.00.00 </p:TimeStamp>

</p:LRIT DDP Admin>

</env: Body>

</env:Envelope>

03.03.07 SOAP Processing
Ingangsdatum: 15-12-2006

3.3.7 - SOAP Processing

3.3.7.1 Software application modules operating on Data Centres, the International LRIT Data Exchange and ASPs shall process SOAP messages as outlined in version 1.2 of the SOAP specification.

03.03.08 SOAP Binding
Ingangsdatum: 15-12-2006

3.3.8 - SOAP Binding

3.3.8.1 SOAP messages will be exchanged between SOAP nodes by binding to the HTTP(S) protocol as defined by version 1.2 of the SOAP specification.

04 LRIT Communication Network Infrastructure

4 - LRIT Communication Network Infrastructure

Ingangsdatum: 15-12-2006
4 - LRIT Communication Network Infrastructure

04.01.01 General

Ingangsdatum: 15-12-2006
4.1.1 - General

04.01.02 World Wide Internet

Ingangsdatum: 15-12-2006

4.1.2 - World Wide Internet

4.1.2.1 The LRIT network infrastructure for communication amongst all Data Centres and the International LRIT Data Exchange must be based upon the world wide internet.

05 Data Security Within The LRIT Network

5 - Data Security Within The LRIT Network

Ingangsdatum: 15-12-2006
5 - Data Security Within The LRIT Network

05.01 General

5.1 - General
Ingangsdatum: 15-12-2006
5.1 - General
05.01.01 Adherence to Performance Standard
Ingangsdatum: 15-12-2006

5.1.1 - Adherence to Performance Standard

5.1.1.1 Data security for LRIT information exchanged between the various LRIT components is based upon the performance details outlined in section 12 (LRIT security) of resolution MSC.210(81). The functional communication specification is expanded with additional details as well as outlining specific data security protocols and strategies.

05.02 Functional Communication Specification

5.2 - Functional Communication Specification
Ingangsdatum: 15-12-2006
5.2 - Functional Communication Specification
05.02.01 General
Ingangsdatum: 15-12-2006

5.2.1 - General

5.2.1.1 Authorization, authentication, confidentiality and integrity are the key functional concepts with respect to data security for the LRIT network.

05.02.02 Authorization
Ingangsdatum: 15-12-2006

5.2.2 - Authorization

5.2.2.1 All LRIT information existing in the LRIT network must not be made available to all LRIT Data Users. Data availability to LRIT Data Users shall be based upon the policy requirements established in resolution MSC.202(81). Each LRIT component within the network shall ensure that the component with which it is communicating is authorized to receive the information being transmitted.

05.02.03 Authentication
Ingangsdatum: 15-12-2006

5.2.3 - Authentication

5.2.3.1 The various LRIT components in the LRIT network must perform authentication before exchanging information with one another. Both components of any point to point communication link must authenticate each other using a standard authentication process.

05.02.04 Confidentiality
Ingangsdatum: 15-12-2006

5.2.4 - Confidentiality

5.2.4.1 The data exchanged between LRIT components must not be disclosed to unauthorized entities during transit across the LRIT network. This must be accomplished by using standard digital cryptography techniques featuring an encryption strength equivalent to or better than 128 bits.

05.02.05 Integrity
Ingangsdatum: 15-12-2006

5.2.5 - Integrity

5.2.5.1 The data exchanged between LRIT components must not be altered by any entity during transit across the LRIT network. This must be accomplished by using standard digital cryptography techniques featuring an encryption strength equivalent to or better than 128 bits.

05.03 Point to Point Data Security Strategy and Protocols

5.3 - Point to Point Data Security Strategy and Protocols
Ingangsdatum: 15-12-2006
5.3 - Point to Point Data Security Strategy and Protocols
05.03.01 General
Ingangsdatum: 15-12-2006

5.3.1 - General

5.3.1.1 LRIT components within the LRIT network will communicate with one another through secure point to point communication links.

05.03.02 Transport Layer Security
Ingangsdatum: 15-12-2006

5.3.2 - Transport Layer Security

5.3.2.1 Each LRIT component that forms a point to point communication link must 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.

05.03.03 Digital Certificates
Ingangsdatum: 15-12-2006

5.3.3 - Digital Certificates

5.3.3.1 Each LRIT component in the LRIT network must verify each others digital certificates before exchanging LRIT information as a method for implementing data authentication. If either component detects an issue with the other LRIT component's certificate, then exchange of data information should not occur.

5.3.3.2 The digital certificates, as a minimum, should contain the following information:

  1. the name of the certificate holder;

  2. the holder's public key;

  3. the name of the certificate authority that issued the certificate;

  4. the serial number; and

  5. the validity period of the certificate.
05.03.04 Key Hashing for Message Authentication
Ingangsdatum: 15-12-2006

5.3.4 - Key Hashing for Message Authentication

5.3.4.1 Each LRIT component must use Key Hashing for Message Authentication Code (HMAC) when communicating across a TLS secured link. HMAC will ensure that LRIT data is not altered during transit and the data integrity is maintained.

05.03.05 Public - Private Key Cryptography
Ingangsdatum: 15-12-2006

5.3.5 - Public -  Private Key Cryptography

5.3.5.1 The TLS secured link must use a public - private (asymmetric) key strategy for encrypting LRIT data. The encryption strength should be strong with a minimum of 128 bits encryption.

05.04 Virtual Private Network

5.4 - Virtual Private Network
Ingangsdatum: 15-12-2006
5.4 - Virtual Private Network
05.04.01 General
Ingangsdatum: 15-12-2006

5.4.1 - General

5.4.1.1 Communication between a Data Centre and the International LRIT Data Exchange must have the option of implementing a Virtual Private Network (VPN) in place of the secured point to point link described in the previous section. The established VPN must meet all the functional specifications described in this document in addition to the specific protocols and features outlined in this section.

05.04.02 TLS VPN
Ingangsdatum: 15-12-2006

5.4.2 - TLS VPN

5.4.2.1 Data Centres that choose to implement VPNs as a connection method must use Transport Layer Security (TLS) based technology for creating secure VPN tunnels. Thus, much of the information outlined in the TLS point to point data security discussion relates to the TLS VPN tunnels.

05.04.03 Digital Certificates
Ingangsdatum: 15-12-2006

5.4.3 - Digital Certificates

5.4.3.1 The Data Centre and the International LRIT Data Exchange each have to verify each others digital certificates before information is exchanged. This process, as described in the TLS point to point subsection, is required in order to perform two way authentication. If either the Data Centre or International LRIT Data Exchange detects a problem with the others certificate, then no information is permitted to be transmitted.

05.04.04 Key Hashing for Message Authenticating
Ingangsdatum: 15-12-2006

5.4.4 - Key Hashing for Message Authenticating

5.4.4.1 Each LRIT component must use Key Hashing for Message Authentication Code (HMAC) when communicating across a TLS secured VPN tunnel. HMAC will ensure that LRIT data is not altered during transit and the data integrity is maintained.

05.04.05 Public - Private Key Cryptography
Ingangsdatum: 15-12-2006

5.4.5 Public - Private Key Cryptography

5.4.5.1 The TLS secured VPN link must use a public - private (asymmetric) key strategy for encrypting LRIT data. The encryption strength should be strong with a minimum of 128 bits encryption.

Annex 04 Draft protocols for the development testing of the LRIT

Annex 4 - Draft protocols for the development testing of the LRIT system and for testing the integration into the system of new LRIT data centres

Ingangsdatum: 15-12-2006

Annex 4 - Draft protocols for the development testing of the LRIT system and for testing the integration into the system of new LRIT data centres

01 General Provisions

1 - General Provisions

Ingangsdatum: 15-12-2006
1 - General Provisions

01.01 Scope and Background

1.1 - Scope and Background
Ingangsdatum: 15-12-2006
1.1 - Scope and Background
01.01.01 Scope
Ingangsdatum: 15-12-2006

1.1.1 - Scope

1.1.1.1 The intent of this document is to provide draft protocols for the  evelopment testing of the international Long-Range Identification and Tracking (LRIT) system and for testing the integration into the system of new LRIT Data Centres.

1.1.1.2 This document has been prepared by the Ad Hoc Working Group on  Engineering Aspects of Long-Range Identification and Tracking of Ships.

1.1.1.3 In preparing the document, the Ad Hoc Working Group has taken into account the provisions of SOLAS regulation V/19-1 and resolution MSC.21(81), "Performance Standards and Functional Requirements for the Long Range Identification and Tracking of Ships."

01.01.02 Background
Ingangsdatum: 15-12-2006

1.1.2 - Background

1.1.2.1 The Maritime Safety Committee, at its eighty-first session in May 2006, adopted amendments to chapter V of the SOLAS Convention in relation of LRIT. These amendments will enter into force on 1 January 2008 provided that acceptance criteria have been fulfilled by 1 July 2007.

1.1.2.2 The LRIT system provides for the global identification and tracking of ships.

1.1.2.3 In operating the LRIT system, recognition shall be given to international conventions, agreements, rules or standards that provide for the protection of navigational information.

1.1.2.4 The draft Protocols for the Development Testing of the LRIT System and for Testing the Integration into the System of New LRIT Data Centres for the international LRIT system as outlined in this document will be established and recognized by the Committee.

01.02 General Description of the System and Definition2

1.2 - General Description of the System and Definitions
Ingangsdatum: 15-12-2006
1.2 - General Description of the System and Definitions
01.02.01 LRIT System Description
Ingangsdatum: 15-12-2006

1.2.1 - LRIT System Description

1.2.1.1 As described in resolution MSC.210(81), sub-section 1.2, 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 LRIT Data Centre(s), including any related Vessel Monitoring System(s);

  5. the LRIT Data Distribution Plan;

  6. the International LRIT Data Exchange; and

  7. LRIT Data Users.

1.2.1.2 As described in resolution MSC.210(81), sub-section 1.2, certain aspects of the performance of the LRIT system are reviewed or audited by an LRIT Co-ordinator acting on behalf of all Contracting Governments.

01.02.02 LRIT System Operation
Ingangsdatum: 15-12-2006

1.2.2 - LRIT System Operation

1.2.2.1 Subsections 1.2.2.1 to 1.2.2.11 provide a high-level overview of the LRIT system architecture. The LRIT system performance standards, resolution MSC.210(81), 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 positional data 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 resolution MSC.210(81), Table 1.

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 will travel 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, will add additional information to the LRIT message and pass along the expanded message to its associated LRIT Data Centre. 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 the "Draft Technical Specifications for Communication within the LRIT System."

1.2.2.6 LRIT Data Centres will store all incoming LRIT information from ships instructed by their Administrations to transmit LRIT information to that Data Centre. LRIT Data Centres will disseminate LRIT information to LRIT Data Users according to the Data Distribution Plan (DDP).

1.2.2.7 The LRIT Data Distribution Plan will contain the information required by the Data Centres for determining how LRIT information will be distributed to the various Contracting Governments. The DDP will contain information such as standing orders from Contracting Governments and geographical polygons relating to Contracting Governments' coastal waters and ports and port facilities.

1.2.2.8 The Data Centres will process all LRIT messages to and from the International LRIT Data Exchange (IDE). The IDE will process all LRIT messages between LRIT Data Centres. The IDE will route the message to the appropriate Data Centre based upon the information contained within the DDP. The IDE will neither process nor store the positional data contained within LRIT messages.

1.2.2.9 LRIT Data Users may 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.

1.2.2.10 The LRIT Co-ordinator assists in the establishment of the international components of the LRIT system, performs administrative functions, and reviews and audits certain components of the LRIT system.

1.2.2.11 Figure 1 provides an illustration of the LRIT system architecture. The green circles and lines in the diagram show the various components and interfaces that must be tested as follows:

  1. the functionality of the International LRIT Data Exchange and all of its interfaces;

  2. the functionality of the International LRIT Data Centre and all of its interfaces;

  3. the functionality of the Data Distribution Plan and all of its interfaces; and

  4. the interface to all National and Regional / Co-operative Data Centres.

Figure 1 - Typical LRIT system architecture

01.02.03 Definitions
Ingangsdatum: 15-12-2006

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 may also collect from the ships information specified by the Contracting Government(s) that has established it.

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

  11. IDC operator means the individual responsible for the daily operation and maintenance of the International LRIT Data Centre.

1.2.3.2 The term "ship," when used in the present Performance standards and functional requirements for long-range identification and tracking of ships, includes mobile offshore drilling units and high-speed craft as specified in SOLAS 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.

01.02.04 Acronyms Used Within This Document
Ingangsdatum: 15-12-2006

1.2.4 - Acronyms Used Within This Document

1.2.4.1 The acronyms that appear within this document shall have the meanings assigned to them in this Article:

1ASP

Application Service Provider

 

2CSP

Communication Service Provider

 

3DCLRIT

Data Centre

 

4DDP

LRIT Data Distribution Plan

 

5IDC

International LRIT Data Centre

 

6IDE

International LRIT Data Exchange

 

7LES

Land Earth Station

 

8MMSI

Maritime Mobile Service Identity

 

9RFP

Request for Proposal

 

10SAR

Search and Rescue

 

11SAR SURPIC

Search and Rescue Surface Picture

 

12SOLAS

International Convention for the Safety of Life at Sea

 

13SSL

Secure Sockets Layer

 

14VPN

Virtual Private Network

 

15VMSVessel Monitoring System

02 The Testing Protocol

2 - The Testing Protocol

Ingangsdatum: 15-12-2006
2 - The Testing Protocol

02.01 General

Ingangsdatum: 15-12-2006

2.1 - General

2.1.1 The testing protocol for the international LRIT system is critical to ensure a successful system. There are two distinctive phases to the testing, namely:

  1. developmental testing, which occurs prior to the International LRIT system being commissioned; and

  2. integration testing, which occurs when components of the International LRIT system are modified.

2.1.2 This document describes the overall testing process that must be followed to ensure the successful implementation of the International LRIT system and the sustainability of the system.

2.1.3 User Test Cases

2.1.3.1 User test cases should be developed from the Performance standards. Each section from the Performance standards must have a corresponding test that confirms the functionality. The details of each test come from the "Draft Technical Specifications for Communication in the LRIT System;" the Draft Technical Specifications for the International LRIT Data Exchange;" and the "Draft Technical Specifications for the International LRIT Data Centre," each of which are based on the Performance standards (resolution MSC.210(81)).
Thus, the detailed test cases must respond to each section in the Performance standards as well as to each of the three related technical specifications.

2.1.3.2 Each message defined in the "Draft Technical Specifications for Communication in the LRIT System" must be fully tested to ensure the interface and functionality is correct. When the International LRIT Data Exchange is tested, the test cases must also cover all of the section in the "Draft Technical Specifications for the International LRIT Data Exchange." Similarly for the testing of the International LRIT Data Centre, all of the sections in the "Draft Technical Specifications for the International LRIT Data Centre" must be covered. Although the IDC specification only applies to the International LRIT Data Centre, it should also be used as an aid in developing the test cases for all of the other Data Centres. The following sections describe the highest level of user cases.

  1. All possible functional tests shall be included and repeated several times to document consistency under various conditions. This shall include all possible operator and user commands, changes, requests, actions and the change of transceiver status, various transceiver modes (e.g. change of flag, commissioning, de-commissioning, transceivers in use for other accepted services if any);

  2. Multiple Data Centres should be used in order for LRIT messages to be passed from a Data Centre to the International LRIT Data Exchange to a Data Centre;

  3. Each type of LRIT Data User should be tested, i.e. Flag State, Port State, Coastal State, and SAR Authority;

  4. For each LRIT Data User, LRIT information should be provided using a request message as well as using standing orders;

  5. Polling and rate change commands should be tested for each combination of LRIT Data Users and types of requests (i.e. requests and standing orders);

  6. Both real time and archive queries from the Data Centres should be used;

  7. Several possible error situations and erroneous messages should be simulated to verify error handling and that users can only receive the information they are authorized to receive; and

  8. In addition to testing the normal range of values and commands, invalid commands should be used to ensure that all functionality is being correctly performed.

2.1.4 The LRIT Co-ordinator will be participating in the developmental and in-service testing of the international LRIT system. The overall co-ordination of the testing should be performed by the LRIT Co-ordinator.

2.1.5 Without the International LRIT Data Exchange, Data Centres cannot communicate with each other. However, in order to determine exactly what positions may or may not be forwarded to other Data Centres, the Data Distribution Plan must be in place. While the International LRIT Data Centre is critical for the successful implementation of the complete International LRIT system, it is not critical for the initial development of the system. Thus, in order to develop the international LRIT system, the International LRIT Data Exchange and Data Distribution Plan must be developed first.

02.02 International LRIT Data Exchange Initial Development

2.2 - International LRIT Data Exchange Initial Development

2.2.1 A number of Administrations already have Vessel Monitoring Systems, which they have indicated may become either National or Regional / Co-operative Data Centres. Since these systems are already in place, the assumption is made that once the international components of the International LRIT system have been developed, there will likely be several National and/or Regional/Co-operative Data Centres available for testing purposes.

2.2.2 The developmental contract for the International LRIT Data Exchange must contain developmental testing. The developer has to propose all of the testing parameters and the LRIT Co-ordinator should approve the testing document, but it will still be the developer's responsibility to deliver an International LRIT Data Exchange that meets the Performance standards.

2.2.3 The following three stages are proposed for the developmental testing of the  International LRIT Data Exchange:

  1. laboratory testing using a Data Centre simulator;

  2. parallel operational testing using a parallel data feed from voluntary Data Centres; and

  3. operational testing using the voluntary Data Centres.

2.2.4 Before the International LRIT Data Exchange receives live data, it should be fully lab tested using a Data Centre simulator that the developer will have to provide.

2.2.5 Laboratory Testing Using a Data Centre Simulator

2.2.5.1 All of the user test cases discussed in sub-section 2.1.3 will have to be carried out using the Data Centre simulator. Since both the Data Centre simulator and the International LRIT Data Exchange are being developed by the same entity, it raises the possibility of common mode errors.

2.2.5.2 The developer shall propose a set of tests to verify the functionality and performance of the system. The tests and test plans shall include the following as a minimum:

  1. the data storage facility/databases shall be populated with realistic data equal to at least one full year of records;

  2. the simulator must generate LRIT reports at both normal and worst-case levels during the tests; and

  3. a sufficient number of user accounts (with secure access) shall be defined and used during the test periods. This shall include at least 10 each of Flag States, Coastal States, Port States and SAR. A realistic Data Distribution Plan shall be made and shall also be modified during the tests.

2.2.5.3 The developer¿s tests shall be grouped as follows:

  1. software module tests (i.e. development tests);

  2. system tests;

  3. factory acceptance tests; and

  4. pre-service verification tests, to be performed in the subsequent testing phases.

2.2.5.4 Each software module shall be sufficiently tested to prove proper operation and consistency under various conditions.

2.2.5.5 The system tests shall include the full set of tests applicable for the complete system and factory acceptance tests and in-service verification tests shall include sub-sets hereof.

2.2.5.6 All tests and test plans are to be accepted by the LRIT Co-ordinator.

2.2.5.7 All test results shall be properly documented with printouts and/or electronic data files, including all relevant results and status information.

2.2.5.8 Once the International LRIT Data Exchange has passed all of the tests using the Data Centre simulator, it will move to the parallel operational test.

2.2.6 Parallel Operational Test

2.2.6.1 The parallel operational test assumes that Administrations have volunteered to make their National and/or Regional /Co-operative Data Centres available for the developmental testing of the International LRIT system. Administrations should have already modified their system to comply with the "Draft Technical Specifications for Communication in the LRIT System." Since the International LRIT Data Exchange is still under development, a parallel feed from the voluntary Data Centres will be provided to the International LRIT Data Exchange. In this way the International LRIT Data Exchange is prevented from crashing the operational Data Centres. The full range of user test cases discussed in subsection 2.1.3 will be carried out.

2.2.6.2 If the Data Distribution Plan is not available for these tests, each volunteer Data Centre will have to manually enter the various standing orders that will be used by that Data Centre to output LRIT information to other Data Centres.

2.2.6.3 Since a parallel data feed is being used, many of the user test cases may have to be simulated using the Data Centre simulator that was used during the laboratory tests. (Refer to sub-section 2.2.5.)

2.2.6.4 Bi-directional communications will be employed to the greatest extent possible to verify the communications protocols and the functional performance of the International LRIT Data Exchange as well as the volunteer Data Centres.

2.2.6.5 As problems arise, it will be imperative to determine if the cause is the International LRIT Data Exchange's implementation of the Performance standards and the specifications, or that of the volunteer Data Centre(s). Depending on the resolution of these problems, clarifications to the specifications will have to be promulgated to prevent similar interface problems with future Data Centres.

2.2.7 Operational Testing

2.2.7.1 After all of the interface issues have been resolved through the parallel operational test, the International LRIT System should go operational using the volunteer Data Centres. In this phase, all of the system components should now be operating according to the Performance standards and the specifications. The volunteer Data Centres will be required to stress the system by making requests as described in sub-section 2.1.3. In this way a full test of the volunteer Data Centres and the International LRIT Data Exchange can be performed.

2.2.7.2 If the Data Distribution Plan web server is not available for these tests, each of the volunteer Data Centres will have to mimic the distribution mechanisms to ensure that all of the information from the DDP is available to the Data Centres.

2.2.7.3 The performance of the volunteer Data Centres to its users is outside the scope of this test protocol. Only the performance of the National and Regional / Co-operative Data Centres that impact the International LRIT Data Exchange, the Data Distribution Plan, or another Data Centre are to be tested.

2.2.7.4 After these three testing phases have been successfully completed, the system is ready to accept new Data Centres. Each new Data Centre should be added according to the Integration test process described in section 2.5.

Ingangsdatum: 15-12-2006

2.2 - International LRIT Data Exchange Initial Development

2.2.1 A number of Administrations already have Vessel Monitoring Systems, which they have indicated may become either National or Regional / Co-operative Data Centres. Since these systems are already in place, the assumption is made that once the international components of the International LRIT system have been developed, there will likely be several National and/or Regional/Co-operative Data Centres available for testing purposes.

2.2.2 The developmental contract for the International LRIT Data Exchange must contain developmental testing. The developer has to propose all of the testing parameters and the LRIT Co-ordinator should approve the testing document, but it will still be the developer's responsibility to deliver an International LRIT Data Exchange that meets the Performance standards.

2.2.3 The following three stages are proposed for the developmental testing of the  International LRIT Data Exchange:

  1. laboratory testing using a Data Centre simulator;

  2. parallel operational testing using a parallel data feed from voluntary Data Centres; and

  3. operational testing using the voluntary Data Centres.

2.2.4 Before the International LRIT Data Exchange receives live data, it should be fully lab tested using a Data Centre simulator that the developer will have to provide.

2.2.5 Laboratory Testing Using a Data Centre Simulator

2.2.5.1 All of the user test cases discussed in sub-section 2.1.3 will have to be carried out using the Data Centre simulator. Since both the Data Centre simulator and the International LRIT Data Exchange are being developed by the same entity, it raises the possibility of common mode errors.

2.2.5.2 The developer shall propose a set of tests to verify the functionality and performance of the system. The tests and test plans shall include the following as a minimum:

  1. the data storage facility/databases shall be populated with realistic data equal to at least one full year of records;

  2. the simulator must generate LRIT reports at both normal and worst-case levels during the tests; and

  3. a sufficient number of user accounts (with secure access) shall be defined and used during the test periods. This shall include at least 10 each of Flag States, Coastal States, Port States and SAR. A realistic Data Distribution Plan shall be made and shall also be modified during the tests.

2.2.5.3 The developer¿s tests shall be grouped as follows:

  1. software module tests (i.e. development tests);

  2. system tests;

  3. factory acceptance tests; and

  4. pre-service verification tests, to be performed in the subsequent testing phases.

2.2.5.4 Each software module shall be sufficiently tested to prove proper operation and consistency under various conditions.

2.2.5.5 The system tests shall include the full set of tests applicable for the complete system and factory acceptance tests and in-service verification tests shall include sub-sets hereof.

2.2.5.6 All tests and test plans are to be accepted by the LRIT Co-ordinator.

2.2.5.7 All test results shall be properly documented with printouts and/or electronic data files, including all relevant results and status information.

2.2.5.8 Once the International LRIT Data Exchange has passed all of the tests using the Data Centre simulator, it will move to the parallel operational test.

2.2.6 Parallel Operational Test

2.2.6.1 The parallel operational test assumes that Administrations have volunteered to make their National and/or Regional /Co-operative Data Centres available for the developmental testing of the International LRIT system. Administrations should have already modified their system to comply with the "Draft Technical Specifications for Communication in the LRIT System." Since the International LRIT Data Exchange is still under development, a parallel feed from the voluntary Data Centres will be provided to the International LRIT Data Exchange. In this way the International LRIT Data Exchange is prevented from crashing the operational Data Centres. The full range of user test cases discussed in subsection 2.1.3 will be carried out.

2.2.6.2 If the Data Distribution Plan is not available for these tests, each volunteer Data Centre will have to manually enter the various standing orders that will be used by that Data Centre to output LRIT information to other Data Centres.

2.2.6.3 Since a parallel data feed is being used, many of the user test cases may have to be simulated using the Data Centre simulator that was used during the laboratory tests. (Refer to sub-section 2.2.5.)

2.2.6.4 Bi-directional communications will be employed to the greatest extent possible to verify the communications protocols and the functional performance of the International LRIT Data Exchange as well as the volunteer Data Centres.

2.2.6.5 As problems arise, it will be imperative to determine if the cause is the International LRIT Data Exchange's implementation of the Performance standards and the specifications, or that of the volunteer Data Centre(s). Depending on the resolution of these problems, clarifications to the specifications will have to be promulgated to prevent similar interface problems with future Data Centres.

2.2.7 Operational Testing

2.2.7.1 After all of the interface issues have been resolved through the parallel operational test, the International LRIT System should go operational using the volunteer Data Centres. In this phase, all of the system components should now be operating according to the Performance standards and the specifications. The volunteer Data Centres will be required to stress the system by making requests as described in sub-section 2.1.3. In this way a full test of the volunteer Data Centres and the International LRIT Data Exchange can be performed.

2.2.7.2 If the Data Distribution Plan web server is not available for these tests, each of the volunteer Data Centres will have to mimic the distribution mechanisms to ensure that all of the information from the DDP is available to the Data Centres.

2.2.7.3 The performance of the volunteer Data Centres to its users is outside the scope of this test protocol. Only the performance of the National and Regional / Co-operative Data Centres that impact the International LRIT Data Exchange, the Data Distribution Plan, or another Data Centre are to be tested.

2.2.7.4 After these three testing phases have been successfully completed, the system is ready to accept new Data Centres. Each new Data Centre should be added according to the Integration test process described in section 2.5.

02.02.01 Administrations already have Vessel Monitoring Systems
Ingangsdatum: 15-12-2006

2.2.1 - Administrations already have Vessel Monitoring Systems

A number of Administrations already have Vessel Monitoring Systems, which they have indicated may become either National or Regional / Co-operative Data Centres. Since these systems are already in place, the assumption is made that once the international components of the International LRIT system have been developed, there will likely be several National and/or Regional/Co-operative Data Centres available for testing purposes.

02.02.02 The developmental contract
Ingangsdatum: 15-12-2006

2.2.2 - The developmental contract

The developmental contract for the International LRIT Data Exchange must contain developmental testing. The developer has to propose all of the testing parameters and the LRIT Co-ordinator should approve the testing document, but it will still be the developer's responsibility to deliver an International LRIT Data Exchange that meets the Performance standards.

02.02.03 Three stages are proposed for the developmental testing
Ingangsdatum: 15-12-2006

2.2.3 -  Three stages are proposed for the developmental testing

The following three stages are proposed for the developmental testing of the  International LRIT Data Exchange:

  1. laboratory testing using a Data Centre simulator;

  2. parallel operational testing using a parallel data feed from voluntary Data Centres; and

  3. operational testing using the voluntary Data Centres.
02.02.04 Data Centre simulator
Ingangsdatum: 15-12-2006

2.2.4 - Data Centre simulator

Before the International LRIT Data Exchange receives live data, it should be fully lab tested using a Data Centre simulator that the developer will have to provide.

02.02.05 Laboratory Testing Using a Data Centre Simulator
Ingangsdatum: 15-12-2006

2.2.5 - Laboratory Testing Using a Data Centre Simulator

2.2.5.1 All of the user test cases discussed in sub-section 2.1.3 will have to be carried out using the Data Centre simulator. Since both the Data Centre simulator and the International LRIT Data Exchange are being developed by the same entity, it raises the possibility of common mode errors.

2.2.5.2 The developer shall propose a set of tests to verify the functionality and performance of the system. The tests and test plans shall include the following as a minimum:

  1. the data storage facility/databases shall be populated with realistic data equal to at least one full year of records;

  2. the simulator must generate LRIT reports at both normal and worst-case levels during the tests; and

  3. a sufficient number of user accounts (with secure access) shall be defined and used during the test periods. This shall include at least 10 each of Flag States, Coastal States, Port States and SAR. A realistic Data Distribution Plan shall be made and shall also be modified during the tests.

2.2.5.3 The developer¿s tests shall be grouped as follows:

  1. software module tests (i.e. development tests);

  2. system tests;

  3. factory acceptance tests; and

  4. pre-service verification tests, to be performed in the subsequent testing phases.

2.2.5.4 Each software module shall be sufficiently tested to prove proper operation and consistency under various conditions.

2.2.5.5 The system tests shall include the full set of tests applicable for the complete system and factory acceptance tests and in-service verification tests shall include sub-sets hereof.

2.2.5.6 All tests and test plans are to be accepted by the LRIT Co-ordinator.

2.2.5.7 All test results shall be properly documented with printouts and/or electronic data files, including all relevant results and status information.

2.2.5.8 Once the International LRIT Data Exchange has passed all of the tests using the Data Centre simulator, it will move to the parallel operational test.

02.02.06 Parallel Operational Test
Ingangsdatum: 15-12-2006

2.2.6 - Parallel Operational Test

2.2.6.1 The parallel operational test assumes that Administrations have volunteered to make their National and/or Regional /Co-operative Data Centres available for the developmental testing of the International LRIT system. Administrations should have already modified their system to comply with the "Draft Technical Specifications for Communication in the LRIT System." Since the International LRIT Data Exchange is still under development, a parallel feed from the voluntary Data Centres will be provided to the International LRIT Data Exchange. In this way the International LRIT Data Exchange is prevented from crashing the operational Data Centres. The full range of user test cases discussed in subsection 2.1.3 will be carried out.

2.2.6.2 If the Data Distribution Plan is not available for these tests, each volunteer Data Centre will have to manually enter the various standing orders that will be used by that Data Centre to output LRIT information to other Data Centres.

2.2.6.3 Since a parallel data feed is being used, many of the user test cases may have to be simulated using the Data Centre simulator that was used during the laboratory tests. (Refer to sub-section 2.2.5.)

2.2.6.4 Bi-directional communications will be employed to the greatest extent possible to verify the communications protocols and the functional performance of the International LRIT Data Exchange as well as the volunteer Data Centres.

2.2.6.5 As problems arise, it will be imperative to determine if the cause is the International LRIT Data Exchange's implementation of the Performance standards and the specifications, or that of the volunteer Data Centre(s). Depending on the resolution of these problems, clarifications to the specifications will have to be promulgated to prevent similar interface problems with future Data Centres.

02.02.07 Operational Testing
Ingangsdatum: 15-12-2006

2.2.7 - Operational Testing

2.2.7.1 After all of the interface issues have been resolved through the parallel operational test, the International LRIT System should go operational using the volunteer Data Centres. In this phase, all of the system components should now be operating according to the Performance standards and the specifications. The volunteer Data Centres will be required to stress the system by making requests as described in sub-section 2.1.3. In this way a full test of the volunteer Data Centres and the International LRIT Data Exchange can be performed.

2.2.7.2 If the Data Distribution Plan web server is not available for these tests, each of the volunteer Data Centres will have to mimic the distribution mechanisms to ensure that all of the information from the DDP is available to the Data Centres.

2.2.7.3 The performance of the volunteer Data Centres to its users is outside the scope of this test protocol. Only the performance of the National and Regional / Co-operative Data Centres that impact the International LRIT Data Exchange, the Data Distribution Plan, or another Data Centre are to be tested.

2.2.7.4 After these three testing phases have been successfully completed, the system is ready to accept new Data Centres. Each new Data Centre should be added according to the Integration test process described in section 2.5.

02.03 International LRIT Data Centre Initial Development

Ingangsdatum: 15-12-2006

2.3 - International LRIT Data Centre Initial Development

2.3.1 The developmental contract for the International LRIT Data Exchange must contain developmental testing. The developer has to propose all of the testing parameters and the LRIT Co-ordinator should approve the testing document, but it will still be the developer's responsibility to deliver an International LRIT Data Centre that meets the Performance standards.

2.3.2 The developer shall propose a set of tests to verify the functionality and performance of the system. All of the user test cases described in section 2.1.3 will be covered. The tests and test plans shall include the following as a minimum:

  1. An International LRIT Data Exchange simulator or a copy of the operational International LRIT Data Exchange should be used for the test. In addition Data Centre simulations should be used to replicate the operational system.

  2. The data storage facility/databases shall be populated with realistic data equal to at least one full year of records.

  3. The simulator must generate realistic LRIT reports at a realistic traffic level during the tests.

  4. A sufficient number of user accounts (with secure access) shall be defined and used during the test periods. This shall include at least 10 each of Flag States, Coastal States, Port States and SAR. A realistic Data Distribution Plan shall be made and shall also be modified during the tests.

2.3.3 The developer's tests shall be grouped as follows:

  1. Software Module Tests (i.e. development tests) -  Each software module shall be sufficiently tested to prove proper operation and consistency under various conditions.

  2. System Tests - The system tests shall include the full set of tests applicable for the complete system.

  3. Factory Acceptance Tests - The factory acceptance tests shall include sub-sets of the system tests.

  4. In-service Verification Tests - The in-service verification tests will only occur after the successful completion of the factory acceptance tests and shall cover the integration of the International LRIT Data Centre into the LRIT system.

2.3.4 All tests and test plans are to be accepted by the LRIT Co-ordinator.

2.3.5 All test results shall be properly documented with printouts and/or electronic data files including all relevant results and status information.

02.04 Data Distribution Plan Initial Development

Ingangsdatum: 15-12-2006

2.4 - Data Distribution Plan Initial Development

2.4.1 The developmental contract for the Data Distribution Plan must contain developmental testing. The developer has to propose the testing parameters and the IMO Secretariat should approve the testing document, but it will still be the developer's responsibility to deliver a Data Distribution Plan that meets the Performance standards and the "Draft Guidance on Setting Up and Maintaining the LRIT Data Distribution Plan."

2.4.2 All of the interfaces with the Data Distribution Plan must be tested, including:

  1. Contracting Governments via a secure web interface;

  2. The International LRIT Data Centre, and all other Data Centres, using the communications protocol defined within the "Draft Technical Specifications for Communication in the LRIT System;" and

  3. The International LRIT Data Exchange, using the communications protocol defined within the "Draft Technical Specifications for Communication in the LRIT System."

2.4.3 The developer shall propose a set of tests to verify the functionality and performance of the Data Distribution Plan within the International LRIT system. The tests and test plans shall include the following as a minimum:

  1. all possible functional tests shall be included and repeated several times to document consistency under various conditions, including at least all possible operator and user commands, changes, and requests;

  2. the data storage facility shall be populated with realistic data;

  3. a sufficient number of user accounts (with secure access) shall be defined and used during the test periods; and

  4. several possible error situations and erroneous messages shall be simulated to verify error handling.

2.4.4 Similar to the previous tests on the international components of the system the developer's tests shall be grouped as follows:

  1. Software Module Tests (i.e. development tests) - Each software module shall be sufficiently tested to prove proper operation and consistency under various conditions.

  2. System Tests - The system tests shall include the full set of tests applicable for the complete system.

  3. Factory Acceptance Tests - The factory acceptance tests shall include sub-sets of the system tests.

  4. In-service Verification Tests - The in-service verification tests will only occur after the successful completion of the factory acceptance tests and shall cover the integration of the Data Distribution Plan into the LRIT System.

2.4.5 All tests and test plans are to be accepted by the IMO Secretariat.

2.4.6 All test results shall be properly documented with printouts and/or electronic data files including all relevant results and status information.

02.05 Integration Test Process

Ingangsdatum: 15-12-2006

2.5 - Integration Test Process

2.5.1 The integration test process occurs when components of the International LRIT System  are modified (e.g. a new LRIT Data Centre is to be added to the LRIT system).

2.5.2 The integration test process does not address the interfaces between the Application Service Provider (ASP) and the Data Centre. These interfaces should be handled through the contractual relationship between the Administration and the ASP.

2.5.3 The integration test process will address the interfaces between the new Data Centre and the following:

  1. Data Distribution Plan, in accordance with the "Draft Guidance on Setting up and Maintaining the LRIT Data Distribution Plan."

  2. International LRIT Data Exchange, in accordance with the "Draft Technical Specifications for the International LRIT Data Exchange."

  3. LRIT Communications interfaces, in accordance with the "Draft Technical Specifications for Communication in the LRIT System."

2.5.4 After the International LRIT Data Exchange and the International LRIT Data Centre are in full operation, the new Data Centres may be integrated one by one after the Data Centres have passed system tests and the in-service verification tests, in a similar fashion to how the International LRIT Data Centre was commissioned.

  1. Software Module Tests (i.e. development tests) - The Administration Commissioning the Data Centre is responsible for performing this level of testing.

  2. System Tests - The new Data Centre shall be tested using the development environment prepared for the initial development of the International LRIT Data Exchange and the International LRIT Data Centre. The system tests shall include the full set of tests applicable for the complete system.

  3. In-service Verification Tests - The in-service verification tests will only occur after the successful completion of the system tests and shall cover the integration of the International LRIT Data Centre into the LRIT System. The same test procedure developed for the integration of the International LRIT Data Centre into the International LRIT System should be employed.

2.5.5 All test results shall be properly documented with printouts and/or electronic data files including all relevant results and status information.

Annex 05 Setting up and maintaining the LRIT data distribution plan

Annex 5 - Draft guidance on setting up and maintaining the LRIT data distribution plan

Ingangsdatum: 15-12-2006

Annex 5 - Draft guidance on setting up and maintaining the LRIT data distribution plan

01 General Provisions

1 -General Provisions

Ingangsdatum: 15-12-2006
1 -General Provisions

01.01 Scope and Background

1.1 - Scope and Background
Ingangsdatum: 15-12-2006
1.1 - Scope and Background
01.01.01 Scope
Ingangsdatum: 15-12-2006

1.1.1 - Scope

1.1.1.1 The intent of this document is to provide draft guidance on setting up and maintaining the Data Distribution Plan within the international Long-Range Identification and Tracking (LRIT) system as stated in the terms of reference of resolution MSC.210(81).

1.1.1.2 This document has been prepared by the Ad Hoc Working Group on Engineering  Aspects of Long-Range Identification and Tracking of Ships.

1.1.1.3 In preparing the document, the Ad Hoc Working Group has taken into account the provisions of SOLAS regulation V/19-1 and resolution MSC.210(81), "Performance Standards and Functional Requirements for the Long Range Identification and Tracking of Ships."

01.01.02 Background
Ingangsdatum: 15-12-2006

1.1.2 - Background

1.1.2.1 The Maritime Safety Committee, at its eighty-first session in May 2006, adopted amendments to chapter V of the SOLAS convention in relation of LRIT. These amendments will come into force on 1 January 2008 provided that acceptance criteria have been fulfilled by 1 July 2007.

1.1.2.2 The LRIT system provides for the global identification and tracking of ships.

1.1.2.3 In operating the LRIT system, recognition shall be given to international conventions, agreements, rules or standards that provide for the protection of navigational information.

01.02 General Description of the System and Definitions

1.2 - General Description of the System and Definitions
Ingangsdatum: 15-12-2006
1.2 - General Description of the System and Definitions
01.02.01 LRIT System Description
Ingangsdatum: 15-12-2006

1.2.1 - LRIT System Description

1.2.1.1 As described in resolution MSC.210(81), sub-section 1.2, 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 LRIT Data Centre(s), including any related Vessel Monitoring System(s);

  5. the LRIT Data Distribution Plan;

  6. the International LRIT Data Exchange; and

  7. LRIT Data Users.

1.2.1.2 As described in resolution MSC.210(81), sub-section 1.2, certain aspects of the performance of the LRIT system are reviewed or audited by an LRIT Co-ordinator acting on behalf of all Contracting Governments

01.02.02 LRIT System Operation
Ingangsdatum: 15-12-2006

1.2.2 - LRIT System Operation

1.2.2.1 Sub-sections 1.2.2.1 to 1.2.2.11 provide a high-level overview of the LRIT system architecture. The LRIT system Performance standards, resolution MSC.210(81), 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 positional data 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 resolution MSC.210(81), Table 1.

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 will travel 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, will add additional information to the LRIT message and pass along the expanded message to its associated LRIT Data Centre. 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 the "Draft Technical Specifications for Communication within the LRIT System."

1.2.2.6 LRIT Data Centres will store all incoming LRIT information from ships instructed by their Administrations to transmit LRIT information to that Data Centre. LRIT Data Centres will disseminate LRIT information to LRIT Data Users according to the Data Distribution Plan (DDP).

1.2.2.7 The LRIT Data Distribution Plan will contain the information required by the Data Centres for determining how LRIT information will be distributed to the various Contracting Governments. The DDP will contain information such as standing orders from Contracting Governments and geographical polygons relating to Contracting Governments' coastal waters and ports and port facilities.

1.2.2.8 Data Centres will process all LRIT messages to and from the International LRIT Data Exchange (IDE). The IDE will process all LRIT messages between LRIT Data Centres. The IDE will route the message to the appropriate Data Centre based upon the information contained within the DDP. The IDE will neither process nor store the positional data contained within LRIT messages.

1.2.2.9 LRIT Data Users may 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.

1.2.2.10 The LRIT Co-ordinator assists in the establishment of the international components of the LRIT system, performs administrative functions, and reviews and audits certain components of the LRIT system.

1.2.2.11 Figure 1 provides an illustration of the LRIT system architecture.

 

Figure 1 - Typical LRIT system architecture

01.02.03 Definitions
Ingangsdatum: 15-12-2006

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 may also collect from the ships information specified by the Contracting Government(s) that has established it.

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

  11. IDC operator means the individual responsible for the daily operation and maintenance of the International LRIT Data Centre.

1.2.3.2 The term "ship," when used in the present Performance standards and functional requirements for long-range identification and tracking of ships (the Performance standards), includes mobile offshore drilling units and high-speed craft as specified in SOLAS 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.

01.02.04 Acronyms Used Within This Document
Ingangsdatum: 15-12-2006

1.2.4 - Acronyms Used Within This Document

1.2.4.1 The acronyms that appear within this document shall have the meanings assigned to them in this Article:

1ASP

Application Service Provider

 

2CSP

Communication Service Provider

 

3DC

LRIT Data Centre

 

4DDP

LRIT Data Distribution Plan

 

5IDC

International LRIT Data Centre

 

6IDE

International LRIT Data Exchange

 

7LES

Land Earth Station

 

8MMSI

Maritime Mobile Service Identity

 

9RFP

Request for Proposal

 

10SAR

Search and Rescue

 

11SAR SURPIC

Search and Rescue Surface Picture

 

12SOLAS

International Convention for the Safety of Life at Sea

 

13SSL

Secure Sockets Layer

 

14VPN

Virtual Private Network

 

15VMSVessel Monitoring System

 

02 The Data Distribution Plan

Ingangsdatum: 15-12-2006

2 - The Data Distribution Plan

2.1 The Data Distribution Plan will reside and be managed by a web server (such as GISIS).

2.2 The LRIT Data Distribution Plan contains the critical tombstone information, the different polygons, distances and standing orders that are involved with flag State, port State, coastal State, and SAR access to the LRIT information.

2.3 The tombstone information resident in the Data Distribution Plan allows the entire international LRIT system to function. Without it, the individual elements of the system would be unable to communicate with each other and the Data Centres would not know what information they were allowed to transfer through the International LRIT Data Exchange (IDE) to other Data Centres based on the various access schemes.

03 Guidance on the Data Distribution Plan with Respect to Accountability

Ingangsdatum: 15-12-2006

3 - Guidance on the Data Distribution Plan with Respect to Accountability

3.1 As stated in section 11.1 of the Performance standards (resolution MSC.210(81)), "The Organization should establish and maintain the LRIT Data Distribution Plan." Thus the IMO Secretariat will hold the Data Distribution Plan.

3.2 However, once the LRIT Co-ordinator has been appointed and the two international components of the LRIT System have been established - namely the International LRIT Data Centre and the International LRIT Data Exchange - it is recommended that the Secretariat and the Organization re-evaluate the location and management of the Data Distribution Plan. Since the Data Distribution Plan will hold the tombstone information, there is value in co-locating it with the IDE.

3.3 Since Contracting Governments will be required to enter the pertinent information regarding LRIT into the Data Distribution Plan, then Contracting Governments are accountable for the validity of the information within the Data Distribution Plan. If, for example, a Contracting Government does not give a standing order with respect to coastal State, then that Government will not receive any information pursuant to coastal State tracking.

04 Guidance with respect to Data Distribution Plan Content

Ingangsdatum: 15-12-2006

4 - Guidance with respect to Data Distribution Plan Content

4.1 Section 11.2 of the Performance standards lists the content of the Data Distribution Plan. Each paragraph is repeated below with proposed guidance given for each paragraph. General guidance is given at the end of Part 4 of this document.

4.2 Section 11.2.1, "a list of Contracting Governments and SAR services entitled to receive LRIT information, and their points of contact."

  1. This information must be added by the IMO Secretariat.

4.3 Section 11.2.2, "information on the boundaries of geographic areas within which each Contracting Government is entitled to receive LRIT information about ships in the area."

  1. This information must be added by the IMO Secretariat, and will be used to verify a Contracting Government's standing orders.

4.4 Section 11.2.3, "information on any standing orders given by a Contracting Government pursuant to paragraphs 16.1.2, .16.1.3 and/or 16.1.41."

  1. Paragraph 16.1.2 contains the standing orders for flag State tracking. While the Administration's Data Centre requires this information, it is not useful for the Data Distribution Plan. However, since it is thus referenced in the Performance Standard, the Data Distribution Plan must be capable of accepting this data from a Contracting Government.

  2. Paragraph 16.1.3 contains the standing order for port State tracking. If the distance from a port is used, then the information from section 11.2.6 must be used in conjunction with this standing order. Although this is a standing order, a Notice of Arrival (NOA) must still be transmitted by the Contracting Government through its Data Centre to the destination Data Centre. The information contained in the standing order should include, but is not limited to, the following: ship name, IMO ship identification number, vessel's flag state and the distance from the Contracting Government's port.

  3. Paragraph 16.1.4 contains the standing order for coastal State tracking. The Contracting Government should be able to enter either the distance from its coast or a polygon that defines the standing order. The Data Distribution Plan should compare the resulting polygon with that defined in Sub-section 11.2.2 of the Performance standards to ensure it is valid. The Contracting Government may also optionally submit standing orders that contain criteria based upon the desire of that Contracting Government to track - or not track - vessels of a particular flag State.

4.5 Section 11.2.4, "information supplied by Administrations pursuant to the provisions of regulation V/19-1.8.1.4".

  1. The Administration's Data Centre will use this information to modify the coastal State tracking output function.

4.6 Section 11.2.5, "information supplied by Administrations pursuant to the provisions of regulation V/19-1.9.2."

  1. The Administration's Data Centre will use this information to modify the coastal State tracking output function.

4.7 Section 11.2.6, "a list of ports and port facilities together with the associated geographic coordinates (based on WGS 84 datum) located within the territory of each Contracting Government."

  1. This information will be used if a Contracting Government is using the distance from a port or port facility to start port State tracking.

4.8 Section 11.2.8, "a list of the National, Regional, Co-operative and International LRIT Data Centre(s) and their points of contact."

  1. The Internet address of each Data Centre should also be added. This will allow all components of the International LRIT system to communicate with each other.

4.9 Section 11.2.9, "a record indicating which LRIT DC is collecting and archiving LRIT information for each of the Contracting Governments."

  1. This information is required in order to map a ship via its flag with a Data Centre.

4.10 All of this tombstone information should be available to all Contracting Governments and all LRIT entities.

4.11 There is no 11.2.7 in the performance standard. The section should be re-numbered.


1
- 16.1.2 refers to provisions of regulation V/19-1.8.1.1 (flag State);
- 16.1.3 refers to provisions of regulation V/19-1.8.1.2 (port State);and
- 16.1.4 refers to provisions of regulation V/19-1.8.1.3 (coastal State).

05 Guidance on the Format of the Data Distribution Plan

Ingangsdatum: 15-12-2006

5 - Guidance on the Format of the Data Distribution Plan

5.1 The Data Distribution Plan should use a standard data exchange format, such as XML.

06 Guidance on Populating the Data Distribution Plan

Ingangsdatum: 15-12-2006

6 - Guidance on Populating the Data Distribution Plan:

6.1 The Performance standards do not indicate how the information that Contracting Governments provide to the Organization are input to the Data Distribution Plan. If Contracting Governments are responsible for providing this information to the Organization in accordance with Regulation section 1.8.2, and the Organization is responsible for establishing and maintaining the Data Distribution Plan under paragraph 11.1 of the Performance standards as noted previously, then it is implicit that the information to populate the Data Distribution Plan travels from a Contracting Government to the Organization into the Data Distribution Plan. This applies for both the initial Data Distribution Plan setup and for updating the Data Distribution Plan in-service.

6.2 The uploading of information from each Contracting Government to the Organization (and into the Data Distribution Plan) should happen automatically without human intervention by the IMO Secretariat.

6.3 The Data Distribution Plan must be available to authorized LRIT entities via a web server held by the IMO Secretariat.

6.4 The Data Distribution Plan must have the capability for Contracting Governments to enter and update the Data Distribution Plan information.

6.5 The Data Distribution Plan server must keep an archive of the previous versions of the Data Distribution Plan. This archive should be used by the LRIT Co-ordinator for auditing purposes.

6.6 The Data Distribution Plan server should automatically verify the format and values for each entry that a Contracting Government makes into the Data Distribution Plan.

6.7 The requirements for communications security are included in the "Draft Technical Specifications for Communication in the LRIT System."

07 Data Distribution Plan Performance Requirements

Ingangsdatum: 15-12-2006

7 - Data Distribution Plan Performance Requirements

7.1 Due to the critical nature of the Data Distribution Plan's information, it must be available 24 hours a day, 7 days a week with an availability of 99.9% over the year and 95% over a day. The availability targets should be reduced if they make the cost of the Data Distribution Plan exorbitant.

08 Data Distribution Plan Dissemination to other Elements of the International LRIT System

Ingangsdatum: 15-12-2006

8 - Data Distribution Plan Dissemination to other Elements of the International LRIT System

8.1 The LRIT System Diagram shows that the Data Distribution Plan is transferred directly to the other elements of the LRIT system, therefore there is no other option for disseminating the Data Distribution Plan.

8.2 The Data Distribution Plan server must automatically push the Data Distribution Plan to all Data Centres and the International LRIT Data Exchange whenever the Data Distribution Plan is updated.

  1. The Data Distribution Plan must keep a log that the information was successfully received by each Data Centre and the International LRIT Data Exchange. This information will be used by the LRIT Co-ordinator for auditing purposes.

8.3 The Data Distribution Plan server must allow any authorized LRIT entity to pull a copy of the Data Distribution Plan at any time.

8.4 If the size of the Data Distribution Plan file is in the range of 1 to 5 MB, then the file should be distributed in its entirety to all of the LRIT entities. However, if the size of the file is much greater than this, then it should be disseminated as changes to the file to save on communications bandwidth and time. As an example the Data Distribution Plan can be segmented by Contracting Governments so that when changes are made the file for each Contracting Government that has been changed will be pushed out as opposed to the entire Data Distribution Plan.

09 Links to the Data Distribution Plan

Ingangsdatum: 15-12-2006

9 - Links to the Data Distribution Plan

9.1 The system architecture figure in the Performance Standards does not have an arrow linking the Data Distribution Plan to the International LRIT Data Exchange, therefore that component of the system architecture figure is open to interpretation:

  1. One possible interpretation might be that all communications with the Data Distribution Plan are limited only to communications with Data Centres. This would not allow for the requirement under the Performance standards, 10.3.13, for the International LRIT Data Exchange to "have continuous access to (the) current LRIT Data Distribution Plan."

  2. Another possible interpretation is that figure reflects the concept that the intelligence (content) of the Data Distribution Plan is shared only with Data Centres, and not with the International LRIT Data Exchange, while still allowing for the routing of the Data Distribution Plan through the International LRIT Data Exchange.

  3. The technical specifications as currently drafted are based on the premise that the Data Distribution Plan is not to be routed through the International LRIT Data Exchange, but that the International LRIT Data Exchange, like all Data Centres, must have continuous access to the current Data Distribution Plan. Therefore, the diagram should be updated to show a connection from the Data Distribution Plan to the following users of the Data Distribution Plan:

  1. Data Centres;

  2. the International LRIT Data Centre;

  3. the International LRIT Data Exchange;

  4. Contracting Governments;

  5. the LRIT Co-ordinator; and

  6. the IMO Secretariat.

Inhoudsopgave

Alles dichtklappenAlles openklappen
Naar boven