[Smwg] TBD RIDs - Current Status
Colin.Haddow at esa.int
Colin.Haddow at esa.int
Wed Nov 19 15:24:06 UTC 2014
Dear all,
after the RID review in London there were still 4 RIDs
where the disposition was TBD, please find below my proposed disposition of 3
of these
Martin note that what I propose with respect to the use of frequency band in
the unused time case will affect the updates to your diagram and supporting
text.
NASA - 26 (also affects responses to NASA-11 and JMS06 (CNES))
RID
The frequencyBand parameter would be more useful to potential user if the
free time antenna's frequency band were specified.
For example, NASA's Space Network TDRS satellites Single Access (SA) antennas
can support S-band, Ku-band, and some can support Ka-band, but not all TDRS
satellites can do that.
When a user wants to use Antenna Free Time, and sees that, for example,
TDRS-6 SA antenna 1 is free, but it cannot support Ka band. The potential
user would not know that until, possibly, too late to make use of the Free
Time.
Proposed Response
Agreed, for the case of unused time it shall be possible (but not mandatory)
to specify a frequency band. This would be done as follows (NOTE what is
suggested also requires the addition of the value ALL to the permitted
frequencyBand values);
To specify unused time on a particular ban of an Antenna the following would
need to be specified;
ScheduledPackage.user NETWORK (as per agreed
updates)
ScheduledActivity.StationRef specify the Station
ScheduledActivy.AntennaRef specify the Antenna (NOTE:
This parameter will be mandatory after the update)
ServiceInfo.frequencyBand specify the Band or ALL (ALL
being specified if all frequency bands supported by the antenna are
UNUSED)
ServiceInfo.serviceType UNUSED
IM-001 (Eumetsat)
RID
It is suggested to add an additional but optional parameter, after the “user”
one, in order to be able to provide if desired an informal name to the
official SANA spacecraft name. E.g. “Metop-B” or “M02” instead of “METOP1
S-)”. This additional parameter is only intended for extra information, to
complement the “user” name for the sake of clarification. The particular user
to decide whether to use this field or not and to decide the “informal”
spacecraft name. This could for ease of understanding.
Proposed Response
Agreed: An optional comment parameter will be added to the ScheduledPackage
class that may be used for the provision of "informal" spacecraft names or
other ad hoc information.
HH-04 (Eumetsat)
RID
EUMETSAT exchange files with both NASA (WOTIS/NENSE) and NOAA at least 3 to 4
times per week. Each of these exchanges use completely different file
formats.
Unfortunately I cannot align either of the file formats to the example shown
in figure B-3.
Were these files taken into consideration when this “Simple Schedule Format
Specification” was specified?
(Examples omitted)
Proposed Response
Pending result of action 2014-1110-03 "Look at the test report and provide any
comments on mapping to SN or NEN items for EUMETSAT RID HH004. (Perform
analysis relative to test report and as to ability to map to proposed
standard.)" Due date 9-Dec-14
JMS06 (CNES)
RID
Consider making “antennaref” a required and not an optional parameter.RID
Supporting Analysis
The cases when this parameter is relevant are many more than those where it
is not: multiple antennas per station to be differentiated ; antennas with
different sizes, frequency bands and performances (not equivalent to support
satellites) ; having different location or transit times (processing of
localization data or time synchronization); …
Without this information, the information on unallocated time becomes
meaningless to the users: availability is per antenna that may actually
provide a support and not per station (as a group of adequate and not
adequate antennas).
In CNES experience, only antennas are allocated, not stations.
To some extent, "stationRef" could be optional... but this RID doesn't
propose that change as it doesn't hurt to have it a required parameter.
Proposed Response
Agreed: antennaRef will be made mandatory.
Cheers for now,
Colin
---------------------------------------------------------------------------------------------------------
Dr. Colin R. Haddow,
HSO-GI, European Space Agency,
European Space Operations Centre,
Robert-Bosch-Str 5,
64293 Darmstadt,
Germany.
Phone; +49 6151 90 2896
Fax; +49 6151 90 3010
E-Mail; colin.haddow at esa.int
---------------------------------------------------------------------------------------------------------
This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
More information about the SMWG
mailing list