Craig
I’m sorry that I missed the June
meetings there – so please excuse any duplication or overlap below as the
topics may have been discussed during the working groups. Some thoughts
on the question of how data formats arise, and the appropriate point within the
LRIT Infrastructure follows:
As a practical matter many ASPs today
support most, if not all, of the satellite providers likely to meet the
performance standards for LRIT (and thus be potentially CSPs or support CSPs).
Therefore I would disagree that this aspect is overly burdensome. Converting
data is not, in context, likely to determine the success or failure of an ASP
considering all other factors within an ASP’s list of responsibilities
(securing customers, maintaining a data center, certification into LRIT).
However; in our view that discussion
itself is rendered moot by the bigger question of what is technically feasible
for a CSP.
The view here is that CSPs will be unable to convert data to the proposed
format (or any other standard format for that matter).
Each CSP provides a communications path
via a specific satellite network. However CSPs do not, in most instances,
have knowledge of payload interpretation,
protocol or format of the data exchanged between the ASP and the
Shipboard Equipment. Such aspects are handled by firmware, scripting or
other configuration mechanisms that are specific to each equipment vendor.
Hence the data transmitted via any given CSP may vary from device-to-device and
change over time as new software or firmware revisions are made to the onboard equipment.
To our knowledge, all potential CSPs provide
flexibility in the representation of the LRIT requirements over their networks
(e.g. the raw encoding of a position report). Most potential CSPs also
provide several different delivery mechanisms which are proven both technically
and commercially. As the CSP cannot generally control the scripting/firmware/configuration
options present on each piece of Shipboard Equipment it becomes technically infeasible
to assign any data translation capabilities to the CSP.
Furthermore; even if a CSP did have
knowledge of the payload protocol – and thus could translate it – that
approach may have unintended consequences. If would lead to a
lowest-common-denominator approach within the data available to ASPs. Shipboard
Equipment and CSPs often make data available in addition to the fields required
for LRIT. We anticipate that ASPs are likely to use this additional data
to offer services complementary to LRIT – in terms of their offerings to
fleet owners and operators. Consequently; we do not believe that it is
desirable for a CSP to remove all additional
data as that would limit the overall utility of the LRIT system to fleet
owners and operators. Such a step would also reduce the commercial
opportunities available to ASPs.
Our view is that the earliest point in the
LRIT infrastructure where sufficient information is available to standardize a
format is at the ASP.
Of note the ability to satisfy the Performance
Standards arises through the use of two system components in conjunction:
a) Shipboard equipment;
including configuration options (scripts, firmware versions etc)
b) The CSP; including the
account configuration and selected delivery formats etc (i.e. VPN, Internet,
header formats)
There are two additional notes here - to
avoid potential misinterpretation of the above:
1) A CSP may also act as an ASP. In that case the ASP+CSP can
take responsibility for the configuration of shipboard equipment – and thus
is able interpret the payload data fully within the ASP aspects of its dual
role.
2) It may initially appear that Inmarsat-C equipment operating in
according to the baseline PDR specifications is an exception – as this is
a rare case of a network operating defining a position reporting protocol.
However; it should be noted that most deployed Inmarsat-C equipment extends the
Inmarsat-C baseline standards in vendor proprietary ways – and this is
specifically allowed within the Inmarsat-C baseline PDR specifications.
3) Finally; any translation to a common format could not be performed once
per “physical” satellite network. The “CSP” for example
in Inmarsat could be a Land Earth Station operator, other distribution partner
or Virtual Network Operator (i.e. Inmarsat-D+). The same comment applies
to other satellite providers who elect to have distribution partner(s) act as
the CSP. It should be noted that this may be required by the
telecommunications regulators in some countries (where a specific legal entity
or reseller holds the concession to land traffic from a given network within a
defined country). Consequently, care should be taken here not to equate “CSP” in the LRIT lexicon with “Satellite Network” in the sense of
the physical satellite constellations available – there may be many CSPs
sharing the same physical satellite network. Hence the apparent simplicity
of the “one-CSP” vs. “many-ASP” argument falls
down. It is actually quite possible that there would be fewer ASPs than
CSPs in practice once LRIT is deployed.
Best Regards
Jeff Douglas
Director
ABSOLUTE SOFTWARE INC
From:
ccglrit-gcclrit-bounces@lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca]
On Behalf Of Hayley, Craig
Sent: Friday, June 01, 2007 09:43
To: ccglrit-gcclrit@lists.ncf.ca
Subject: Re: [Ccglrit-gcclrit]
June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT,
Hamburg Germany
You make a fair point...
I would suggest other interested parties (such as ASPs wishing to bid on the
ASP function for the IDC case) voice their position. If we allow CSPs to send
the shipborne data to the ASP based upon any "format" or protocol
than the ASP will have to absorb the cost of supporting multiple
"formats" and communication protocols. The extra expense, of course,
would likely be pushed back to the customers (contracting governments).
This topic affects only ASPs
and CSPs wishing to form the communication path to the International Data
Centre (not national or regional data centers).
Based upon e-mails
written on this reflector and the discussion in the
Regards,
Craig Hayley
System Engineer
Canadian Coast Guard
From:
ccglrit-gcclrit-bounces@lists.ncf.ca
[mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On
Behalf Of Brian Mullan
Sent: Friday, June 01, 2007 10:37
AM
To: Hayley, Craig
Cc: ccglrit-gcclrit@lists.ncf.ca
Subject: Re: [Ccglrit-gcclrit]
June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT,
Hamburg Germany
Thanks, Craig
Good clarification on the
data format from the ships. However, you now infer that CSPs will perhaps be
asked to format messages from ships – but not all CSPs have signed up to
do this (I know of only one). It is the understanding of many CSPs that the
manipulation of the “raw” data from ships starts at the ASP level.
Also, the LRIT coordinator has said in the past that coordination
(“oversight”) starts at the ASP level. The CSP has largely been
seen (until now) as purely the comms pipe that provides the LRIT data from
ships to the ASP and to start involving CSPs in manipulating LRIT data would
extend the oversight role.
Writing in specifications
for all CSPs would therefore appear to be premature!
Kind regards
Brian
Brian Mullan
Head, Maritime Safety
Services
Inmarsat,
Tel: +44 (0)20 7728 1464
Fax: +44 (0)20 7728 1689
Mob: +44 (0)7711 495836
From: Hayley, Craig
[mailto:HayleyCR@DFO-MPO.GC.CA]
Sent: 01 June 2007 13:52
To: Brian Mullan
Cc: ccglrit-gcclrit@lists.ncf.ca
Subject: RE: [Ccglrit-gcclrit]
June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT,
Hamburg Germany
Hi All,
I'm please to see a good
discussion has developed around this topic. Hopefully, more discussion on other
topics in the documents will be initiated over the coming week before we meet
in
Given the e-mails on this
topic, the text (including wording in the table) should be
altered to eliminate any confusion.
I agree that the specific
data elements (latititude, longitude, year, month, day, hour, minute, unique
equipment identifier) that the shipborne equipment transmits is the important
information. The "format" of how those elements are displayed is
accomplished by land based software (not shipborne equipment software). Essentially,
an application piece of software will take those data elements, process
them and display them in a given "format". It has been decided
that SOAP messages (using XML format) will be the back bone of the LRIT
communication system. Thus, the various data elements contained in a given LRIT
message will have to be "formatted" as such. The question of whether
application software residing at the CSP or ASP (not software on the shipborne
equipment) begins to format the data elements into an LRIT message (SOAP using
XML) as defined in the communications document is another issue. Currently, the
document is written such that the CSP (for the International Data Centre
case) begins to build SOAP messages and pass them to the ASP. We have to
define an interface between the ASP and the CSP for the International Data
Centre case. If we allowed CSPs to transmit information to the ASP using
different formats, protocols, etc than it wouldn't be fair to the ASP. This
would add an extra cost burden on the ASPs given that they would have to
support multiple formats, protocols, etc. Please note that national data
centers and regional data centers are free to define and allow different
formats, protocols, etc from the CSP to the ASP.
The intention of the LRIT
communications document shall be to specify the data elements transmitted by
the shipborne equipment as stated in Brian's previous e-mail:
Shipborne Data Elements:
Latitude -> degrees, minutes and decimal minutes to two
decimal places N / S
Longitude ->degrees, minutes and decimal minutes to two
decimal places E / W
Unique equipment ID ->
number
Year -> 4 digit year
number
Month -> 2 digit month
number
Day -> 2 digit
day number
Hour -> 2 digit hour
number
Minute -> 2 digit
minute number
Regards,
Craig Hayley
From: Brian
Mullan [mailto:Brian_Mullan@inmarsat.com]
Sent: Friday, June 01, 2007 6:18
AM
To: Hayley, Craig
Cc: ccglrit-gcclrit@lists.ncf.ca
Subject: RE: [Ccglrit-gcclrit]
June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT,
Hamburg Germany
Hi, Hayley
Many thanks for your
email. I can agree that the text of the document is clear; but that the wording
in the table is not consistent and appears even to contradict the text you
quote. My copy of the document shows wording for 1.1.1.1 that is different:
“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.211(81).”
Your reference is new
text in 2.2.2.4 in the copy that I received (15-02-2007 LRIT ad hoc WG)
In Table 2, the heading
indicates “Parameter provided by LRIT Shipborne Equipment” and then
describes the various elements, including
specifying the format. It is clear to me and others that this
method of presenting the information in the table means that the information
transmitted by the shipborne equipment *must*
follow the format written in the table. This is where the difficulty lies
– the wording is over-prescriptive and does not accord with the wording
in 2.2.2.4. My original email showed how, in Inmarsat C position reporting at
least, the way the information is transmitted. Other shipborne systems probably
will have their own format for presenting data to the ASP.
May I suggest, please,
that we stick to requiring that the specific data elements (unique identifier,
latitude/longitude and date/time of the position) are transmitted from the ship
and then only start to prescribe the format for onward transmission from the
ASP? In other words, as long as the shipborne equipment transmits, as a
minimum, the required elements, any
format is acceptable. This allows for all approved shipborne LRIT systems to be
offered, no matter in which order or format the data is presented. This
approach will also allow the table to be in accord with the new wording in
2.2.2.4
I hope that this is
clear. Your hard work is very much appreciated and it is clearly understood
that the document remains a “work in progress”. Please don’t
take my input as criticism – it is not! All I seek is clarity of the
wording for all.
With best wishes
Brian
Brian Mullan
Head, Maritime Safety
Services
Inmarsat,
Tel: +44 (0)20 7728 1464
Fax: +44 (0)20 7728 1689
Mob: +44 (0)7711 495836
From: Hayley, Craig
[mailto:HayleyCR@DFO-MPO.GC.CA]
Sent: 31 May 2007 19:05
To:
Cc: Brian Mullan
Subject: RE: [Ccglrit-gcclrit]
June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT,
Hamburg Germany
Hi Brian,
Thanks for the e-mail. I
hope more people will take the time to read the documents and provide comments.
I assume you are referring to the LRIT communication document.
Please note the following
text in the LRIT communications document:
1.1.1.1 The
parameters added by the LRIT shipborne equipment include the latitude,
longitude, Time Stamp when the position was generated, and the shipborne
equipment identifier. The “Format” of these parameters as outlined
in table 2 indicates how the parameters shall be formatted while the
Regarding your concerns
with the format of the date/time... The only difference that I can detect
between the date/time you state and what is in Table 2 of the LRIT communications
document is the separators ("-" versus ":") for the year,
month, day, hour and minute. The separator used to separate the year, month,
etc in the date stated in table 2 is not important and in no way linked to
the format coming out of the shipborne equipment. The format is with respect to
SOAP messages communicated along the various LRIT communication segments. CSPs
for the IDC shall have to "build" SOAP messages complying with
table 2 in the communications document using the format from the ship borne
equipment. The important thing with the time stamp is that seconds are not
transmitted.
Regarding your concerns
with the format for latitude... We had a discussion on your e-mail and the
intention was to implement your recommendation. I can't recall why the
"seconds" component of the latitude didn't change to decimal
minutes with a precision of 2 decimal places. The most likely reason is
that I forgot to incorporate this change in the document due to the numerous
requests. My apologies on this topic. I will make the change for latitude to
decimal minutes unless someone raises a compelling reason not to change. Any
body from the Communications group recall if there was a specific reason why we
didn't make the change (Jilian, Guy, etc.)???
I would like to high
light to everyone that these documents are in constant flux as a result of many
requests from different inputs at the Ad Hoc meeting. Thus, it is important to
fully read the documents that come out of each meeting to ensure that any particular
topic of interest is addressed in a satisfactory manner.
Thanks,
Craig Hayley
System Engineer
Canadian Coast Guard
709-772-7740
From:
ccglrit-gcclrit-bounces@lists.ncf.ca
[mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On
Behalf Of Brian Mullan
Sent: Thursday, May 31, 2007 12:35
PM
To:
Subject: Re: [Ccglrit-gcclrit]
June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT,
Hamburg Germany
Thanks,
In table 2 I note that
the format of date/time is still shown as YYYY-MM-DD-HH-MM. My earlier email
(attached) made comment on this. Also in Table 2, note appears to have been
taken of my comments regarding latitude/longitude position for Longitude only,
but ignores Latitude.
We must not start requiring
reformatting for transmitted data that is already designed into existing
shipboard equipment – PLEASE!
Many thanks
Brian
Brian Mullan
Head, Maritime Safety
Services
Inmarsat,
Tel: +44 (0)20 7728 1464
Fax: +44 (0)20 7728 1689
Mob: +44 (0)7711 495836
From:
ccglrit-gcclrit-bounces@lists.ncf.ca
[mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On
Behalf Of Peverett, Tracy
Sent: 29 May 2007 22:27
To:
Subject: [Ccglrit-gcclrit] June
12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT,
Second of two
e-mails
As promised, attached please find the updated LRIT
Communications specification.
Best regards
Tracy
Tracy
Peverett
Senior
Policy Analyst
Canadian
Coast Guard
Tel:
1-613-990-4046
Fax:
1-613-998-3255
e-mail:
peverettT@dfo-mpo.gc.ca
This
email and any files transmitted with it are confidential and intended solely
for the use of the individual or entity to whom they are addressed. If you have
received this email in error please notify the system manager. In accordance
with Inmarsat Information Security Policy and Guidelines on Computer use,
emails sent or received may be monitored. Inmarsat plc, Registered No 4886072
and Inmarsat Global Limited, Registered No. 3675885. Both Registered in
_____________________________________________________________________
This e-mail has been scanned for viruses by Verizon Business Internet Managed
Scanning Services - powered by MessageLabs. For further
_____________________________________________________________________
This e-mail has been scanned for viruses by Verizon Business Internet Managed
Scanning Services - powered by MessageLabs. For further information visit
http://www.verizonbusiness.com/uk
_____________________________________________________________________
This e-mail has been scanned for viruses by Verizon Business Internet Managed
Scanning Services - powered by MessageLabs. For further information visit
http://www.verizonbusiness.com/uk