[Ccglrit-gcclrit] Comments on LRIT documents

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