AERONAUTICAL COMMUNICATIONS PANEL (ACP)
WORKING GROUP M
FIFTH MEETING OF THE IRIDIUM SUB-GROUP
Montreal, Canada 22-24 August, 2006
REPORT
1. General
1.1 The fifth meeting of the Iridium Sub-Group of the ACP Working Group M was held 22-24 August, 2006 at ICAO Headquarters. The meeting was chaired by Robert Kerczewski, NASA Representative nominated to chair by the United States.
1.2 The meeting was attended by: Robert Kerczewski (NASA); Torsten Jacob (ICAO); Robert Witzen (ICAO); Mike Meza (Iridium); Hon Lam (Iridium); Donna Bethea-Murphy (Iridium); Brian Pemberton (ARINC); Brent Phillips (FAA); Jon Pendleton (Northwest); Nikos Fistas (Eurocontrol); Don Thoma (Iridium); Steve Henriksen (ITT); and Kevin Stevens (NavCanada).
1.3 The agenda for the meeting was reviewed and approved with the addition of two items: “Review of AMS(R)S SARPS Status” and “Visit to SITA”, inserted as agenda items 5 and 6.
1.4 The minutes from the fourth Iridium Sub-Working Group meeting were approved without comment.
2. Review of AMS(R)S SARPS Status
2.1 Mr. Torsten Jacob provided an initial review of Working Paper 5, Draft AMS(R)S SARPs State Letter Responses. Following comments and suggestions on Draft SARPS text improvements from Mr. Nikos Fistas, Mr. Jacob reviewed comments received by ICAO in response to the State Letter from Eurocontrol, France, the United States, Inmarsat, and the United Kingdom. Comments from Inmarsat were of a technical nature and the Subgroup was advised to review the material prior to further discussion planned for the second day of the meeting.
2.2 Mr. Fistas provided further overview of his and Eurocontrol’s comments: Eurocontrol, in light of the continuing development of performance based requirements, would like to note that some performance requirements in the draft SARPS are restrictive compared to the potential performance of satellite systems and would like to be able to make it clear that satellites can exceed these performance requirements. Mr. Robert Witzen noted that the commission instruction was that the SARPS changes cannot affect current implementations – so very little could be changed unless Inmarsat agrees. But perhaps a general comment can be made that more stringent parameters might be needed in certain airspace and then refer to particular manuals. With respect to the Iridium manual, the parameters from the SARPS are noted, and the values Iridium can satisfy can be mentioned. Mr. Jacob further clarified that the proposal is to come up with figures that could enable use in other non-oceanic airspace – the performance requirements in the SARPS do not give the performance required to cover all airspace. However, Mr. Fistas noted that this is a longer-term problem which will need to be addressed.
3. Review of current IRIDIUM MANUAL VERSIONS
3.1 Mr. Jacob provided comments on how to merge the technical and implementation manual and also comments on technical specifications, in Working Paper 2. Working Paper 6 is Mr. Mike Meza’s proposal to combine the two manuals into one document, based upon Mr. Jacob’s comments. Mr. Witzen provided comments on the manual in Working Paper 4. These working papers were reviewed during the first day. The discussions are summarized below.
3.2 Review of Working Paper 2. Mr. Jacob prepared comments on the manual structure to create a more generic manual that would have the flexibility for future amendments if necessary. In Section 4 on spectrum availability, some further information will be required regarding the coordination of spectrum use for ATC safety service operations with other non-safety users. Mr. Nikos noted that some generic information on the current situation with AMS(R)S allocations needs to be included. Mr Jacob added further that the situation with Iridium and what is required to satisfy the generic requirements must be explained in section 4.2. Mr. Witzen suggested that material be introduced on the L-bands ( 1.5 and 1.6 GHz) and the difficulties of aviation getting bandwidth there, followed by some specific material on Iridium. Mr. Jacob proposed one further addition, an item or appendix giving generic information on ATN specific information on using Iridium as a subnetwork on ATN. The final item involves Table 8.1 and the discussions at IRD-SWG04 regarding the need to consider end-to-end performance. Mr. Jacob further reviewed the draft SARPs and concluded that the figures in the SARPS really are subnetwork values only. End-to-end performance requirements are given in the ATN manual. Values given for different classes of services, and can be referenced for end-to-end system performance requirements. The final column of Table 8 can thus be deleted.
3.3 Review of Working Paper 4. This working paper reflected further comments on Working Paper 2 by Mr. Witzen, proposing changes intended to generalize the manual, improve logical arrangement of material, and in particular to make the information in the manual that is Iridium specific more in the line of aeronautical service Iridium can provide rather than the more general material earlier in the manual.
3.3.1 The need to describe specific points to implement ground stations or communications established with the ground through a ground station was identified. It needs to be understood if direct access to ground stations is required to obtain a shorter ground link, and how that access would be obtained.
3.3.2 Mr. Witzen provided a number of important clarifications and other improvements to the text. Availability material could be inserted into section 2.2.4 where reliability and integrity are described. A discussion on interoperability between different service providers produced the conclusion that for data this need not be addressed, as network interoperability at the ATN layer is adequate. For voice however, interoperability may need to be discussed.
3.3.3 Mr. Witzen noted that the Operational Benefits section should be restructured to describe benefits to the operation of the aircraft, not the communications. More specific information on standardization activities – for example MOPS (MPS in Eurocae), material on ICAO SARPs, etc., is needed. The goal is first to identify AMS(R)S specification in general, then ICAO material, standards and characteristic, MOPS, etc.
3.3.4 Changes were proposed regarding institutional arrangements, reference to the 10th Air Navigation Conference was made.
3.3.5 Discussion of the subject of spectrum availability, expansion of this chapter is necessary, in particular in the 1.5/1.6 GHz band, where there is a primary allocation to AMS(R)S and AMSS.
3.3.6 The ATN/IPS section addresses the use of Iridium as an ATN compatible subnetwork. Some networks in the aircraft may be OSI-based ATN, but ICAO is in the process of replacing some of this with IP services.
3.3.7 The material addressing the Iridium satellite network should address the aeronautical terminal rather than Iridium handset. It was noted that figure 2-1 shows a network in the US, but in general we are interested in a network in North Atlantic, Africa, and any other area. Although the figure is intended to be general and applicable to any area, it is suggested that it be amended to demonstrate a more general application. We would like to suggest how the networks be implemented with the shortest possible ground path. For example, a mobile terminal can act as a ground terminal.
3.3.8 Material describing interference to and from Inmarsat generated discussion of the plausibility of an airline installing both Inmarsat and Iridium on the same aircraft. Mr. Jon Pendleton (Northwest Airlines) noted that Northwest may at some point wish to install Iridium as a backup system – currently aircraft are having Inmarsat installed. Hence interference issues regarding dual installations appear to be relevant. Mr. Brian Pemberton noted that the service provider would enable that a particular message would be routed by the CMU as configured, and the likelihood is that you would not have one transmitting and one receiving at the same time, unless you had two different service providers. Mr. Steve Henriksen noted that AEEC is also dealing with this issue and Mr. Witzen agreed that AEEC and other sources should be considered.
3.4 Presentation of Working Paper 3, “Future Communications Study Technology Evaluation – SATCOM Availability Analysis”, by Mr. Henriksen. The paper was presented using a PowerPoint presentation (included as Working Paper 7). The presentation was well received. Mr. Kerczewski suggested that ITT has demonstrated a methodology which can be applied, perhaps with improved assumptions and measurements based on Iridium’s operational experience, to create an availability number for the manual. Mr. Jacob added that the material presented may be of value in addressing the Working Group M recommendation regarding availability. Mr. Kerczewski agreed to request assistance from Mr. Chuck LaBerge of Honeywell in drafting a brief paragraph regarding Iridium availability, based on the ITT work.
Day Two – 23 August 2006
3.5 Review of the comments on the draft AMS(R)S SARPS. In reviewing the various comments received, Mr. Jacob noted the ICAO desire to minimize the number of changes.
3.5.1 Mr. Fistas reviewed his comments. Some editorial comments were proposed. In the definitions, Mr. Fistas suggested a drawing be put into the manual, and Mr. Meza agreed that it could be inserted where the end-to-end models have been added – in line with ISO 8348. Regarding the SNSDU definition, Mr. Fistas will check on whether there is a definition for that in 8348.
3.5.2 The section 4.2.1.1 recommendation was discussed, as it is a general recommendation to AMSS in general and not to AMS(R)S systems and may not belong. Mr. Phillips suggested that this may be a remnant from an AMSS document, however no AMSS SARPS exist anymore. It was noted that France also commented about this. So two options are to keep it or remove it – Mr. Jacob noted that to remove it might constitute a change significant enough to require another state review of the document.
3.5.3 In Section 4.4.1, Mr. Fistas asked if this refers to intra- or inter- system priority and pre-emption. It was noted that studies suggest that inter-system priority and pre-emption is not feasible. But the proposal was to leave this section unchanged.
3.5.4 Section 4.6.2 – It is unclear on who needs to act; France also commented on this. Mr. Jacob noted that this refers to the fact that the AMS(R)S system has to make information available, it is not an operational issue. Mr. Don Thoma described Iridium’s process of providing failure notification. In practice, a notice would be sent to ARINC operations people who then are responsible to notify their users. Mr. Permberton noted ARINC’s processes in place for automatic notification to all dispatch centers through e-mail or a ground-ground message. Escalation procedures may involve phone calls, etc., dependent on severity of outage, customer, etc. So, Iridium’s responsibility is to notify the service provider, who would then have the escalation process in place to inform the end users/customers. The service provider would decide if there is a service impact.
3.5.5 It was noted that Section 4.6.4.1.1 is redundant with item 4.7.2.1. Mr. Fistas noted that Section 4.7.2.2 is not really an interface specification, and further is defined in ATN specifications. There are many other requirements in ATN that are not listed here. Mr. Jacob agreed to investigate this further, in terms of what is in the ATN SARPS and the NGSS SARPs, what happened to this merger. Section 4.6.4 discusses packet data performance, and Mr. Fistas proposed merging 4.6.4.1.1 into 4.7.2. France proposed deleting 4.7 altogether, and Mr. Fistas agreed with that position.
3.5.6 Section 4.6.4.1.2.3 – It was noted that Inmarsat requested the value be changed from 23 to 40, as well as several other numeric changes. Mr. Jacob believed these changes must be accepted, although they are being proposed very late in the process. A discussion ensued on the fact that these numbers represent minimum values, but they are not necessarily the values that can currently be achieved by systems, nor are they the values that are required in some airspace domains. Mr. Fistas proposed to note in the document that ICAO is working to define operational parameters for different airspace and operational domains. But the SARPS must allow existing systems to operate. Mr. Jacob agreed to contact Inmarsat to verify that they have the same understanding that these are subsystem performance numbers and not end-to-end performance numbers.
3.5.7 In section 4.6.4.1.3 on integrity, it was proposed to change the reference to change to residual “block” error rate, in the text as well as the subsection title. Mr. Lam agreed that DO-270 does use block error rate. France had proposed referring simply to bit error rate in these sections, but Mr. Lam pointed out that block, packet, and SNSDU error rates are different from bit error rate. Mr. Kerczewski proposed to state that the residual SNSDU error rate shall not be greater than 10-6 and change subsection titles and other parts similarly.
3.5.8 The US comment on Section 4.6.5.1.3 was that there might be a problem using Voice over IP. An approach has not yet been identified, and Mr. Phillips agreed to contact the source and see if they can propose a solution or further explanation of what they mean.
3.5.9 Inmarsat comments have all been covered above. Mr. Fistas noted that there were only four numeric changes that Inmarsat was requesting.