Comments on LRIT documents
by HayleyCR@DFO-MPO.GC.CA
Dear Colleagues,
Provided below are some comments with respect to the documents that we
worked on in Paris.
LRIT communications document (working group 3)
***************************************
* The Ship Name parameter in table 4 has been put back in the document
and left as an optional parameter. Section 16.1.3 of Resolution MSC.210(81)
states that contracting governments may pass along ship name in order to
obtain LRIT information.
1 The message ID parameter outlined in the various message
tables is intended to provide a unique number that will differentiate the
various messages in the LRIT system. It fails to accomplish this objective
since the combination of DC id and time stamp will not produce a unique
number. Creation of message ID has changed to the following (message type
parameter added since message IDs will be different sizes):
* Request based messages: Message type, IMO#, contracting government
ID, time stamp.
1 Positional data report: Message type, IMO#,
DC ID, time stamp 2.
2 SAR Surpic: Message Type, contracting
government ID, time stamp.
3 Error messages: Message type, node ID, time
stamp.
4 DDP update: Message Type, time stamp.
* Time stamp parameter should be added to table 4 (ship position
request), table 5, table 6 and table 7.
International Data Exchange Document (working group 2)
********************************************
* Message ID and message type terminology used in the document is also
used in the communications document. It may be beneficial to standardize on
this type of terminology since the terms are used differently in each
document.
* The document states (page 3, 2.1.1.1) that requesting data centers
will include LRIT data center ID information in the requesting message
header. The data exchange would use this information in routing of the
request message. Currently, a slightly different methodology is outlined in
the communications specification. The ship's flag state information is
included in the requesting message as opposed to a data center ID parameter.
The data exchange would view the flag state parameter and route to the
appropriate data center. I believe both methods are acceptable and we simply
need to choose one method. However, all contracting governments will have to
know the data center that a given flag is assigned to if the method
described in the data exchange is chosen (example: Canada, as a port state,
has just received an NOA from a USA ship. Canada must check a list to
determine which data center, the USA ship is reporting to. This is an extra
step on the contracting government's part).
* Receipt messages are not covered in communications document.
* Response messages, other messages and SAR messages are described in
the communications document. I propose that they are described in only one
document in order to avoid confusion.
* I would expect to see a block diagram similar in concept to the one
outlined in the data center document. Each block would than be described in
the document.
Regards,
Craig Hayley
Electronics System Engineer
Canadian Coast Guard
PH: 709-772-7740