10:29 a.m.
All
The relationship between the CSP and the ASP is already covered by the
CSP's terms of business. These are very carefully constructed
documents, based on years of legal practice and interpretation. If we
seek to get involved in that relationship IN ANY WAY we stand in danger
of making it more difficult for CSPs to participate in the system and
can damage the contractual relationship between them and the ASPs. That
would be unwise. In any case, I do not believe it will be necessary.
There is nothing wrong with putting this load on to the ASP's , because
it is a primary and significant part of the role they play in the
current voluntary system. They have much more to do than just clean up
the data, enhance it as required and pass it on to the DCs. I have not
yet seen any case being made to restrict their role in this way. All
the (potential) ASPs I have spoken to so far have accepted that it will
be part of their role to interface with multiple CSPs. If there is
evidence to the contrary, please may we see it, before we go off at a
tangent on this.
We ought not to leave this entirely for discussion in Hamburg - not
every one can be there and, as we have seen at other meetings, the pace
of the session may not leave time for sensible consideration of such
issues.
Andy
Andy Fuller
Head of Operations
International Mobile Satellite Organization
99 City Road, London EC1Y 1AX, UK
Tel. + 44 (0) 207 728 1378
Fax + 44 (0) 207 728 1172
E-mail: andy_fuller(a)imso.org
www.imso.org
-----Original Message-----
From: ccglrit-gcclrit-bounces(a)lists.ncf.ca
[mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Hayley, Craig
Sent: 04 June 2007 15:18
To: ccglrit-gcclrit(a)lists.ncf.ca
Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working
Group onEngineering Aspects of LRIT, Hamburg Germany
All,
If we do not specify the interface between the CSP and the ASP than the
ASP will have to accept any deliver mechanism (or payload format for
that matter) that any CSP outputs. Thus, ASPs will be responsible for
accepting quite a variety of interface protocols. This will include not
only standard commercial interfaces that are being used by commercial
ASPs and CSPs today, but potentially also interfaces from contracting
governments "entities" that are acting as CSPs.
Consider the following scenario... A contract government with some sort
of Vessel Monitoring system (VMS) that is not interested in LRIT but
understands it has to comply with IMO regulation. It chooses to call a
subsection of its VMS system a CSP and informs the LRIT Co-ordinator
that its CSP (and its flag ships) will connect to an ASP connected to
the International Data Centre. Given that the CSP to ASP interface is
not specified in the LRIT communications document, the ASP is compelled
to accept a potentially non commercially available unique interface from
the contract government's CSP. If this scenario repeats itself with
other contracting governments than the ASPs could be in for an expensive
design process. Based upon the text in the LRIT performance standards,
it would seem that a contracting government could define an internal
"entity" as a CSP and wish it to connect to an ASP connected to the
International Data Centre.
Given the various views and the desire to protect the ASPs from having
to accept "any" interface, I will suggest the following to the group.
Text will be added such that ASPs and CSPs can form an "informal"
partnership if both entities agree to each others terms. An "informal"
partnership could be as simple as exchanging letters. The communication
interface between the CSP and ASP in such a situation will be deemed an
internal communication link and will not be subject to "specific"
communication protocols and formats. The communication link, of course,
would have to adhere to the LRIT performance standards and "generic"
functional standards described in the Communications document. The
communications document will continue to provide some boundaries and
specific specifications to the CSP to ASP interface for ASPs and CSPs
that do not have "informal" partnerships.
We can discuss in Hamburg next week.
I may touch base via phone with some members to discuss this issue.
Regards,
Craig Hayley
System Engineer
709-772-7740
-----Original Message-----
From: ccglrit-gcclrit-bounces(a)lists.ncf.ca
[mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Andy Fuller
Sent: Monday, June 04, 2007 10:30 AM
To: ccglrit-gcclrit(a)lists.ncf.ca
Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working
Group onEngineering Aspects of LRIT, Hamburg Germany
Craig
I agree with Jeff and Ralf. We should keep well out of specifying any
formats or procedures for the CSP. To do so will slow down and damage
development of the system.
Andy
Andy Fuller
Head of Operations
International Mobile Satellite Organization
99 City Road, London EC1Y 1AX, UK
Tel. + 44 (0) 207 728 1378
Fax + 44 (0) 207 728 1172
E-mail: andy_fuller(a)imso.org
www.imso.org
-----Original Message-----
From: ccglrit-gcclrit-bounces(a)lists.ncf.ca
[mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Ralf-Dieter
Preuss
Sent: 04 June 2007 13:40
To: ccglrit-gcclrit(a)lists.ncf.ca
Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working
Group onEngineering Aspects of LRIT, Hamburg Germany
Craig,
I agree with Jeff:
everything beyond the DC is up to the contracting government; it is not
necessary and maybe even not helpful if we specified the interface
between CSP and ASP. The format used between ASP and DC could be quite
the same as described in the COMMs paper; at least that is what is
beeing discussed here with companies interested in the CSP/ASP services.
Best regards
Ralf
---------------------------------------------------------
Bundesamt fuer Seeschifffahrt und Hydrographie (BSH)
Ralf-Dieter Preuss (S3)
Bernhard-Nocht-Str. 78 Tel: +49 (0) 40 3190-7300
20359 Hamburg Fax: +49 (0) 40 3190-5000
http://www.bsh.de/ email: ralf-dieter.preuss(a)bsh.de
---------------------------------------------------------
Jeff Douglas schrieb:
Our view is that the earliest point in the LRIT infrastructure where
sufficient information is available to standardize a format is at the
ASP.
and
It is actually quite
possible that there would be fewer ASPs than CSPs in practice once >
LRIT is
deployed.
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
www.absolutesw.com <http://www.absolutesw.com/>
------------------------------------------------------------------------
*From:* ccglrit-gcclrit-bounces(a)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(a)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
Hamburg meeting, the document will be aligned with the
"consensus"
view.
Regards,
Craig Hayley
System Engineer
Canadian Coast Guard
------------------------------------------------------------------------
*From:* ccglrit-gcclrit-bounces(a)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(a)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, 99 City Road, London EC1Y 1AX, UK
Tel: +44 (0)20 7728 1464
Fax: +44 (0)20 7728 1689
Mob: +44 (0)7711 495836
www.inmarsat.com <http://www.inmarsat.com>
------------------------------------------------------------------------
*From:* Hayley, Craig [mailto:HayleyCR@DFO-MPO.GC.CA]
*Sent:* 01 June 2007 13:52
*To:* Brian Mullan
*Cc:* ccglrit-gcclrit(a)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 Hamburg.
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(a)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, 99 City Road, London EC1Y 1AX, UK
Tel: +44 (0)20 7728 1464
Fax: +44 (0)20 7728 1689
Mob: +44 (0)7711 495836
www.inmarsat.com <http://www.inmarsat.com>
------------------------------------------------------------------------
*From:* Hayley, Craig [mailto:HayleyCR@DFO-MPO.GC.CA]
*Sent:* 31 May 2007 19:05
*To:* ccglrit-gcclrit(a)lists.ncf.ca
*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 information is contained within the LRIT message
and
does not specify the format of how the shipborne equipment transmits
the
information.
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(a)lists.ncf.ca
[mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] *On Behalf Of *Brian
Mullan
*Sent:* Thursday, May 31, 2007 12:35 PM
*To:* ccglrit-gcclrit(a)lists.ncf.ca
*Subject:* Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc
Working Group onEngineering Aspects of LRIT, Hamburg Germany
Thanks, Tracy
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, 99 City Road, London EC1Y 1AX, UK
Tel: +44 (0)20 7728 1464
Fax: +44 (0)20 7728 1689
Mob: +44 (0)7711 495836
www.inmarsat.com <http://www.inmarsat.com>
------------------------------------------------------------------------
*From:* ccglrit-gcclrit-bounces(a)lists.ncf.ca
[mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] *On Behalf Of *Peverett,
Tracy
*Sent:* 29 May 2007 22:27
*To:* ccglrit-gcclrit(a)lists.ncf.ca
*Subject:* [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working
Group onEngineering Aspects of LRIT, Hamburg Germany
_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(a)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 England and Wales
with Registered Office at 99 City Road, London EC1Y 1AX.
_____________________________________________________________________
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
_____________________________________________________________________
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
------------------------------------------------------------------------
_______________________________________________
Ccglrit-gcclrit mailing list
Ccglrit-gcclrit(a)lists.ncf.ca
http://lists.ncf.ca/mailman/listinfo/ccglrit-gcclrit
_______________________________________________
Ccglrit-gcclrit mailing list
Ccglrit-gcclrit(a)lists.ncf.ca
http://lists.ncf.ca/mailman/listinfo/ccglrit-gcclrit
_____________________________________________________________________
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
_______________________________________________
Ccglrit-gcclrit mailing list
Ccglrit-gcclrit(a)lists.ncf.ca
http://lists.ncf.ca/mailman/listinfo/ccglrit-gcclrit
_______________________________________________
Ccglrit-gcclrit mailing list
Ccglrit-gcclrit(a)lists.ncf.ca
http://lists.ncf.ca/mailman/listinfo/ccglrit-gcclrit
_____________________________________________________________________
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