ITU-R WP-4C Working Document€¦ · Web viewThe present working document is intended to be the basis for development of such an ITU-R Recommendation. This document presents some

Radiocommunication Study Groups

Source: Documents 4C/39 (Annex 7), 67, 81, 86, 87

Subject: Resolution 422 (WRC-12),Question ITU-R 83-6/4

Document 4C/TEMP/47-E17 September 2012English only

Annex 14 to Working Party 4C Chairman’s report

WORKING DOCUMENT IN RESPONSE TO RESOLUTION 422 (WRC-12)

General principles, guidelines and example methodology(ies) to calculate spectrum requirements to satisfy AMS(R)S access within

the bands 1 545-1 555 MHz (space-to-Earth) and 1 646.5-1 656.5 MHz (Earth-to-space)*

1 IntroductionHaving an agreed methodology to calculate the spectrum needs of AMS(R)S communications within priority categories 1 to 6 of RR Article 44 of each AMS(R)S satellite network would assist MSS/AMS(R)S frequency coordination discussions by providing better estimates of the spectrum requirements of AMS(R)S systems, reducing overestimation of stated requirements and working towards more efficient use of scarce spectrum resources. Resolution 422 (WRC-12) invites ITU-R “to conduct studies on, and develop in one or more ITU-R Recommendations, a methodology, including clear definitions of input parameters and assumptions to be used, to calculate spectrum requirements within the frequency bands 1 545-1 555 MHz (space-to-Earth) and 1 646.5-1 656.5 MHz (Earth-to-space) for AMS(R)S communications related to the priority categories 1 to 6 of Article 44….” The present working document is intended to be the basis for development of such an ITU-R Recommendation. This document presents some principles and guidelines to help establish the essential elements for development and use of such methodologies.

NOTE – As a point of clarification, the introduction of a satellite system(s) into the communications infrastructure of the Air Traffic Management System has certain architectural implications. Rather than communicating directly with aircraft via air/ground radio links, the various ground facilities, e.g. air traffic control (ATC) centers, aeronautical operational control (AOC) centers, etc. are connected to the aeronautical earth station (AeES) via terrestrial links where the AeES is connected

* Any actions on Annex 16 to Document 4C/522 (Working document towards a preliminary draft new Report ITU-R M.[AMS(R)S SPECTRUM ESTIMATE] – AMS(R)S communication requirements forecasts and estimated future spectrum requirements) are held in abeyance pending further developments on this document. Attention: The information contained in this document is temporary in nature and does not necessarily represent material that has been agreed by the group concerned. Since the material may be subject to revision during the meeting, caution should be exercised in using the document for the development of any further contribution on the subject.

/TT/FILE_CONVERT/5E408DA057E0EB3ACA58EA44/DOCUMENT.DOC 19.09.12

- 2 -4C/TEMP/47-E

to the satellite via the earth to space and space to earth feeder links which may be in a frequency band different from the L-band. The satellite in turn is connected to the aircraft earth station (AES) via the L-band earth to space and space to earth service links. For a ground based center to communicate with an aircraft it would utilize the terrestrial link to the AeES, the earth to space feeder link, and the space to earth service link to the AES. This will simply be referred to as the forward direction. Likewise, for the aircraft to communicate with a terrestrial center it would utilize the AES, the earth to space service link, the space to earth feeder link to the AeES and finally the terrestrial link to the appropriate center. This will simply be referred to as return direction.

2 General principles and guidelines for development of the methodologiesThe following presents principles and guidelines to help establish the essential elements for development and use of methodologies to calculate AMS(R)S spectrum needs in the 1 545-1 555 MHz band for the forward requirements and 1 646.5-1 656.5 MHz band for the return requirements on an ongoing basis for purposes of bilateral and multilateral MSS coordination meetings conducted pursuant to Article 9 of the Radio Regulations:a) The methodologies should first and foremost provide accurate results avoiding

overestimation or underestimation of spectrum needs. To support this goal the most accurate input data available should be employed. The calculation methodology should reflect as closely as possible the algorithms actually employed by the satellite system under study.

b) The methodologies should provide a simple, efficient and quick means for determining spectrum requirements. In order to realize this goal, ambiguity should be minimized with pre-agreement on assumptions, estimates and other raw data employed in the study where possible.

c) The methodologies should support the present AMS(R)S environment but take into consideration changes to the environment during the target period, including changes in service offerings (for example AOC and ATS), traffic, equipage, and technology.

d) The methodologies should account for the equipage of the aircraft and satellite network. Only the services and transmission capabilities afforded by the communication equipment deployed on the aircraft, the AeES and satellite under study should be considered.

e) The methodologies should avoid double counting of the bandwidth for serving the communication traffic in areas with overlapping satellite networks coverage.

f) The information provided for each AMS(R)S satellite network, to be used as input parameters to the methodologies, should, to the extent possible, be independently verifiable.

g) Submitted input data should be associated with clear and adequate definition and/or description, as appropriate, without the need for any interpretation and should be delineated by service and operational volume as required to ensure proper allocation to AMS(R)S priority communications 1 through 6 per RR Article 44 and to satellite beams.

h) The number of alternative methodologies that may be employed to calculate the spectrum requirements should be minimized.

i) The methodologies should take into account only the communication traffic requirements of safety communications of the traffic forecast, i.e. the air traffic service (ATS) and aeronautical operational control (AOC) communications as they apply to priority communications 1 to 6 per ITU Article 44.


- 3 -4C/TEMP/47-E

j) The methodologies should account for only that portion of the AMS(R)S client’s airspace in which satellite communications would be employed such as by excluding airspace corresponding to areas in which VHF and HF communications are employed.

k) AMS(R)S spectrum needs for an airspace of interest should be provided in a format consistent with the system configuration and capabilities of AMS(R)S satellite network(s) operating within that airspace. For example:– Spectrum needs of an AMS(R)S satellite network with multiple spot beams

should be determined to the level of spectrum needs of each spot beam.– Proper measures should be taken into consideration where an AMS(R)S satellite

system is capable of dynamically configuring its satellite network resources.– Proper measures should be taken into consideration where an AMS(R)S satellite

network including: Aircraft and AeES communications equipment are capable of and support voice compression and/or data compression.

– Only AMS(R)S priority communications 1 through 6 per RR Article 44 supported by the satellite system beam under study should be included in the spectrum requirements calculation.

l) Other principles and/or guidelines, if any.

3 Example inputs and assumptions[Editorial Note: These example input parameters are to be further reviewed in future WP 4C meetings to establish their relevance to proposed methodologies.]This section identifies inputs and assumptions that have been identified by WP 4C during discussions, and forms a basis for the development of new Recommendation ITU-R M.[AMSRS.METHODOLOGY].

3.1 Inputs

Out of need, inputs may be based on known facts, measurements, historic or similarity inference, simulations, forecasts, and estimates. However, each input should be based on the most valid source available at the time of the coordination process. The list provided below gives examples of inputs that may be required to implement the methodologies to be developed.

It should be noted that all of the information contained in this section may not be needed as inputs to the methodologies to be developed and adopted in the ITU-R Recommendation.a) Detailed AMS(R)S satellite network characteristics establishing the network element

capabilities and limitations (e.g. satellite,, gateway facilities), and determining the ability to share resources, and provide certain services. As an example the following information may be needed:– satellite beam configurations (location and latitude/longitude boundaries),

antenna discrimination;– spot beam spectrum reuse factor;– satellite and earth station G/T, transponder BW and typical C/N0 available for

each beam;– number of aeronautical earth stations (AeES) providing AMS(R)S services

within the service area of the global beam and spot beams for each satellite network where the traffic is simultaneously handled by multiple AeESs;


- 4 -4C/TEMP/47-E

– number of simultaneous number of AES logged-on to a satellite during the busy hour;

– typical efficiency per beam (function of available power and bandwidth and carrier load);

– retransmissions as a percentage of throughput due to fading, interference and/or collisions for both addressed and broadcast data transmissions.

b) Detailed information concerning the air traffic characteristics (airliner, cargo, and general aviation) such as latitude/longitude boundaries of the air space and any crossing of these boundaries; flight routes and schedule, additional unscheduled flights that would typically be added by airliners; aircraft equipage, number of aircraft equipped with AES terminals and model of AES terminal registered with the satellite operator, to the extent available.

c) AMS(R)S terminal characteristics: This should be provided by the AMS(R)S satellite operator for all carrier types supported by its satellite system. Characteristics should include information such as:– bit rate as a function of C/N0;– service types supported: data, i.e. voice, broadcast, addressed, party-line;– reference information bit rate: pilot signals, channel feedback information;– signalling bits employed: data link signalling, acknowledgements, other;– error correction bits employed: coding, parity;– guard time bits; for TDMA carriers;– preamble bits;– range of message size, frame size, packet size, segment size, and window size;– other protocol information, e.g. header bits and , queuing algorithms used.This information might also be provided more generically, e.g. on a message basis with typical and maximum information and overhead bits provided.

d) Voice traffic characteristics: For example, the average Erlang load by aircraft is needed and might be provided via measured data or from statistical references. Table 6-24 of the “Communications Operating Concept and Requirements for the Future Radio System”, Version 2 (COCRv2) report (Reference 1) provides the ATS related party-line voice transmission characteristics based on a survey of studies.

e) Detailed information on AMS(R)S Data traffic characteristics: To support queuing model analyses, traffic characteristics for each priority service and any network management services are needed. These characteristics may include: service instance rate, message quantity and message sizes. However, what is needed for the queuing model is the message arrival rate, and the message size.

f) QoS performance requirements: Performance thresholds required include: transit delay (latency), integrity (bit error rate), availability of provision, and call establishment delay. Thresholds should be provided for each service class and airspace associated with priority communications, levels 1 to 6 specified in ITU-R Article 44 plus any network management service required. Reference [2] provides a cross-classification between


- 5 -4C/TEMP/47-E

ITU priority levels and COCR defined ATS and AOC communications1. This cross-classification is summarized in Table A1 of Appendix A. The COCR provides QoS threshold in compliance with RCTA defined parameters as well as safety and operational review results conducted as part of the COCR study. However the QoS requirements were based on air to air and air/ground/air communications so the QoS thresholds may need to be adjusted to account for the operational limits of satellite communication links.

g) Other miscellaneous data required by certain methods proposed include: beam configuration of the satellite during the busy hour, where the beam configuration could be adjusted dynamically:– percent of total airtraffic represented by each of the following types, commercial

passenger, commercial cargo, general aviation, and government. This would assist in developing assumptions of the equipage of aircraft and typical flight paths, which could impact the overall AMS(R)S spectrum requirements;

– number of aircraft equipped with an AES in specified airspace;– average volume of traffic to be handled by each AES for each type of aircraft

commercial passenger, commercial cargo, general aviation, and government. This would assist in developing assumptions of the equipage of aircraft and typical flight paths, which could impact the overall AMS(R)S spectrum requirements;

– growth rate of different types of AMS(R)S terminal types known in ICAO;– ratio of non-scheduled flights to scheduled flights using AMS(R)S equipped

aircrafts and their growth or decline ratio with respect to previous records;– expected terrestrial network (i.e. AM(R)S) growth in airspace of interest,

especially those that do not have complete coverage by terrestrial network for some concept proposed (in particular in Europe) this input parameter is redundant with the first example above);

– assumed growth of communication traffic in specific spot beams of a given network;

– percent of communications conducted via satellite when out of range of VHF;– satellite usage statistics for voice and data broadcast transmissions;– average number of aircraft for which a forward broadcast transmission is

intended for;– AOC & ATS voice statistics;– Averaged unit information volume (Erlangs) for circuit switched voice traffic to

be handled by a satellite system (Va).

1 The COCR provides statistical communications traffic data for the various aircraft communications that typically take place throughout different phases of a flight. However, not all of these communications pertain to AMS(R)S communications, for instance some of these communications could be supported via terrestrial AM(R)S communications. For the COCR data to be accurately employed in the methodology three factors must be properly accounted for: 1) Only traffic associated with AMS(R)S should be used. 2) Of the above traffic, only that which can be supported by the satellite system under study should be used. 3) Message lengths should be adjusted to account for limitations of transmission protocols employed by the satellite versus the terrestrial air to ground links assumed in the COCR.


- 6 -4C/TEMP/47-E

3.2 Assumptions

There are a number of assumptions that come into play in the development of the spectrum requirements. In some cases, they help to simplify or speed up the computation process and in others they arise out of practical necessity.

Appendix C to Attachment 1 provides an analysis illustrating the relationship of different computed spectrum requirements of an AMS(R)S satellite network to the associated assumptions used in the calculations. The following is a running list of assumptions made concerning the proposed methodology. Validity of these and any other assumptions needs to be verified in advance of adopting any proposed Methodology.– Only services which are planned to be operated on a particular satellite system are

considered. Currently, AMS(R)S services are limited to the En-Route (ENR), the Oceanic, Remote and Polar (ORP) domains, but in the future AMS(R)S services may be used in Airport (APT) and Terminal Manoeuvring Area (TMA) flight domains. The methodology should be sufficiently flexible to address AMS(R)S operations in any flight domain. [Editorial Note: The term ORP as used in this document is intended to refer only to the oceanic and remote region and does not include the polar regions not covered by GSO satellites]

– Care needs to be taken to consider only the communication messages which can and would be carried by the satellite network. For example, some communication requirements may have latency requirements that cannot be met by GSO satellite systems and services which are used in terrestrial domains are not a load on satellite systems at present and therefore would not be included in the near term spectrum requirements computation.

– References to addressed data or voice as used in this document refers to communications in which information is exchanged between two users and should be assumed as two-way unless otherwise noted.

– Network Management Services: While transparent to end user operations, the satellite system is assumed to be part of the network providing communications. The network requires connection and routing communication. This network management traffic which is specific to the satellite system under study is anticipated to flow over the satellite to enable the provision of ATS and AOC services. Therefore, load attributable to this traffic is included in the same manner as other services in the calculation of the spectrum requirements.

– Assumptions should be made concerning minimum requirements for voice channels and based on how voice might be deployed within the AMS(R)S environment. Possible options include: one addressed voice channel provided at a minimum per beam; one party-line voice channel provided at a minimum per airspace control sector (noting a beam may contain many airspace control sectors); and one broadcast voice channel(s) provided within the beam. At present, no party-line voice channels or broadcast channels are used for AMS(R)S services.

– The number of AESs operating in a given beam in a given period may be estimated from historical data. Where such data does not exist, the number of AESs could be estimated from the following:i) Analysis of flights could generally be carried out by counting the number of

flights passing through the airspace under consideration in a given time interval.


- 7 -4C/TEMP/47-E

ii) The number of the aircraft operating can also be obtained by analysing airlines timetables.

iii) Considerations shall also be needed on the ratio of satellite equipped aircraft (AES).

– In the case of return broadcast mode of operation, the effect of uncontrolled communication message collisions would need to be taken into consideration.

– For the purpose of computing traffic loads and providing subsequent spectrum requirements ATS and AOC traffic may be combined but forward and return traffic should be kept separate.

4 Example methodologiesExample methodologies to calculate AMS(R)S spectrum requirements are described below.

The methodologies take into account the number of aircraft equipped with an AES in the specific airspace of interest, potentially using one or more satellite networks and each specific satellite’s communication requirements and technical characteristics such as satellite beam configuration.

Attachment 1 Appendix C presents an example of the methodology identified as “Approach 2” in this document to calculate spectrum requirements for AMS(R)S communications.

[Editorial Note: While the example provided contains some valuable information concerning inputs, relationships and explanations it is neither correct nor complete with respect to the methodologies proposed in this document and will need to be updated once the methodologies are agreed upon and availability of input data verified]

[5 Validation issuesData for the input parameters of the methodology should be provided by the administrations or AMS(R)S operators. The accuracy of the results naturally depends on the accuracy of the input data and hence it is desirable for input data to be validated to the extent possible. For example, the source of data should be clearly identified and where possible data should be taken from or be consistent with publically available sources. [To be further developed]]

6 SummaryConsiderations and examples of methodologies to determine spectrum requirements to satisfy AMS(R)S access within the bands 1 545-1 555 MHz (space-to-Earth) and 1 646.5-1 656.5 MHz (Earth-to-space) are provided and it is expected that appropriate Recommendation(s) are to be developed during the current ITU-R study period based on this working document.


- 8 -4C/TEMP/47-E

There are a number of procedural observations, questions, and suggestions related to the methodologies proposed within. In some instances while the proposed methodologies may include suggestions for addressing certain issues, their scope may reach beyond the intent of this document affecting regulations, recommended practices or deployment plans. As such, these issues are provided here in the form of observations and/or questions simply to provide focus for future discussions.

Synergies are of particular importance when dealing with the complex challenges faced when developing AMS(R)S spectrum requirements. Any implementation techniques that can be identified to simplify, reduce cost and hasten the execution of the proposed methodologies will be of great value and sharing of these is to be encouraged going forward. In this light the suggestions below are included. They are not intended to be prescriptive in any way but rather considered as an aid that may be included in the development of a final recommendation. Addressing the issues raised in the following sections would go a long way in helping progress the work of these studies.

6.1 Observationsa) It has been noted that AES could be registered on more than one AMS(R)S satellite

network and that the AES terminals are modified to use a coordinate look-up table to automatically decide on which network to log-on to. AES registrations could then lead to redundant spectrum allocations. Logged-on data collected is preferable therefore in determining the number of AES to be used in information volume calculations. The feasibility of gathering this data needs to be determined and if it is not available, adjustments to counts must somehow be made. This is an area that needs further investigation.

c) Some of the services as noted in the COCR can be carried as point-point or as broadcast services. This should be taken into account when using this methodology. d) It is not understood at present whether broadcast data via AMS(R)S may be used in the return direction and this needs further investigation. Currently the draft methodology does not address return direction broadcast mode.

f) The availability and granularity of input data, particularly raw traffic data has a direct bearing on the complexity and accuracy of the methodology. With more precise data, fewer calculation steps and/or assumptions are required, the spectrum requirements become easier to calculate and the results are more accurate. At present, it is unclear what data might be available. The development of the methodology should therefore be

an iterative process where general approaches are developed, input requirements and objectives identified and their availability verified. Then, depending on the availability and quality of the input data available, alternative methods are developed.

g) The initial proposed methodology is likely to contain many details that may be determined to be overly cumbersome and have negligible effect on the spectrum requirements generated. A review is thus in order to see how it might be simplified while retaining accuracy.

6.2 Questionsa) Grouping services by class of service (COS) is necessary from an efficient and practical

standpoint when determining information loads. However in reference 2 the allocation of ATS and AOC services to ITU priority levels (1-6) results in a highly uneven distribution. The COCR reference 1 allocates all ATS services to higher priority levels


- 9 -4C/TEMP/47-E

than AOC while reference 2 allocates both services to the same priority levels in some cases. The question then posed is: How should each ATS and AOC service be categorized with respect to COS priorities while taking into account the ITU priority classifications?b) The COCR provides QoS requirements by class of service. However, the QoS requirements were based on air to air and air/ground/air communications so the QoS thresholds may need to be adjusted to account for the operational limits of satellite communication links. How best are QoS requirements determined to ensure appropriate safety and account for satellite communication limitations, principally latency?

6.3 Suggestions

Throughout this document the point of view is taken that spectrum requirements are being developed for a host satellite system and other systems are only considered to the extent that they overlap coverage of the host. In fact all AMS(R)S satellite systems with coverage in the client air space are hosts and it is suggested that rather than treating each system separately the process should be undertaken jointly or at least in a parallel manner sharing common data so as not to duplicate efforts later.

Editorial Note: Administrations are invited to provide to WP 4C information regarding the items identified below:– Availability of measured communications traffic(sources/methods).– Availability of statistical communications traffic(sources/methods).– Aircraft count determination (sources/methods).– List of AMS(R)S terminal types and technical characteristics.– Determination of flight communication services applicable to AMS(R)S.– Characteristics of communications (COCR?).– Account for priority and pre-emption (queuing model).

7 NomenclatureIt is useful to consider the hierarchy of distributing the number of AESs (AES Count) and integrating amount of calculated spectrum requirements.

Following example is suggested to consider for the hierarchy and suffix to be used for respective notations.

- Ground Earth Station - “g”

- Airspace or Service area (Geographic area or Satellite dependent coverage area) - “a”

- Beam for spectrum calculation -“b”

- Type of traffic, i.e. Data, Broadcast or Voice- “d”, [“br” or “bt”] or "v"

- Type of carrier, “c”

Attachments: 1


- 10 -4C/TEMP/47-E

ATTACHMENT 1

FRAMEWORK FOR NEW RECOMMENDATIONITU-R M.[AMS(R)S.METHODOLOGY]

Methodology to calculate aeronautical mobile-satellite (R) service spectrum requirements within the frequency bands

1 545-1 555 MHz (space-to-Earth) and 1 646.5-1 656.5 MHz (Earth-to-space)

(Question ITU-R 83-6/4)

The ITU Radiocommunication Assembly,

considering

a) that coordination between satellite networks is required in accordance with the Radio Regulations, and that, in the frequency bands 1 525-1 559 MHz (space-to-Earth) and 1 626.5-1 660.5 MHz (Earth-to-space), coordination is partially assisted by regional multilateral meetings;

b) that, in these frequency bands, geostationary mobile-satellite system operators currently use a capacity-planning approach at multilateral coordination meetings, under arrangements agreed between their administrations, to periodically coordinate access to the spectrum needed to accommodate their requirements, including aeronautical mobile-satellite (R) service (AMS(R)S) spectrum requirements;

c) that, since spectrum resources are limited, there is a need to use them in the most efficient manner within and amongst various MSS networks,

recognizing

a) that WRC-97 allocated the frequency bands 1 525-1 559 MHz (space-to-Earth) and 1 626.5-1 660.5 MHz (Earth-to-space) to the MSS to facilitate the assignment of spectrum to multiple MSS networks in a flexible and efficient manner;

b) that WRC-97 adopted No. 5.357A giving priority to the accommodation of the spectrum requirements for the AMS(R)S providing transmission of messages with priority categories 1 to 6 in Article 44 in the frequency bands 1 545-1 555 MHz and 1 646.5-1 656.5 MHz;

c) Resolution 222 (Rev. WRC-12), related to use of the frequency bands 1 525-1 559 MHz and 1 626.5-1 660.5 MHz by the mobile-satellite service, and procedures to ensure long-term spectrum access for the aeronautical mobile-satellite (R) service;

d) that Resolution 422 (WRC-12) invites the ITU-R to conduct studies on, and develop in one or more ITU-R Recommendations, a methodology, including clear definitions of input parameters and assumptions to be used, to calculate spectrum requirements within the frequency bands 1 545-1 555 MHz (space-to-Earth) and 1 646.5-1 656.5 MHz (Earth-to-space) for AMS(R)S communications related to the priority categories 1 to 6 of Article 44,


- 11 -4C/TEMP/47-E

noting

that AMS(R)S systems are an essential element of the International Civil Aviation Organization (ICAO) standardized communications infrastructure used in air traffic management for the provision of safety and regularity of flight in civil aviation,

recommends

that within the frequency bands 1 545-1 555 MHz (space-to-Earth) and 1 646.5-1 656.5 MHz (Earth-to-space), the spectrum requirements for AMS(R)S communications related to the priority categories 1 to 6 of Article 44 to be assigned by bilateral or multilateral frequency coordination meetings under Resolution 222 (Rev.WRC-12)should be calculated using the methodology described in the Annex as far as applicable.

ANNEX 1

Method of calculation of spectrum requirements for the AMS(R)S communications in the 1.5/1.6 GHz bands

[Editorial Note: Review all notations used in this document to ensure consistency and ease of understanding by all readers.]

1 General

1.1 Introduction

Through RR No. 5.357A, priority shall be given to accommodating the spectrum requirements of the AMS(R)S providing transmission of messages with priority 1 to 6 in Article 44. This Annex contains a methodology which may be used to determine the AMS(R)S spectrum requirements per beam per satellite for AMS(R)S communications.

The methodology described in this Recommendation is based on the following steps:1. determination of the number of AESs (“AES Count”) within a beam;2. calculation of the information volume generate by these AESs for each of a number of

different voice and data carrier types;3. calculation of the spectrum requirements for various types of carrier in each beam;The methodology also includes steps for the calculation of the total AMS(R)S spectrum requirements for a network.

Calculation of the spectrum requirements of the AMS(R)S communications can be carried out by procedures as shown in the flow chart of Figure1.

The following four sections describe each of the above steps in more detail. For some steps, there are different approaches that may be used to determine the required information.

It is generally necessary to determine the spectrum requirements considering a particular time period when traffic is expected to be at its highest. Typically, traffic is assessed for the busy hour of a day and, if there is significant day-to-day variation, it may be necessary to consider the traffic expected on the busiest day of the year.


- 12 -4C/TEMP/47-E

Calculations are based on the input information of total data/voice traffic of the AMS(R)S communications for all Aircraft Earth Stations (AESs) which are actually operating AMS(R)S applications within the specified service area of the satellite network under consideration.

In some satellite networks, there can be more than one Ground Earth Station (GES) providing AMS(R)S services in a given service link beam. As the service link carriers typically cannot be shared by the GESs, in such a case it is necessary to estimate traffic and spectrum requirements separately for each GES. In this case, it is important that for each GES the AES count considers only those AESs which operate via that GES. The total spectrum requirements for a beam are determined by summing the spectrum requirements determined for each GES in each beam.


- 13 -4C/TEMP/47-E

FIGURE 1

Example of calculation of AMS(R)S spectrum requirements

To be modified

Total Spectrum Requirements for specified beam/zone SR (kHz)

Peak Information VolumePd,b,v (kbit/s or Erlang)

Air Traffic Statistics

Other airspace

Other beam/Zone

AMS(R)S communication requirementsOther types of signal/carrier

AMS(R)S communication requirementsand satellite channel throughput characteristics Nd & Nb = Pd/Cd (number) for addr and brcst data

Nv = E(Pv,Lc,Ce) (number) for Addr and pl voice

Ne = Estimate for broadcast voice

Satellite channel spectrum characteristics

SR = Nd,b,v,e × Dd (kHz)

Other types of signal/carrier/AeES

Log-on AES in specified networkACn (Number)

Required Number of CarriersNd,b,v,e (number)

Traffic Characteristics: SCV instance, MSG Size, Holding time, etc; or

historic traffic per AES.

Capacity per carrier: Cd (bit/s), Call Loss: Lc (%), Carrier

transmission rate RT and various transmission overheads

Normalized carrier separationDd/v (kHz)

Log-on AES in specified beam/zone ACb (number) & Global beam GCb

Log-on AES in specified airspaceACa (number)

Log-on AES in specified AeES withhin a beam/zone ACbAeES (number)

Other AeES

1.2 Glossary

[Editorial note: This list to be further reviewed and attempt to minimize number of terms and assumptions, etc.]

[Addressable Traffic: With respect to data traffic refers to the fact that each data packet comprising some message transmitted contains an address targeting one or more users. With respect to circuit


- 14 -4C/TEMP/47-E

voice traffic refers to a circuit established between two users. VOIP is handled similar to data. Radio bears may carry information specific only to a user, i.e. a dedicated circuit or may provide

multiple circuits to multiple users through employment of FDMA, TDMA or CDMA access schemes in which case addressing is defined by the frequency, time slot, or code assigned to each user.

Aircraft Earth Station (AES): As defined in RR 1.84 is a mobile earth station in the aeronautical mobile satellite service located on board an aircraft.

AES Count: Peak number of actually operating AESs within the specified area of the satellite network and logged on to that satellite network under consideration in the busiest hour of the year, where the busiest hour is the busiest hour of that particular area/beam. Note that the AES count should include only those AES which are expected to make use of the satellite network

Airspace: Volumes corresponding to different phases of an AC’s flight. Only some of these are applicable to satellite communications at present. The airspaces that are the focus of this study include:

– En Route (ENR) – Consists of the airspace that surrounds the TMA domain starting at ~FL 245 to FL 600. It is the continental or domestic airspace used by Air Traffic Control (ATC) for the cruise portion of the flight. It also includes areas to the lower limits of controlled airspace (e.g. 1 500 feet) where an airport or TMA does not exist. At the ATSU (Air Traffic Service Unit) level, the COCR assumes this domain to have a horizontal limit extending 300 NM by 500 NM.

– Oceanic, Remote Polar (ORP) – This domain is the same as ENR, except that it is associated with geographical areas generally outside the domestic airspace. The COCR assumes this domain to have a horizontal limit extending 1000NM too 2000NM.

– Airport (APT) – [definition to be added]

– Terminal Manoeuvring Area (TMA) – [definition to be added]

Air Traffic Service Unit (ATSU): A unit established for the purpose of receiving reports concerning air traffic services and flight plans submitted before departure (ICAO). Such a reporting office may be established as a separate unit or combined with an existing unit. It is a generic term meaning air traffic control unit, flight information centre, or air traffic service reporting office.

Call Establishment Delay: The total time taken between the PTT action by the User and the time for the squelch to operate in the receiver (of the party being called). (EUROCAE WG67-1)

Communication Operating Concepts and Requirements (COCR): The COCR is an output report resulting from a joint study effort undertaken by EUROCONTROL and the Federal Aviation Administration (FAA). It is intended to be used to determine candidate data communication technologies –existing or future – that can meet the requirements of air traffic services and operating concepts expected to be implemented in the future. The COCR is independent of any specific AC and ground radiocommunication technology. The physical implementation of the radio components of a communication system are collectively referred to as the Future Radio System (FRS).

Erlang: A unit of traffic intensity. It is a dimensionless quantity expressing voice activity in units of time that would be seen in during some time interval, typically an hour. It is used to determine the number of circuits needed to satisfy circuit voice demand, e.g. one Erlang represents one circuit occupied for one hour.


- 15 -4C/TEMP/47-E

Ground Earth Station (GES): The earth station used for the feeder links of the AMS(R)S system. This is equivalent to an aeronautical earth station, as defined in RR No. 1.182.

Information Load: This is the load in kbps or Erlangs associated with a particular service type it defines the capacity that is required from the facilities servicing the capacity, e.g. radio bearers within a satellite beam.

Push to Talk (PTT): The physical action taken by the “User” in operating his/her transmitter key. The general term “User” refers to a pilot or Controller. The term “key” is used to denote any type of device including buttons, levers, foot switches, computer mouse and

Service Instance (SI): A set of one or more messages and/or transactions associated with completing an objective. For example, a Flight Crew request followed by a Controller clearance followed by a Flight Crew acknowledgement would constitute a single service instance that contains three messages and two transactions.

Service Volume (SV): A volume of airspace that aligns with ATC sector/position control boundaries.

Technical Delay (also Transit Delay), one-way: Time required by the system to deliver a message, beginning with user action to send the message, and ending upon notification of recipient of message receipt. Typically accounts for half of a transaction.

Technical Delay (also Transit Delay), two-way: Time required by the system to deliver a message, beginning with user action to send the message, and ending upon notification by initiating user of reply receipt, excluding any user response time. Typically, that part of TD(95) allocated to system defining maximum time in which 95% of messages will be delivered.

Voice Latency: The one-way user-to-user voice delay between analogue system interfaces (HMIs) after the audio path has already been established.

2 Estimation of number of AESs to be handled with the satellite system under consideration

From an operational and economical point of view, it is generally desired that normal traffic in a wide area will be handled by the global beam, and high traffic in congested airspace be handled by spot beams. The advantage of the global beam is that it covers areas that would otherwise not be covered by the spot beams. In a typical deployment scenario a cluster of spot beams may be activated to serve aircraft along the high traffic air routes with the outlying aircraft served by the global beam. Although it is possible for the global beam to provide many of the same services as the spot beams the global beam is likely to be used for broadcast messages, signaling, and logging aircraft on to the network. At some point additional spot beams may be activated to provide services where it is more spectrally or power efficient. In any case it is important to know how many AESs are being served during the peak period by either spot beams or global beams.

[Editorial Note: Some satellite systems utilize advanced multi-spot beam configurations The multi-spot beam systems would be treated in a similar manner as systems that utilize a global beam and a few spot beams but with different technical and servicing characteristics taken into consideration.]


- 16 -4C/TEMP/47-E

The number of AESs (AES Count) within a specified beam to be handled within the satellite system under consideration should be determined. The AES Count is defined as the peak number of actually operating AESs within the specified area of the satellite network and logged on to that satellite network under consideration in the busiest hour of the year, where the busiest hour is the busiest hour of that particular area/beam. Note that the AES count should include only those AES which are expected to make use of the satellite network.

The AES Count, is a fundamental parameter required for the estimation of the spectrum requirement for the AMS(R)S communications. Three approaches to determine this number are described in this section:

1) In the first approach, it is assumed that the total number of AESs within the AMS(R)S system within the critical time period is known or may be estimated. However, the distribution of the AESs within different beams and airspaces may not be known and under this approach the number of AESs within a given beam and airspace is estimated based on assumptions of aircraft count densities and beam areas.

2) In the second approach it is assumed that the total number of logged-on AESs within the AMS(R)S system within the critical time period is known or may be estimated. However, the distribution of the AESs among the different beams may not be known and under this approach the number of AES within a given beam is estimated based on known information on the distribution of aircraft within the AMS(R)S system’s service area .

3) In the third approach, it is assumed that historical data for the total number of logged-on AESs within each beam of the AMS(R)S system within the critical time period is available, and estimates of future requirements may be made based on this historical data, with a suitable adjustment to account for increasing or decreasing demand in the future.

[Editorial note, the above descriptions will need to be reviewed when the description of the approaches are finalised]

It should be noted that Approach 1 is generally intended for use by newly planned AMS(R)S systems, while Approach 3 is applicable to established systems and should provide the most accurate estimate of AMS(R)S spectrum requirements. Approach 2 utilizes some historic data along with a number of assumed parameters and factors to determine AMS(R)S spectrum requirements. Its applicability to new or established systems is unclear at the time being.

An AMS(R)S system may consist of several GSO satellites, which may have overlapping beams in some areas. The spectrum requirements are determined separately for each beam within each satellite, and in areas of overlap there is a risk that AESs are double-counted, i.e. assigned to two satellites at the same time. Hence, when determining the AES count in areas of overlapping coverage, it is necessary to ensure that the number of AESs is suitably apportioned between the satellites.

2.1 Approach 1 – AES counts estimated from aircraft count densities and beam service areas

[Editorial Note: The text in this section as written pertains to the ENR and ORP airspaces and will be expanded as necessary to include other airspaces in which AMS(R)S ITU-R Article 44 priority 1-6 communications are required]


- 17 -4C/TEMP/47-E

[Editorial Note: In a given satellite beam there can be more than one GES providing AMS(R)S services for some satellite networks. Since service availability can vary between GESs it is necessary to estimate the maximum number of simultaneous logged on AES to a specific GES. Further study is needed to incorporate this variability into the methodology] There are at least four types of aircraft that may need to be considered in this section, commercial passenger, commercial cargo, general aviation, and government. Characteristics/statistics and traffic associated with these types can vary and so individual calculations of AES Count in the area of interest may be performed for each type of aircraft and used to calculate traffic data which are then summed for each aircraft type as appropriate before computing the spectrum requirements. In the event that such information is not well known, it is assumed that different aircraft types contribution to total traffic is by the same % of the total each aircraft type population to total aircraft population.

[Editorial Note: The following discussion needs to be rewritten to better address possible areas in which AMS(R)S may be utilized to provide priority 1-6 coverage]In the case of aeronautical communications traffic varies during different phases of an aircraft’s flight the AES counts within each beam are divided into groups reflecting the phase of flight and associated communications they are likely to encounter.Normally VHF air/ground/air links are used to provide aeronautical communications services where available but, beyond line of sight (BLOS), HF or satellite communications must be employed. There are two phases of flight in which this is likely to occur, the “en route” or ENR phase and the “oceanic remote polar” or ORP phase. The ENR phase will include portions of flight that are within line of sight (LOS) to VHF base stations and portions of flight BLOS that must depend on HF or satellite communications. The ORP phase is by definition BLOS to VHF transmissions.LOS distance to the horizon (Lh) from an aircraft (AC) may be calculated as:

Lh = 1.064 x (FL)1/2 (1)

whereLh: distance to horizon in nautical miles (NM);FL: Flight level or AC altitude in feet.

The ENR and ORP airspaces are defined in COCRv2 and summarized in Table A2. ENR is defined to reside in a vertical range between 24,500 and 60,000 feet. As a worst case it is assumed that all AC are flying at the lower end of the range resulting in a LOS distance of 167 NM, the maximum in which they would be able to receive VHF transmissions. We note that the flights which are likely to employ HF or satellite communications are those that are headed to or from land, i.e. oceanic. It is likely the VHF base stations would be located as close to the coastline as possible to facilitate oceanic coverage. It also is likely that departing or arriving flights would not necessarily fly in a direction perpendicular to the land. Assuming flights paths are on average at 45 degrees with respect to a tangent to the coastline, aircraft would be BLOS when more than 118 NM offshore. If the coverage area of the global beam is reduced to exclude the area defined by land with a 118 NM extension, then the remaining area can be assumed to contain the relevant ENR and ORP combined airspace (EOa). Each ORP air space is fairly large with respect to each ENR air space for a given flight. For the purpose of calculating an aggregate ORP airspace (Oa) it is assumed that one ORP would exist between each group of continents with transoceanic crossings that lie within a global beam. Subtracting the aggregate ORP air space i.e., from the combined ENR + ORP air space, determined earlier, will give an estimate of the total aggregate ENR air space (Ea).


- 18 -4C/TEMP/47-E

[Editorial note: The text in the remainder of this section needs to be reviewed and simplified. If possible, consider coordination with other approach as appropriate. In particular, it is not clear why the ACg parameter is necessary. ]

Before allocating logged-on AES counts “ACn” to beams and air space types “ACn” must be adjusted. The logged-on AES count “ACn” represents the total count seen by the entire global beam. Since only a portion of the global satellite beam, the area “EOa” would possibly provide communications to AC, “ACn” must be adjusted accordingly. This is done by multiplying “ACn” by the fraction of the global beam area (GBa) that “EOa” represents. The result is an adjusted logged-on AES count (ACg) as shown in equation (2).

ACg = ACn X (EOa/GBa) (2)where

ACn: total logged-on AES as seen by the entire global beam;EOa: combined ENR and ORP airspace within beam BLOS to VHF BS;GBa: Global Beam Area;ACg: logged-on AES communicating via HF or Satellite.

Allocating the adjusted logged-on AES counts (ACg) is then a three step process. First a combined AES count must be determined for each beam type. Second the number of AES per beam is determined. Third the AES counts per beam should be divided between those residing in the ENR airspace and ORP airspace within each beam.

[Editorial Note: With respect to steps one and two above the maximum number of simultaneous logged -on AES per spot beam (ACb), is best determined through traffic statistics from the relevant satellite system, with adjustments made for projected short term changes in AES population. However, if such information is not available, for example for new systems, ACb can be obtained by taking into account an assumed beam configuration during peak period and following the steps shown below]

Step 1 – Allocate AES by beam type

There are two factors that are needed when allocating AES counts to each coverage beam area: the relevant area covered by the satellite beam(s) and; the surface density of AC in the respective satellite beam areas. Reference (3) a report entitled “Future Communications Infrastructures – Technology Investigations. Evaluation Scenario”, by Eurocontrol and FAA, characterizes service volumes for typical aeronautical scenarios. Service volumes used in COCRv2 are based on actual air traffic control sectors having complex 3-dimensional shapes. To simplify the analysis, the FCS study transformed these complex service volumes into geometric shapes of equivalent volume. This facilitates the generation of an AC count for each Test Volume (TV). Peak instantaneous AC counts (PIAC) were generated for each test volume by air traffic growth-predicting tools, e.g. MLM2 for US and SAAM3 for Europe. Of particular interest are the larger sized service volumes that were defined for the purpose of evaluating space technologies and can be employed to

2 The Mid-Level-Model (MLM) is a software model of the National Airspace System (NAS), developed by The MITRE Corporation’s Center for Advanced Aviation System Development (CAASD), to study system-wide effects to the NAS for specific scenarios.3 EUROCONTROL’s System for Traffic Assignment and Analysis at a Macroscopic Level (SAAM) is an integrated system for wide or local design evaluation, analysis, and presentation of Air Traffic Airspace/TMA scenarios.


- 19 -4C/TEMP/47-E

approximate the AC densities seen by various satellite beam types. Appendix A, Table A3 provides details of some of the larger defined service volumes. The table shows the volumetric AC densities taken from the reference document. Because geostationary satellites have the capability to have beam coverage areas that can include multiple air traffic control sectors, the calculated AC density includes flights that would take place at different altitudes. However for calculation simplification, it is assumed that the altitude dimension is removed from the equation. The volumetric density becomes a surface density with the AC count remaining the same as that used in the volumetric density. Consequently, the applicable satellite beam coverage area can be multiplied by the reference surface density to approximate the AC count included for each beam.

As expected the smaller test volume, referred to as TV 3.4 in reference 3 and Table A3 of this document, has an area most similar to a spot beam area with a much higher density than that of a somewhat larger test volume, referred to as TV 4.4 in reference 3 and Table A3 of this document, as an areas and density more closely approximation that of a global beam.

The aggregate spot beam area (ABa) is multiplied by the appropriate test volume density (TVd) to approximate the AC seen by the aggregate spot beams (ABac). Likewise, the relevant global beam area EOa is multiplied by an appropriate test volume density (TVd) to approximate the AC seen by the global beam (GBac). A spot beam cluster factor (ra) can then be estimated as the ratio of ABac/GBac and the appropriate number of logged-on AES can be allocated to the aggregate spot beam area as follows:

The number of the aggregate spot beam AES can be estimated by using the adjusted number of logged-on AES as follows:

ACa = ACg × ra (3)

where

ACg: adjusted number of AES logged-on to the satellite under consideration;ra: ratio of logged-on AES operating within spot beam cluster airspace. ABac /GBac.-

Since the spot beams overlap the global beam and will service the AES within their aggregate coverage area we can eliminate the ACa count computed above from the adjusted global beam AES count, ACg, to determine the AES count serviced by the global beam (GCa).

[Editorial Comment: The information provided in Tables A2 and A3 is provided for illustrative purposes and is not intended to be prescriptive. More accurate data reflective of the geographic region under study should be used when available; however, if no more accurate data is available Tables A2 and A3 are offered as defaults.]

[Editorial Note: Determining ABa the overlap of the spot beams should be considered when computing the cluster area and this could be approximated by assuming hexagonal areas for each beam as with cellular designs, e.g. 2.598 replaces Pi. This calculation approach effectively provides an approximate overlap of 17.3% for spot beams.]

[Editorial Note: Global beams overlap on average around 20% and a greater percentage where there are heavier concentrations of traffic and lesser percentage elsewhere. This greater percentage of overlap will result in a higher global beam AC count GBac. While this has no effect on the total number of AES it will result in a reduced number of AES allocated to the aggregate spot beam. This can be corrected by splitting the global beam overlap areas between the two global beams and reducing each global beam area accordingly.]

[Editorial Note: The calculations above make an assumption that peak logged-on AES counts (ACn) are available from AC or AMS(R)S operator logs. If this is not the case then the process of


- 20 -4C/TEMP/47-E

calculating the number of logged-on AES within a given satellite beam would involve having the total number of AES registered to the satellite system(s) of interest globally, using available registration information distribution of registered AES over different airspaces could be determined. Flight statistics and/or time tables for the airspace of interest could then be used with the number of registered AES (Rs) to determine those AC in the air and likely to be logged-on to a specific satellite, i.e. ACn.]

[Editorial Note: For future revisions to Section 2.2 refer to the discussions captured in Section 2.1 Since we captured the concentration factor above and the AES are the logged-on counts to the satellite under study most of the factors previously considered are no longer applicable]

Step 2 – Determine the logged-on AES count for given beamSpot beams may be part of a cluster or potentially could stand alone. If the beam is part of a cluster its spot beam area should be reduced by half of any overlap areas with other beams and further reduced by any part that lies outside the EOa area, i.e., any part within 118 NM of land. The beam logged-on AES count ACb may then be calculated using the reduced spot beam area (Sa) as follows:

ACb = ACa X (Sa/ABa) (4)where

ACb : logged-on AES to a beam;ACa: logged-on AES in aggregate spot beam area;Sa: reduced spot beam area see discussion above;ABa: aggregate spot beam area.

For stand-alone spot beams the formula above applies but the spot beam area is not reduced for overlap with other spot beams. For the global beam no further allocation is needed than as described in step one and the AES count is given as GCa.

[Editorial Note: The 118 NM ENR reduction above assumes VHF coverage from land and if not the case will need to be treated as a special case]

Step3 – For each beam divide AES counts between those flying in the ENR airspace and ORP airspace

The ENR and ORP air spaces were discussed earlier. A typical transoceanic flight will pass thru an ENR airspace shortly after departure continue into the ORP airspace and then into another ENR before arriving at its destination. The relevant ENR airspace can be assumed to begin anywhere 118 NM off the shoreline and end where an ORP is encountered. The ORP is estimated to be 1000NM by 2000NM located and oriented to minimize the distance to all surrounding land masses. Based on each spot beams overlay on the above configuration its reduced spot beam area Sa is divided into percents representing the portion of the beam that falls into the ENR airspace and the portion that falls into the ORP airspace. The spot beam’s ACb AES count is then multiplied by these percents to give both an ENR AES count (ACbe) and an ORP AES count (ACbo). For the global beam the areas associated with each of the beams is cutout from the EOa defined area and then the same method is used to distribute the GCa counts into GCbe for ENR located AES and GCbo for ORP located AES.

[Editorial Note: The configuration described above is provided simply as an example of what the actual layout might look like. Actual aeronautical airspaces are well known and should be

substituted where ever possible]


- 21 -4C/TEMP/47-E

2.2 Approach 2 – Calculation of the AES count per beam, based on a statistical distribution approach

Maximum number of AES per service area (ACa) is best determined through historical traffic statistics from the relevant satellite system, with adjustments made for projected short term growth. However, if such information is not available, ACa can be obtained based on total number of registered AES to the satellite network concerned and statistical and operational data for similar systems.[editorial note: need to review this para when the methodology is stable]

2.2.1 Estimation by using the number of registered aircraft equipped within a given service area

The number of the AES within specified service area can be estimated by using the total number of registered AES to the satellite network under consideration as follows:

ACa = Rs × ro × ra (5)where

Rs: number of registered AES capable to use the satellite network under consideration;

ro: ratio of the maximum number of AES operating at any instant in the visible area of the satellite network to the total number AESs registered to the system;

ra: ratio of the AES operating within the specified service area to the number of AES operating in the visible area of the satellite network concerned.

2.2.2 Estimation of the number of AESs to specific satellite beam

[Editorial note: Proposals to modify the content of section 2.2.2 were discussed during the Sept 2012 meeting of WP 4C. However, the discussions revealed some fundamentally different thinking on how the AES count per beam should best be determined under this approach. Hence, detailed changes to this section could not be agreed, and the issue will be revisited at the next WP 4C meeting.]

[Maximum number of AES per beam (ACb), referred to as the AES count, can be obtained by taking into account of beam configuration of the satellite network as follows:

ACb = ACa for global beam (6a)

ACb = ACa/Nb for spot beam (6b)

ACb = ACa for global beam [coverage area] (6a)

ACb = bc × ACa/Nb for spot beam [coverage area] (6b)

ACb = ACa for global or spot beam (6a)

ACb = bc × ACa/Nb for beam element in the beam cluster (6b)

where

Nb: number of spot beam in the coverage area;


- 22 -4C/TEMP/47-E

[What is represented by the parameter “bc” and how is it calculated?]

Nb: number of beam element in the beam cluster;

bc: peak to average distribution factor for beam element in the beam cluster.

][Comments: How does equation (6a) work? In practice, traffic distribution is not uniform across the various spot beams, some spot beams could serve a high percentage of total traffic carried by a network. What are the typical size of defined Air Spaces and how would they relate to typical size of satellite beams in use today?]

2.3 Approach 3 – Where historical data of the logged-on AESs per beam is available

The AES count per beam (ACb) is best determined through historical statistics from the relevant satellite system, with adjustments made for projected short term changes in the number of operating aircraft.

The traffic data for both circuit switched voice traffic and the packet data traffic is processed on an hourly basis based on the raw call data records. It is possible to gather the following information on an hourly basis for each calendar day of any given month.

Satellite network/associated GES Beam: Global/spot within the satellite Calendar day Hour (0-23 hours) Traffic unit (kbits for packet data traffic (forward and return directions) and min for

circuit switched voice traffic) Volume of traffic (kbits or mins) and the associated AES ID.

Based on the above information it is possible to identify three busy hours within a given year for each category of voice and packet data traffic in each beam of every ocean region/satellite. Having identified the three busy hours, the AES count is determined for each of those busy hours and the average value of the AES count for those three busy hours is used in the further analysis. These steps are undertaken separately for the voice and data traffic so that two values for the AES count are determined – one applicable to voice traffic and the other applicable to the data traffic. An underlying assumption here is that there is not a significant difference in volume of traffic associated with each of the three busy hours.


- 23 -4C/TEMP/47-E

AES count (ACb) = (X1+X2+X3)/3 (6c)where X1, X2 and X3 are the maximum number of AESs in each of the three busy hours associated with either the voice or data traffic

Average volume of voice traffic in the busy hour Yave = (Y1+Y2+Y3)/3 (6d)

where Y1, Y2 and Y3 are the values of voice traffic volume in each of the three busy hours.

Average volume of data traffic in the busy hour Zave = (Z1+Z2+Z3)/3 (6e)where Z1, Z2 and Z3 are the values of data traffic volume in each of the three busy hours.

Volume of voice traffic carried by one AES in the busy hour Va = Yave /ACb mins (6f)

.

Volume of data traffic carried by one AES in the busy hour Da = Zave /ACb kbits. (6g)

Based on the above procedure it is possible to arrive at the AES count in a given beam for each type of voice and data service and the associated traffic carried by each AES .

3 Calculation of information volume for each type of trafficThe calculation of information volume may be conducted separately for each of a number of different traffic types. In the sub-sections below, a method to determine the information volume for each of the following traffic types is considered: addressed data (including packetized voice), broadcast data, addressed circuit-switched voice, party-line circuit-switched voice and broadcast voice.

[Note: terminology related to the types of carrier needs to be checked and aligned throughout the document]

Information volume for each type of traffic in the beam should be obtained by considering only the portion of AES counts supporting a particular traffic type.

For AMS(R)S systems which have historical call data available, the traffic volume per AES may be determined from call/data records. In other cases, the traffic volume per AES may need to be estimated from the planned AMS(R)S communications (for example as defined in the COCR) and from that data, an estimation may be made of the aggregate information volume required within a particular beam for a particular carrier type.

[Editorial Note: While all five traffic types are employed in aeronautical communications, a refined list of ATS and AOC messages provided by the AMS(R)S system under study and corresponding to ITU priority 1-6 is needed to decide if all traffic types need to be considered. This is particularly applicable to the theoretical approach, based on use of the COCR or similar information.]

[Editorial Note: Different approaches were suggested in the Chairman’s report to determine the capacity requirement; in addition other approaches could also be taken. For example, for the established networks a methodology based on historical traffic records should provide most accurate results. If this information is available it will greatly simplify the methodology. Also where historical information is available the average traffic per aircraft within each satellite beam can be estimated from records. This allows any geographic variability in the average traffic per aircraft to be readily estimated. However, relevant historic or statistical information may not be readily available in all cases. As an alternative, the queuing method provided below is proposed. The method employs a bottom up approach to determine the traffic that would be generated by AES


- 24 -4C/TEMP/47-E

within a beam. The method is based on the COCRv2 (see reference 1) which is the result of a joint EUROCONTROL and the Federal Aviation Administration (FAA) study sponsored by ICAO approved by the Aeronautical Communication Panel.]

3.1 Data carrier (to cover both data and packetized voice requirements)

3.1.1 Information volume determined from estimated AMS(R)S communications requirements – Queueing model

[Editorial note: This section (section 3.1.1) need to be reviewed and simplified if possible.]Since message arrival rates are somewhat random, the communications traffic aggregate load through the satellite is non-linear with respect to the AC traffic. It is therefore proposed that a queuing model be used to accurately evaluate and accommodate the combined AES communication service loads while ensuring priority and preemption service handling. The queuing model indirectly determines the peak data information load per carrier per beam (Pdi) as follows: The queuing delay is computed for some given input capacity (C) and is incrementally increased until the most limiting transit delay requirements can be met. The input capacity for which this occurs defines Pdi which is used later to determine the spectrum requirements:

The proposed queuing method is described in detail below, broken down into several steps to help its implementation [Comment: The following descriptions provide for having a variety of messages, data carrier types, vocoders, AES terminals, etc. If this is not representative of the operational environment, then some steps in the following formulas could be eliminated or simplified.]

Step 1 – Adjust AES counts

The AES count per beam is limited to just those AES models that support a given service. Next they are segregated into counts that support a particular carrier type:

ACbdi = scvd x rdi × ACb (7a)

GCbdi = scvd x rdi × GCb (7b)

where

subscript “d” refers to a specific service, “i" refers to a specific carrier type;scvd: AES service ratio;rdi: AES carrier type ratio;ACbdi : AES that support a given service and type carrier for given spot beam;GCbdi : AES that support a given service and type carrier for global beam.

Step 2 – Determine data service characteristics

All of the ATS and AOC safety communication services corresponding to RR Article 44 priority 1-6 communications that are to be provided via the satellite need to be defined. In certain cases, services can be provided as data or voice and further categorized as addressed or broadcast and need to be allocated accordingly at the outset of the calculation. A preliminary list of these services with associated characteristics were developed from references 1 and 2 are presented in Appendix A, Table A4.

[Editorial Comment: The information provided in Table A4 is preliminary and will need to be reviewed for accuracy, applicability and/or modification to the satellite system under study. Table A4 is provided as a starting point in establishing relevant service detail.]


- 25 -4C/TEMP/47-E

Step 3 – Computation of message arrival rates (MAR)

The message arrival rate is a central concept in the development of a queuing model. It is a function of: AES counts; service instances; messages associated with each service instance; and any applicable time frames, defined by the flight duration over some defined airspace or other time interval that properly characterizes service instances. The first step in computing the MAR is to determine the service instance rate per AC (SR). COCRv2, Tables 6-2, 6-4 and 6-14 provide a definition for each instance, i.e., the number of instances (SI) and how and when they occur allowing the SR to be computed. The instances are defined on a per AC basis except A-EXEC and AMC services which are provided on an Air Traffic Service Unit (ATSU) basis.

NOTE – While, Table 6-14 provides network traffic instance definition, these were defined for typical terrestrial networks. Therefore the service instances should be adjusted as appropriate to model typical satellite communications use for the satellite under study. The adjusted traffic instances are then used in the development of MARs associated with network traffic.

Since the services have certain disparate service instance definitions, they need to be treated differently in the calculation of the MAR. Example calculations are provided below in order to exemplify these differences. These calculations fall into different categories based on how the instances occur. The categories are: at certain AC positions; over some time interval; per sector, per ATSU, or per domain; AC type; and on a non-AC basis. Besides the categorical differences, some services require additional adjustments which are also captured in the examples that follow:

AC Position service instance

For this category, some number of instances is provided in relation to a specific location that occurs once or twice during a flight, e.g., the service GATES service (in the ENR airspace) provides for one instance at the top of a descent. In this case, the service instance count (SI) is 1 and the time interval would be the duration of the flight. Table 6-5 of COCRv2 provides the flight time for each air space type which can be summed to get the total flight time (FTT) though actual fight times would be preferable. FT should be converted to hours. Since this information is for a single AC, the SR is computed simply as:

SR = SI/FTT (8)

This category only applies to the ENR domain and it could be argued that the top of the descent would be within LOS of VHF base station so satellite transmission may not pertain.

NOTE – Table 6-5 of COCRv2 provides flight information for two distinct cases of low density and high density air spaces. Actual airspaces under study may not fit either of these categories and thus will require some modification to the flight data as provided in the table.

Time interval service instance

For this category, the service instance is provided per some unit time (UT). For example, the TIS-B service (in the ENR airspace domain) calls for one instance per 10 seconds. In this case, the UT in hours is (10 sec/3600 sec) hrs and SI is 1. Since this information is provided for a single AC, the SR is computed as:

SR = SI/UT (9)

Combined time and position service instance

Some service instances are of a compound nature. For example, the WXRT service (in the ENR & ORP airspace) calls for one instance per 3 min when at cruise level. In this case, the UT in hours is (3 min/60 min) hrs and SI is 1. Since this information is provided for a single AC, the SR for the ORP airspace is computed as:


- 26 -4C/TEMP/47-E

SR = SI /UT (10)

However this service has a different service instance in the ENR airspace, i.e., when climbing or descending the service instance is 1 every min. It is noted in COCRv2 that in the ENR airspace 50% of the time is spent climbing or descending and 50% is spent cruising. The UT for the ENR airspace can therefore be computed as:

UT = 50% X (3/60) + 50% X (1/60) (11)

and SR is computed using equation (9).

Per sector, per ATSU, per domain service instance

In this category the number of service instances SI is divided by the flight time to cross the defined airspace. For example, the D-ATIS service (in the ENR airspace domain) is given as 1 per domain, on arrival, for 70% of the AC. Making an assumption that half of the planes are arriving and half are departing SI = 1 x 50% x 70%. Since this information is provided for a single AC the SR is computed as:

SR = SI/FTD (12a)

whereFTD: is the Flight Time across the ENR airspace in hours.

For Packetized voice or Voice over IP (VOIP) the number of service instances SI is divided by the flight time to cross the defined airspace. COCRv2 Table 6-24 as service instances per sector for both ENR and ORP airspaces. Since this information is provided for a single AC the SR is computed as:

SR = SI/FTS (12b)

whereFTS: is the Flight Time across either an ENR or ORP sector given in hours.

Non-per-AC service instance

The only applicable services having this type of service instance is the AMC and A-EXEC services. For the ENR airspace, the AMC service instance is defined as1 per week per ATSU. To translate this service into a per AC basis, one must know the number of AC, i.e., the number operations that are served by the ATSU over the applicable timeframe (e.g., one year or one week). COCRv2, Table 6-12 provides the daily operations (DO) (number of AC serviced in a 24-hour period) per ATSU. The translation is then performed as follows:

First DO must be normalized to a single air route. The DO for the ENR domain (Table 6-12) is based on a 40 sector domain yet the actual sectors traversed (SECT) during a flight is much less (see Table 6-5). Therefore we get:

DN = DO x (SECT/40) (13)

Next, since DN represents AC serviced in a 24 hour period, it must be adjusted to match the service instance time frames.

For AMC, this is given as:

DNadj = DN(AC/day) x 7 (days/week) (14)

By dividing the service instance SI (1/wk) by DNadj (# AC serviced in the ATSU air route/wk). The time frames cancel giving 1 instance per aircraft per ATSU route.

The flight time across the ATSU (FTA) (see COCRv2, Table 6-5) may be computed as:


- 27 -4C/TEMP/47-E

FTA = FTS X SECT (15)

where

FTS: is the Flight Time across an ENR sector given in hours.

FTA may then be used to compute the SR as:

SR =(SI/DNadj)/FTA (16)

Service arrival rates SR are computed for each service and then the MAR is calculated by multiplying each SR by its corresponding number of messages per service instance (MQ) (provided in COCRv2, Tables 6-15 thru 6-17), satellite utilization, and the number of AES within the relevant air space that support the carrier type for which the calculation is being performed. Although the communications considered herein are exclusive to ENR and ORP airspaces that are beyond LOS; some of the associated messages will be transmitted via HF radio and some via the satellite system. A factor (RTad) representing the percent of addressable data transmitted over satellite must be developed from AC logs, billing and/or pilot surveys and used in the calculation of the MARs. Once MARs have been developed for each of the ENR airspace and ORP airspace. They are added together to get a MARdi for each service and type carrier.

For ENR MARdie = SRd x MQd x RTad x ACbdie (17a)

For ORP MARdio = SRd x MQd x RTad x ACbdio (17b)

MARdit = (MARdie + MARdio)t (17c)

MARdi = (t = 1_m) MARdit (17d)

where

subscript “d” refers to the specific data service, “i" refers to a specific type carrier, “e” pertaining to the ENR airspace, “o” pertaining to the ORP airspace, “t” pertains to a specific air traffic type, “m” pertains to the total number of air traffic types and:SRd: is the service specific arrival rate;MQd: is the quantity of messages per service instance;RTad: is the % of addressable data messages transmitted via satellite;ACbdie: AES count within ENR airspace and BLOS to VHF for a given spotbeam;ACbdio: AES count within ORP airspace for a given spotbeam.

NOTE – At the beginning of the methodology it was stated that due to the different characteristics of each air traffic type including: equipage, usage, etc. traffic requirements would be developed separately for each traffic type and then summed for each beam. In the above formulas MARdi is computed for each traffic type MARdit then summed across all traffic types.

For packetized voice the message arrival rate is computed a little differently due to three differences. First, satellite usage for voice may be different than for data and a different utilization factor (RTav) representing the percent of voice transmissions that would be carried over satellite must be developed from AC logs, billing and/or pilot surveys and used in the calculation of the VOIP MAR. Second, Table 6-6 of COCRv2 shows that AC equipped for voice and data utilize voice only 40% as often as voice only equipped AC in the ENR airspace and only 5% as often in the ORP airspace. Third, each service instance refers to some number of pilot or controller push to talk (PTT) transmissions (#tx) each with some period or holding time (H). Depending on the vocoder used the number of packets (i.e., messages) sent during each holding time can vary and therefore the number of messages per instance can vary.


- 28 -4C/TEMP/47-E

Specifications for vocoders typically provide the packets per second (PPS) which is computed as the Codec rate in bytes/sec divided by the payload size in total bytes including voice sample + overhead. The MARs associated with different vocoders cannot be summed because the payload (message) size varies. However, the MARs for ENR and ORP can be combined.

The packetized voice MAR may thus be calculated as follows:

For ENR MARcdie = SRd x MQc x RTav x ACbdie x 40% (18a)

For ORP MARcdio = SRd x MQc x RTav x ACbdio x 5% (18b)

MARcdit = (MARcdie + MARcdio)t(18c)

MARcdi = (t = 1_m) MARcdit (18d)

where subscript “c” refers to a specific voice codec, “d” refers to the packet voice service, “i" refers to a specific carrier type, “e” pertains to the ENR airspace, “o” pertains to the ORP airspace, “t” pertains to a specific air traffic type, “m” pertains to the total number of air traffic types and:

SR: is the service arrival rate for voice;MQc: is the quantity of messages per packetized voice service instance and may be

calculated as H x PPS x #tx/instance (see above);RTav: is the % of voice messages transmitted via satellite;ACbdie: AES count within ENR airspace BLOS to VHF for a given spotbeam;ACbdio: AES count within ORP airspace for a given spotbeam.

NOTE – Because holding time is in seconds it cancels with the PPS seconds and the packetized voice MAR is in Messages/Hr like all the other MARs. Also because the message size differs between codecs the message arrival rates for codecs (MARcdi) cannot be combined and each one must be treated as a separate service in the queuing analysis.

NOTE – At the beginning of the methodology it was stated that due to the different characteristics of each air traffic type including: equipage, usage, etc. traffic requirements would be developed separately for each traffic type and then summed for each beam. In the above formulas MARcdi is computed for each traffic type MARcdit then summed across all traffic types.NOTE – In the current manual of ICAO, some AMS(R)S systems use R/T600 and R/T10500 carriers, dependent on type of AES, for return link data communications. It has to be noted that evolution of the SARPs is under discussion to include most demanding performances in Oceanic airspace and to cover continental airspaces. The manual will be updated accordingly if a new version of the SARPs is approved by ICAO.

[Editorial Note: See Appendix C for a table of approved AERO carrier types used for AMS(R)S data and voice communications and their characteristics.]

NOTE – For the global beam GCbie and GCbio replace ACbie and ACbio respectively in each of the formulas 17 and 18 above.

Step 4 – Queuing model(s)

A Queuing model is employed to determine the data capacity requirement. The queuing model may be used to simply evaluate the traffic load associated with the priority 1 to 6 services. A non-pre-emptive priority queuing model was used to develop the capacity requirements in the COCRv2. Details of the model and the methodology to employ it can be found in Appendix 3 of the COCRv2. A pre-emptive resume priority queuing model was developed since publication of the COCRv2 to provide different estimates of the capacity requirements. It is proposed that the pre-emptive model is a closer fit to the pre-emptive requirements associated with priority services 1 to 6 per ITU RR


- 29 -4C/TEMP/47-E

No. 5.357A. Reference 4 presents the “non-pre-emptive” and “pre-emptive resume” priority queuing analyses methods and the results of the analyses. Specifics of the two models along with the definition of parameters employed and computation are provided below.

The COCR (non-preemptive) model assumes a single-server queuing system with random message arrival times (Poisson) and service times that have general distributions. The same is true for the reference 4 (preemptive) model. However, the service times are assumed to have an exponential distribution.

The queuing analysis is performed for each circuit type one at a time so for clarity subscript “i” is not shown. The following parameters used in the queuing analysis are:– Message sizes (MS) in bytes are provided for the uplink (forward) and downlink

(return) directions for each of the relevant data services in COCRv2 Tables 6-15 thru 6-17. The message sizes include overheads associated with the network, integrity and security and assume an ATN4 protocol stack is used. While, Table 6-17 provides network traffic message sizes, these were defined for typical terrestrial networks and actual message sizes employed by the satellite under study should be used in the queuing analysis. The message size for packetized voice varies by vocoder employed and is simply the payload size in total bytes including voice sample + overhead. Message sizes for packetized voice are the same in both the upstream and downstream direction. NOTE – It is possible that due to limitations of the satellite link message segmentation may be required in which case the effected message size and quantity must be adjusted accordingly before the queuing analysis is performed.NOTE – Each codec effectively defines a different service for the purposes of the queuing analysis so MARcd replaces MARd in those cases.

– Message size (Msg) is given in bits and is simply MS multiplied by 8 bits/byte. – Aggregate message size, appropriate for each priority class is calculated as follows:

Msgp = 8(bits/byte)(d = 1_m) (MSd x MARd) / (d = 1_m) MARd (19)

where:Subscript “p” indicates a priority class;

Subscript “d” indicates each data service associated with a priority class;

Subscript “m” is the total services in the priority class.

NOTE – Priority classes and associated performance requirements are assigned to each data service in COCRv2, Tables 6-18 and 6-20 thru 6-23. These need to be reviewed and adjusted to ensure RR Article 44 priority 1-6 compliance and modified as appropriate. ICAO Annex 10 Volume III states that within same message category the system shall provide voice communications priority over data communications. While voice may be used in place of data for many of the services considered, the nature of voice use vs data use are considerably different and not interchangeable

4 ATN: Aeronautical Telecommunications Network is an ICAO developed family of upper layer packet protocols supporting Air traffic services (ATS) communications. The COCR is a forward looking document that makes some general assumptions to enable the estimation of future needs. Therefore, it does not address legacy data delivery systems and related protocols such as: ACARS, FANS 1/A, and X.25 or TCP/IP managed communications planned for Aircraft Operator Communications (AOC) services. It will be necessary to study the impact these other protocols may have on the total traffic load when employed in calculations versus ATN only for the time frame in which the methodology will be implemented.


- 30 -4C/TEMP/47-E

from information load perspective. The ATN protocol stack treats voice packets with the highest priority (see expedited forwarding, RFC 3246). It is therefore proposed that packetized voice be treated within the highest priority service class with similar transit delay requirements or define a separate high priority class for packet voice altogether.

[Editorial Note: Voice has performance requirements defined in COCRv2 Tables 5-1 and 5-2 for ATS and AOC services respectively. Because of propagation delays, it is not possible to meet some of the voice performance requirements in the ATS respective table when communicating via a GEO satellite. It is necessary to determine what portion of the ATS voice requirement is relevant to AMS(R)S communications.]– Channel Capacity in kbps (Cu for uplink (forward) and Cd for downlink (return)): For

the purposes of the queuing analysis it is assumed the channels servicing the traffic load are carriers of a given type within a single satellite beam.

Message service rate (p) is the capacity divided by message size or C/Msgp (20)– Message arrival rate per second is the MARp(messages/hour) divided by

3 600(seconds/hour). The aggregate message arrival rate (p) appropriate for each priority class is therefore calculated as follows:

p = ((d = 1_m) MARd)/3 600(sec/hour) (21)– Priority class utilization p is the aggregate message arrival rate divided by the service

rate or

p = p/p(22)– Average message service time without preemption (Xp), for a priority class, is simply

the transmission time calculated as the message size divided by the capacity

(Xp) = (Msgp/C) or 1/p (23)– Average message service time with preemption (Tsp) for a priority class is the average

message time without preemption divided by the sum of all priority class utilizations excluding the highest priority class. It is calculated as:

Tsp = (Xn)/1-(p = 1_n-1) p (24)

where

subscript “n” refers to the highest priority class.– The second moment (Xp)2 for general distribution service times is provided in COCRv2

as the variance (Var) of the service message sizes plus the average message size (AvgMsg) squared divided by the capacity or given as:

(Xp)2 = (Varp + (AvgMsgp)2)/C (25)– The second moment (Xp)2 for an exponentially distributed service time is provided in

COCRv2 simply as:

(Xp)2 = 2 x the service time squared or 2 x (Tsp)2 (26)– Average message waiting time (Twp) for a priority class, is identified as the time it takes

for a message to arrive and be stored in the buffer queue. Both the non-preemptive and preemptive models employ the same general formula:

Twp = ((p = 1_n) p(Xp)2 )/ (2(1-n)( 1-n-1)) (27)

where

(n) = (p = 1_n) (p) and (n-1) = (p = 1_n-1) (p) (28)


- 31 -4C/TEMP/47-E

However, the above formulas compute the average send time for an average message in the queue. COCRv2 uses the send time associated with the worst case COCR service assigned to the queue, i.e., the service with the largest message size in the queue. This is because the individual service latencies are not insured unless the worst case service size is used for the message send time. Replacing Msgp with the largest message size (MsgA) results in the following:– The average message service time without preemption (XA) is therefore calculated using

the largest message size in the queue divided by the capacity:

(XA) = (MsgA/C) (29)– The average message service time with preemption (TsA) is then calculated as the

average message time without preemption divided by the sum of all priority class utilizations excluding the highest priority class. It is calculated as:

TsA = (XA)/1-(p = 1_n-1) p (30)– The average message waiting time for the largest message (TwA) would be a reduced

version of the formula presented above to compute (Twp):

TwA = ((p = 1_n) p(Xp)2 )/ 2(1-A) (31)– The average queuing time (TQA) may then be computed as:

TQA = TwA + (XA) for non-preemptive priority queuing and; (32)

TQA = TwA + TsA for preemptive priority queuing (33)– The rth percentile of the queuing time (T(r)Q ) is the time for which some percent “r” of

all messages will have a queue time less than the transit delay (TD). These transit delay provided in COCRv2 Table 6-18 are given as 95%. In order to use the average queuing time TQA, produced by the queuing model, to validate compliance, it must be converted to the same percentile basis. This is done as follows:

T(r)Q = T(95)Q = ln(100/(100-95))TQA = ln(20)TQA = 3 x TQA (34)

In addition to the queuing delay, the other significant delay limiting satellite communications is the propagation delay (PS). In general propagation delay is ignored in the COCR computation as the propagation times associated with the Air/Ground transmissions are insignificant for LOS links. However, when employing satellite links, propagation delays would be significant and should be accounted for (see Table A7 for worst case values). However, when determining compliance with the transit delay requirements provided in the COCR for AMS(R)S, the propagation delay should be taken into account. The timing requirement may therefore be expressed as:

TD(95) – PS > 3 x TQA (35)

whereTD(95) is the COCR 95% transit delay for the priority class being calculated;

PS: is the forward or return propagation delay in seconds between the AeES and AES.

TQAp is calculated for each priority class (p) and capacity increased until the conditions of equation (35) are just satisfied for the appropriate TD(95)p. The highest capacity determined from all of the priority class calculations effectively represents the worst case traffic load on the beam carrier of a specific type (Pdi) . A Queuing analysis is performed for each beam carrier type of interest, including for the global beam, following the procedure in Figure 2 below:

[Editorial note: it would be helpful to have links between the steps described here and the relevant boxes in Figure 2]


- 32 -4C/TEMP/47-E


- 33 -4C/TEMP/47-E

FIGURE 2

Queuing analysis procedure

Start

Compute: Class message size, Msgp Class arrival rates, p

Input: 95% Transit Delay, TD(95) Msg Arrival Rates, MARs Low initial capacity, C

Select: Higher capacity C

Compute: Class and max message rates p & A Class & max utilization p & A Avg svc time for max Msg, (TsA) Second moment (X)

2 Avg wait time for max Msg, (TwA) 95th percentile queuing time T(95)Q

TD(95) –PS > T(95)Q ?

Yes No

Save Capacity, as Pdp

End

Repeat for each priority class

Traffic load, Pdi is highest Pdp calculated

3.1.2 Information volume determined from historical records

Peak data rate for the addressed data carriers to be handled by each type of carrier can be calculated by the following process.

Total data traffics per GES in a given beam (Tb g (kbit)) can be obtained as:

1) In case of unit traffics provided in kbit/hour:

Tbg = Da × ACbg (36a)

and peak data rate per beam (Rd (kbit/s)) is calculated as:

Pd = (hs × Tbg/3 600 (36b)

where


- 34 -4C/TEMP/47-E

Da: averaged unit data traffics to be handled by an AES(kbit/hour) (see equation 6e above);

hs: conversion factor from bit/hour to bit/s [Comment: who provides this factor?].

[Editorial Comment: It is assumed that what is meant by “hs” is a peak to average ratio. How is this determined? It may be possible to use the queuing models described in section 3.1.1 to determine the peak data rate from which ‘hs” could be determined and used with measured data “Da” to determined “Pd”.]

Peak data rate per beam can be divided for each type of carrier as:

Pdi = rdi × Pd (37a)

whererdi: data carrier type (i) ratio.

In this case, rdi would be ratio of data traffic volume associated with each carrier type(i) relative to total data traffic volume (Tb).

3) For voice packetized:

[Editorial Note: Presently packetized voice is not supported nor provided for AMS(R)S systems,

This section to be reviewed at future meeting.]

Tvg = Pdrv × ACg × rv (37c)

wherePdrv: peak data rate per beam (kbit/s) for voice traffic; [Comment: How is the value

of Pdrv computed? ]rv: AES ratio in the specified beam area using voice. [Comment: How is the value

of rv determined? ]

It is to be noted that Pdrv depends on the vocoder specified by aviation to be used for VoIP as already currently specified in ICAO ATN/IPS technical manual.NOTE – In the current manual of ICAO, some AMS(R)S systems use R/T600 and R/T10500 carriers, dependent on type of AES, for return link data communications. It has to be noted that evolution of the SARPs is under discussion to include most demanding performances in Oceanic airspace and to cover continental airspaces. The manual will be updated accordingly if a new version of the SARPs is approved by ICAO.

3.2 Broadcast data carrier

3.2.1 Information volume determined from estimated AMS(R)S communications requirements

[Editorial note: This section (3.2.1) need to be reviewed and simplified if possible.]

The broadcast data traffic load may be determined in a manner similar to addressed data. However due to the nature of broadcast transmissions they are likely to require separate transmission channels than for addressed and therefore the broadcast services may need to be considered within a separate queuing analysis to determine the peak broadcast data traffic load Pbi. [Comment: It is


- 35 -4C/TEMP/47-E

required to confirm the stated assumptions above. If broadcast data is carried over the same carriers as addressed data, then this section is required to be revised.]

The broadcast data traffic load may be determined in a manner similar to addressed data. However due to the nature of broadcast transmissions they are likely to require separate transmission channels than for addressed and therefore the broadcast services may need to be considered within a separate queuing analysis to determine the peak broadcast data traffic load Pbi.

A more simplified analysis for computing the peak broadcast data traffic load Pbi is proposed within COCRv2 and should be considered as another option for the methodology. Broadcast ranges are based on operational requirements for data transfer between users, i.e. all users that must receive the broadcast message receive it in a timely manner. Broadcast messages can be gathered from several sources and uplinked from a AeES to a number of AES or downlinked from a number of AES to a AeES for distribution to control positions, AOC centers, etc. As a worst case analysis it could be assumed that although the messages are broadcast in nature, each message whether uplinked or downlinked contains information only relevant to one specific aircraft. If it is also assumed that all AES and AeES involved are in the coverage of the same beam then a simplified method, as proposed in COCRv2 may be employed to estimate the required peak broadcast data traffic load for a specific beam and type carrier (Pbi) as follows:

Pbdit = (ACbdjt x MSd x 8 bits/byte)/((TD95)d – PS) (38a)

Pbit = (d = (1 to n) Pbdit (38b)

Pbi = (t = (1 to m) Pbit (38c)where

subscript “d” defines a specific data broadcast service, “n” total number of broadcast services, “i” a specific type carrier, “t” is a specific air traffic type, “m” total number of air traffic types and:ACbdit AES logged-on to a beam of a specific air traffic type supporting a specific broadcast service and type carrier;MSd is the broadcast service message size in bytes;(TD95)d is the specified 95% transit delay requirement for the broadcast service (see COCRv2, Table 6-20);PS is the forward or return propagation delay in sec between the AeES and AES.

As mentioned at the beginning of the methodology, due to the different characteristics of each air traffic type including: equipage, usage, etc. traffic requirements would be developed separately for each traffic type and then summed for each beam. In the above formulas Pbi is computed for each traffic type Pbit then summed across all traffic types.For the global beam GCbdi would replace ACbdi in the formula above. The formula can be used to calculate the uplink (forward) or downlink (return) peak broadcast data information rate for a specific beam and type carrier Pbi however, the applicable broadcast services may be different. Likewise, it is probable that broadcast transmissions from some AeES for some services will contain information that will be relevant to multiple AC and likewise that not all AES will broadcast information simultaneously. More work is needed to complete a more accurate method for calculating Pbi including a review of all broadcast services and their applicability to AMS(R)S.

3.2.2 Information volume determined from historical records[Editorial Note: content of this section to be developed]


- 36 -4C/TEMP/47-E

3.3 Circuit-mode and party-line voice carrier (not covered by packetized voice)

3.3.1 Information volume determined from estimated AMS(R)S communications requirements – use of the queueing model

[Editorial note: This section (3.3.1) needs to be reviewed and simplified if possible.]

[Editorial Note: As for the case of a data carrier, (section 3.1), the approach based on use of historical records determines the traffic requirements per AES using methodology based on past traffic records. However these rely heavily on known data volumes either through actual historical measured data traffic or via statistics. If this data is available it will greatly simplify the methodology. Also where historic data is available the average data traffic per aircraft within each satellite beam can be estimated from records. This allows any geographic variability in the average data traffic per aircraft to be readily estimated. However, where relevant historic or statistical information is not available the alternative methodology for developing the voice traffic requirements, based on the COCR, is therefore proposed below.]

The voice traffic is gradually being converted to packetized voice and such traffic as discussed earlier would be supported by the data carriers. In this section voice is provisioned on a switched circuit that provides dedicated channel bandwidth for the length of a transmission. The addressed or Party-line traffic requirements are computed with the objective that enough circuits must be available so that transmissions are not delayed or lost beyond acceptable performance levels.

Party-line is employed for normal communications, whereas communications of an urgent or secure nature would use private (addressed) line. Both party-line and addressed voice are calculated in the same manner shown below, but should be treated as a separate requirements since call traffic characteristics are different for each. The same is true when computing AOC and ATS voice traffic, each should be computed separately and the loads added before determining channel requirements. Regardless of the traffic load computed, it is assumed that a minimum of one voice line is needed per beam to meet the addressed voice needs and one voice line per control sector per beam is needed to meet the party-line voice needs. It is required to confirm the validity of the above assumptions.

The unit of information volume normally employed to determine capacity requirements for circuit switched voice is Erlangs. Erlangs represents the # voice circuits occupied during the busy hour. It is computed from the average holding time (H) per transmission multiplied by the average # transmissions per hour (#tx/Hr). It is a dimensionless term representing some multiple (fraction) of an hour. If H is in seconds then Va could be defined as Hsec × #tx/hr/3 600sec/hr.

Averaged unit information volume (erlangs) for circuit switched voice traffic to be handled by a satellite system (Va) can be obtained by aggregating the amount of circuit voice traffic over a given period of time tp (e.g. 1 hour) at the peak period of the day on the busiest day of the year. Va will then need to be distributed by beam and circuit type before computing the spectrum requirements,

Total circuit voice traffic per AeES in a given beam carrier (VbAeESi (Erlang)) can be obtained as:

VbAeESi = (Va/ACg) x rr x RTav x ACbAeESdi (39)

where

subscript “d” refers to the circuit voice service capable and “i" refers to support of a specific type carrier and:ACbdi: logged-on AES communicating via HF or Satellite (see equation 7a);ACg: logged-on AES communicating via HF or Satellite (see equation 2);


- 37 -4C/TEMP/47-E

rr: percent of all circuit based voice that is AMS(R)S priority 1-6;RTav: Ratio of voice messages transmitted via satellite (see discussion for

equations 18a, 18b).

[Note, the variable names above should be reviewed, e.g. replacing “AeES” with “g”]

For the global beam Vbi is computed using equation above but replacing ACbdi with GCbdi (see equation 7b).

The voice traffic per beam carrier (Vbi) may also be obtained by employing communication statistics. ATS voice transmission characteristics are provided in Table 6-24 of COCRv2 and are based on a survey of studies that evaluated both typical and worst-case conditions for various airspaces assuming limited or non-existent use of data communications. The ORP airspace values were estimated because of limited or non-existent reference data. [Only ATS Controller/pilot voice communication is provided as there was insufficient information to characterise AOC voice communication but it was assumed that the AOC voice communication is so limited that it does not contribute significantly to system loading.] [Comment: It appears that preceding sentence is not consistent with first sentence of section 3.3.2. It is required to further investigate applicability of addressed voice to ATS and AOC voice communications and their impact on system loading.] If the COCRv2 data were to be employed, the message arrival rate MARd would be the same as was computed for packetized voice earlier. Noting, as was discussed with packetized voice, Table 6-6 of COCRv2 shows that for AC equipped for voice and data only utilize voice 40% as often as voice only AC in the ENR airspace and only 5% as often in the ORP airspace. As such circuit voice traffic is a function of the number of AES that support circuit voice only and those that support circuit voice & data. For spot beams this is given as ACbh representing those that support circuit voice only and ACbk for those that support circuit voice as well as data. For the global beam it is GCbh for circuit voice only and GCbk for circuit voice as well as data. The AES are then further distributed by the type of carrier supported denoted by subscript “i”.

Vbi can then be calculated as follows:

For ENR Vbie = MARd x rr x He x (#tx/instance)e x (ACbhie + ACbkie x 40%)(40a)

For ORP Vbio = MAR x rr x Ho x (#tx/instance)o x (ACbhio + ACbkio x 5%) (40b)

Vbit = (Vbie + Vbio)t (40c)

Vbi = (t = 1_m) Vbit(40d)

where subscript “d” refers to the circuit switch voice service, “i" refers to a specific type carrier, “e” pertaining to the ENR airspace, “o” pertaining to the ORP airspace, “t” pertains to a specific air traffic type, “m” pertains to the total number of air traffic types and:

MAR: is the service arrival rate for voice;MQc: is the quantity of messages per packetized voice service instance and may be

calculated as H x PPS x #tx/instance (see above);rr: percent of all circuit based voice that is ITU priority 1-6;RTav: is the % of voice messages transmitted via satellite;ACbhie: AES count within ENR airspace BLOS to VHF, ckt voice only;ACbhio: AES count within ORP airspace, ckt voice only;ACbkie: AES count within ENR airspace BLOS to VHF, ckt voice & data;ACbkio: AES count within ORP airspace, ckt voice & data;


- 38 -4C/TEMP/47-E

Vbit: voice traffic per beam carrier due to a class of air traffic.

NOTE – At the beginning of the methodology it was stated that due to the different characteristics of each air traffic type including: equipage, usage, etc. traffic requirements would be developed separately for each traffic type and then summed for each beam. In the above formulas Vbi is computed for each traffic type Vbit then summed across all traffic types.

Vbi is also computed for the global beam with GCb replacing ACb everywhere in the above formulas.NOTE – Currently, some AMS(R)S systems use C21K and C8.4K carriers , dependent on type of AES, for service link voice communications.

[Editorial Note: the COCRv2 only provides party-line statistics related to ATS services. Additional statistics are needed to determine average circuit voice traffic per AES in each airspace type for each service type]

3.3.2 Information volume determined from historical records

[Only AOC communication services utilize addressed voice. The voice load associated with AOC is stated in the COCR to be negligible.] [Comment: As mentioned above, the preceding sentence is not consistent with the sentence highlighted in section 3.3.1. It is required to further investigate applicability of addressed voice to ATS and AOC voice communications and their impact on system loading.] Both party-line and addressed voice are calculated in the same manner, but should be treated as a separate requirements since call traffic characteristics would be different for each. [Regardless of the traffic load computed, it is assumed that a minimum of one voice line is needed per beam to meet the addressed voice needs and one voice line per control sector per beam is needed to meet the party-line voice needs.] [Comment: the preceding sentence should be reviewed]The voice traffic is gradually going to be converted to packetized voice and such traffic would be supported by the data carriers. The voice traffic will be divided for each beam by corresponding number of AES to be handled.

Then they are distributed to each type of carrier concerned.

Total voice traffic per GES in a given beam (Vb g (Erlang)) can be obtained as:

Vbg = (Va × ACg )/60 (41)

where Va is the averaged voice traffic in minutes obtained from equation 6f above.

[Note: The applicability of converting to a reference period of 1 minute by dividing by 60 should be reviewed]

.

For the established satellite networks, based on the past traffic data records, the value of Va can vary in each satellite ocean region as well as in each beam within the given satellite ocean region. This information can be derived from the past traffic records.

Averaged unit information volume for voice signal to be handled by a satellite system (Va) can be obtained by aggregating the amount of voice traffic over a given period of time tp (e.g. 1 hour) and at the peak period in the busiest day of the year.

Total voice traffic (Vbg) can be divided for each type of carrier as: Vbg j = rvj × Vbg (42b)

wherervj: ratio of traffic volume for voice carrier type (j) to total traffic volume.


- 39 -4C/TEMP/47-E

In this case, rvj would be some percentage of the AES models supporting addressable or party-line voice that also support a carrier type.

NOTE - Currently, some AMS(R)S systems use C21K and C8.4K carriers , dependent on type of AES, for service link voice communications.

3.4 Circuit-mode broadcast voice carrier

3.4.1 Information volume determined from estimated AMS(R)S communications requirements – use of a queueing model

[Editorial note: This section (3.4.1) need to be reviewed and should include a practicable method as appropriate.]

One forward direction broadcast voice channel per air space is assumed to provide sufficient capacity to handle the voice broadcast message load until AMS(R)S broadcast voice traffic characteristics can be obtained. The broadcast voice beam channel requirements is estimated by adding one broadcast voice circuit for each airspace pertaining to a phase of flight that overlaps the satellite beam with the total circuit requirement referred to as (Ne).

[Editorial Note: A review of all broadcast voice messages and their applicability to AMS(R)S is needed. Traffic characteristics including: the number of messages sent by operational volume, and message lengths, i.e. holding time is needed. ]

[Editorial note: It is unclear as to the need for air to ground broadcast voice so it is not included at present. This assumption should be confirmed.]

3.4.2 Information volume determined from historical records[Editorial Note: content of this section to be developed]


- 40 -4C/TEMP/47-E

4 Calculate required bandwidth for each beam and type of carrier

4.1 Data communications including broadcast data

[Editorial Note: In the equation below, it is assumed that Pdi represents only the information required, and excludes transmission overheads. This needs to be checked particularly in the context of use of historical data – does the historical data provided consist of only the information or does it already include the transmission overheads such as those identified in equation (45)? This could have an impact on how Cdi should be calculated]

a) The required number of specified circuits per beam and GES (Ndig) can be calculated by the following formula:

Ndig = Roundup(Pdi/Cdi) (44)

wherePdi: peak data rate to be supported by a circuit (kbit/s);Cdi: effective transmission rate, i.e. transmission capacity of the normalized data

carriers in kbit/s taking into account the channel overhead. One approach to calculate Cdi is given below.

[Editorial Note: the effective transmission rate may depend on the channel state, for example in systems which use adaptive coding or modulation. Further considerations are needed on how such systems should be handled .]

[Editorial Note: In the following text if ki is large, can this lead to a negative value of Cdi? This equation should be further reviewed.]

The effective carrier transmission rate (Cdi) that is available to deliver the service data may be determined as follows:

Cdi = (RTi − Rh − Rf − Rs − Re − ki(Rg + Rp)) × (1 − rr) (45)where

RTi = carrier transmission rate (kbit/s);ki = the number of ACbi or GCbi supporting data and the carrier type being

analysed;Rh = protocol header bit rate: addressing, COS, msg length, frame check sequence,

etc. (kbit/s);Rf = reference info bit rate: synchronization bits, pilots, channel state information,

etc. (kbit/s);Rs = signalling bit rate:enhance frame exchange, automatic repeat request, other call

establishment signalling (kbit/s);Re = error correction bit rate: coding, parity (kbit/s);Rg = guard time bit rate: for TDMA carriers (kbit/s);Rp = preamble bit rate (kbit/s);rr = ratio of retransmissions due to fading, interference, collisions (a number

between 0 and 1).


- 41 -4C/TEMP/47-E

Rh, Rf, Rs, Re, Rg, and Rp are defined by the carrier type employed and only include overhead associated with layers 1 & 2 of the OSI model. Parameter rr would need to be determined from statistics gathered or from system simulations.

[Editorial Note: How should rr be determined?]

The required number of broadcast carriers Nbi is computed in a like manner as Ndi using equations (44) and (45). Note that broadcast channels would repeat messages at certain interval, and therefore there should be no retransmission factor associated with this calculation.

NOTE – For packetized voice and broadcast, if multicast is employed to limit the stations receiving transmissions, i.e. party-line or broadcast adjustments may be needed in equation (45) to account for traffic associated with maintaining group membership as well as any additional protocol overhead.

b) The required bandwidth per beam and GES (SRdg) can be calculated by the following formulas:

SRdg is determined by multiplying the carrier separation for the respective types of carrier (Ddi) and the required number of carriers by accumulating all type of carriers as follows:

SRdg = Sum(BWdig) + SRxig (47a)

where BWdig: calculated bandwidth for specific type of carrier (i)

= Ndig × Ddi (kHz) (46)Ddi: Carrier separation between data carriers in kHz.SRxig: spectrum requirement for the network control per GES and etc

[Editorial Note: it should be ensured that the effective transmission rate calculated above does not include the spectrum requirements for network control, to avoid this requirement from being double counted]

Then, total spectrum requirement for data carriers in a beam (SRd) can be obtained as:

SRd = Sum (SRdg ) (48)

NOTE – In the above discussion forward and return link requirements may be calculated separately, i.e. SRd(fwd) and SRd(ret), as these links may have different characteristics and traffic loading.

The spectrum requirements resulting from the broadcast data information load is computed in a like manner as above making the necessary adjustments to the above equations such as replacing the input Pdi with Pbi, the intermediate term Nd is changed to Nb, and the output term SRd becomes SRbr to indicate it is a different spectrum requirement, i.e. for broadcast data in forward link.

4.2 Circuit-mode voice communications for addressed and Party-line demand

The number of circuits required for circuit voice communications number of required voice channel (Nv) can be obtained by the Erlang B formula. The detailed description of the method to obtain the number of circuits is given section 7.5 of reference 5, i.e., ITU-D SG2 publication “Handbook Teletraffic Engineering”, Jan 2005.

The goal of Erlang traffic theory is to determine exactly how many service-providing elements should be provided in order to satisfy users, without wasteful over-provisioning. To do this, a target


- 42 -4C/TEMP/47-E

is set for the grade of service (GoS) or quality of service (QoS). For example, in a system where there is no queuing, the GoS may be that no more than 1 call in 100 is blocked (i.e., rejected) due to all circuits being in use (a GoS of 0.01), which becomes the target probability of call blocking, Pb, when using the Erlang B formula.)

[Editorial Note: There are a number of references that propose a GoS of .01 call loss. The most appropriate for aviation safety should be referenced here]

In some established satellite networks it is common to allocate certain minimum number of channels Nvg min for each GES in a given beam. For each voice carrier type, the required number of channels are calculated as per the Erlang B formula for a given grade of service (GoS). Then the maximum of the numbers is taken, i.e.:

Nvig = max (N viming, Nvi Erl-Bcal) (49)where

N vi min g: minimum number of channels per GES required for each voice carrier type;N vi Erl cal: number of channels based on Erlang-B formula calculations for each voice

carrier type.

The required bandwidth (SRv) can be calculated by multiplying the carrier separation for the respective types of carrier (Dv) and the required number of carriers and accumulating all types of carrier

Then, total spectrum requirement for voice carriers in a beam (SRv) can be obtained as:

SRv = (i= 1 to n) (g= 1 to m (BWvi,g) (51)where

n : total number of carrier types supported;m : total number of GES serving the beam;BWvig: bandwidth required for one specific carrier in kHz;

= Nvig × Dvi (kHz) (50) Nvi: number of carriers(i);Dvi: nominal separation between voice carriers in kHz.

In general the spectrum requirements for circuit-mode voice in the forward and reverse directions are equivalent. However it is assumed that the broadcast voice is only in the forward direction so SRv(fwd) is calculated as above while SRv(Rev) would exclude the term Nbj in the above calculations.

5 Spectrum requirements for a network under consideration

5.1 Calculation of total spectrum requirements per beam

Total forward and return spectrum requirements per beam can be obtained as:

SRf = SRd(fwd) +SRb(fwd) + SRv(fwd) (52a)

SRr = SRd(ret) [+SRb(ret)] + SRv(ret) (52b)where

SRd: required spectrum for data signal per beam;


- 43 -4C/TEMP/47-E

SRb: required spectrum for broadcast data signal per beam [Note: In the preceding text it is assumed that there is no return link broadcast requirement, in which case SRb(ret) may not be required];

SRv: required spectrum for voice signal per beam;

SRf: required forward spectrum per beam;

SRr: required return spectrum per beam.

During the frequency coordination discussions, the spectrum assigned per beam should take into account further constraints such as those from the satellite transponder channelisation.

5.2 Calculation of spectrum requirements for service area with beam cluster

Spectrum requirements for specific service area with beam cluster (SRa) can be obtained by taking into account of reuse factor within cluster as follows:

SRa = Nb x SRc/ ru (52c)

whereSRc: spectrum requirements obtained for single beam element in the cluster;Nb: number of beam element in a beam cluster;ru: spectrum reuse factor (>= 1) enabled by beam element delivery;

[Editorial note: this section should be reviewed. A more detailed approach should be considered as an alternative, which , for example, would determine the spectrum requirements for each beam in the cluster individually, then determine the overall spectrum requirements considering the frequency re-use between specific beams.]

5.3 Calculation of total spectrum requirement for a satellite network

Total AMS(R)S spectrum requirements per satellite (SRa) can be obtained by summing spectrum requirements of each beam, including the global beam and applying factors of reuse and as follows.

SRfa = (SRfgi = (1 to n) SRfi/ru) (53a)

SRra = (SRrg + i = (1 to n) SRri/ru) (53b)where

SRfg: forward spectrum requirements for global beam;SRrg: return spectrum requirements for global beam;SRfi: forward spectrum requirements for a specific spot beam;SRri: return spectrum requirements for a specific spot beam;SRfa: total satellite forward spectrum requirements;SRra: total satellite return spectrum requirements;n: total number of active beams (#B) in the satellite system;ru: spectrum reuse factor (> 1) enabled by spot beam delivery;

[Editorial note: if this section is retained, it should be reviewed. A more detailed approach should be considered as an alternative, which , for example, would determine the spectrum requirements for each beam within the satellite individually, then determine the overall spectrum requirements considering the frequency re-use between specific beams.]


- 44 -4C/TEMP/47-E

APPENDIX A TO ATTACHMENT 1

Appendix A provides reference information tables. This information yet to be finalized and would be updated in due time.

TABLE A1

ITU-COCR service cross-classification

ITU priority level

COCRATS AOC

1

Distress calls, distress message and distress traffic

Data Link Alert

Urgent Contact

2Communications preceded by the urgency signal

3Communications related to radio direction-finding

4 Flight safety messages

ATC Clearance Notice to Airmen (NOTAM)Departure Clearance Flight Plan Data (FLTPLAN)Downstream Clearance Load Sheet Request/Transfer (LOADSHT)ATC Microphone Check Update Electronic Library (UPLIB)Data Link Taxi ClearanceCommon Trajectory CoordinationData Link Automatic Runway Visual RangeData Link Automatic Terminal Information ServiceData Link Operational Terminal Information ServiceData Link Operational En Route Information ServiceDynamic Route AvailabilityAir Traffic Control SurveillanceFlight Plan ConsistencyFlight Plan IntentSystem Access ParametersTraffic Information ServiceIn-Trail ProceduresMerging and SpacingCrossing and PassingPaired ApproachAir-to-Air Self SeparationAir Traffic Control SurveillanceData Link Surface Information and GuidanceWake Service


- 45 -4C/TEMP/47-E

ITU priority level

COCRATS AOC

Data Link Significant Meteorological InformationPilot Preferences DownlinksData Link LogonATC Communication ManagementAuto Execute

5 Meteorological messages

Textual Weather Reports (WXTEXT)Real-time Weather Reports for Met Offices (WXRT)

Graphical Weather Information (WXGRAPH)

6 Flight regularity messages

Data Link Flight Update Flight Status (FLTSTAT)Arrival Manager Information Delivery Maintenance Problem Resolution (MAINTPR)

Real-Time Maintenance Information (MAINTRT)

AOC Data Link Logon (AOCDLL) Position Report (POSRPI)

Out-Off-On-In (OOOI) Cabin Log Book Transfer (CABINLOG) Technical Log Book Update (TECHLOG) Fuel Status (FUEL) Gate and Connecting Flight Status (GATES) Engine Performance Reports (ENGINE) Flight Log Transfer (SWLOAD)

7

Messages related to the application of the United Nations Charter

8

Government messages for which priority has been expressly requested

9

Service communications related to the working of the telecommunication service or to communications previously exchanged

10

Other aeronautical communications

Free Text (FREETEXT)

Software Loading (SWLOAD)It should be noted that Table A1 has been developed based on the information in the COCR [if possible, reference to the relevant part of COCR should be added].


- 46 -4C/TEMP/47-E

TABLE A2

Phase of flight air space characteristics

NOTE – The nomenclature FL+ # refers to a flight level at an altitude of # x 100 feet, e.g., FL245 refers to an aircraft flying at an altitude of 24,500 feet.

TABLE A3

FCS Service volume characteristics

NOTE - TV stands for traffic volume.

TABLE A4

AMS(R)S applicable services [Note: information related to APR, TMA domains to be added as well]

ITU Priorit

y Level

Scv Abbrv Service name Type ENR ORP

0 NETCONN Network Connection Ntwk x x0 NETKEEP Network Keep Alive Ntwk x x

4 ACL ATC Clearance ATS x x4 ACM ATC Communication Management ATS x x

4 AMC ATC Microphone Check ATS x o6 AOCDLL AOC Data Link Logon AOC o x

6 ARMAND Arrival Manager Information Delivery ATS x x

4 C&P ACL Crossing and Passing ATS x x


- 47 -4C/TEMP/47-E

4 C&P SURV Crossing and Passing ATS x x1 D-Alert Data Link Alert ATS x x

4 D-ATIS (Arrival)

Data Link Automatic Terminal Information Service

ATS x o

ITU Priorit

y Level

Scv Abbrv

Service name Type ENR ORP

4 DLL Data Link Logon ATS x x4 DYNAV Dynamic Route Availability ATS x x

4 D-ORIS Data Link Operational En Route Information Service

ATS x x

4 D-OTIS Data Link Operational Terminal Information Service

ATS x o

4 D-RVR Data Link Automatic Runway Visual Range

ATS x o

4 DSC Downstream Clearance ATS x x4 D-SIGMET Data Link Significant Meteorological

InformationATS x x

6 ENGINE Engine Performance Reports AOC x o

4 FLIPCY Flight Plan Consistency ATS x x4 FLIPINT Flight Plan Intent ATS x x

4 FLTPLAN Flight Plan Data AOC x x6 FLTSTAT Flight Status AOC x x

6 FUEL Fuel Status AOC x x6 GATES Gate and Connecting Flight Status AOC x o

4 ITP ACL In-Trail Procedures ATS o x4 ITP SURV o x

4 M&S ACL Merging and Spacing ACL ATS x o4 M&S SURV Merging and Spacing SURV x o

6 MAINTPR Maintenance Problem Resolution AOC x x6 MAINTRT Real-Time Maintenance Information AOC x x

4 NOTAM Notice to Airmen AOC x x6 POSRPT Position Report AOC x x

4 PPD Pilot Preferences Downlinks ATS x x4 SAP System Access Parameters ATS x o

4 SAP PR System Access Parameters (Periodic Report)

ATS x o

4 SURV Air Traffic Control Surveillance ATS x x4 TIS-B Traffic Information Service ATS x o

1 URCO Urgent Contact ATS x o4 WAKE Wake Service ATS x o

5 WXGRAPH Graphical Weather Information AOC x x


- 48 -4C/TEMP/47-E

5 WXRT Real-time Weather Reports for Met Offices

AOC x x

5 WXTEXT Textual Weather Reports AOC x x

“x” denotes service applicability to an airspace (ENR or ORP) and “o” denotes none[Editorial Note: Table to be updated with other airspace types]

TABLE A5

AMS(R)S message characteristics[To be added]

TABLE A6

AMS(R)S COS performance factors[To be added]

TABLE A7

Transmission ranges and propagation times

Transmission VolumeAir Space ENR ORPAir-Ground SURV (NM)

200 200

Air-Ground Propagation Time (sec)

[PG]

.00123 .00123

APPENDIX B TO ATTACHMENT 1 (TBD)

[Editorial Note: Appendix B may provide input summary table and detailed description of how to obtain the input data]


- 49 -4C/TEMP/47-E

APPENDIX C TO ATTACHMENT 1

Appendix C provides the worksheets associated with calculations.

The following example output information is related to the approach presented in Document 4C/633 only and is not applicable to the approaches presented in Documents 4C/628 and 4C/653. In future the example output format and its content would be aligned with the Methodology to be agreed to.

[Example output form of calculation and its conditions

The example output form of calculation and its conditions provided in Table 1 illustrates the relationship of the computed spectrum requirements of an AMS(R)S satellite network to the input parameters and associated assumptions used in the calculations.

TABLE 1

Item　 Code Unit Airspace

1Airspace-

2 Formula/Note

AC 　　　　　　　

　 Peak Log-on AES to the Network ACn AC 250 Estimate　(1)

　 AES ratio for Spot Beam ra % 10 Estimate　 Peak Log-on AES to the Airspace ACa AC 225 25 ACn*ra

Traffics 　　　　　

　 Average Unit Data Traffics Da Kbit/AC・h

50 Past Record (2)

　 Total Data Traffics Dt Mbit/h 11.25 1.25 ACa*Da　 Average Unit Voice Traffics Va Erl 0.01 Past Record (3)

　 Total Voice Traffics Vt Erl 2.25 0.25 ACa*VaBeam 　　　　　

　 Number of Satellite Ns n 2 Spec (4)　 Number of Beams per Satellite Nb n 1 6 Spec (5)

　 Spot Beam Concentration Factor bc n - 2.4 Estimate or Nb^0.5 (6)

　 Peak Log-on AES to Beam ACb AC 112.5 5.2 ACa*bc/(Ns*Nb)Data 　　　　　

　 Total Data Traffics per Beam Tb Mbit/h 5.625 0.26 Da*ACb　 hour to Second Conversion Factor rp n 1.2 Estimate

　 Peak Data Rate per Beam Rd kbit/s 1.88 0.09 Tb*hs/3600

　 Type of Data Carrier 　　 R/T600 R/T10500 　

　 Bearer Rate Tr bit/s 600 10500 Spec　 Effective Transmission Rate Cd bit/s 43.2 851 Estimate (7)

　 AES Carrier Type distribution ratio rd n 0.2 0.8 Past Record


- 50 -4C/TEMP/47-E

Item　 Code Unit Airspace

1Airspace-

2 Formula/Note

　 Beam 　　 Global Spot Global Spot 　

　 Peak Data Rate per Type of Carrier Pd ｋbit/s 0.38 0.02 1.50 0.07 Rd*rd

　 Number Of Data channels Nd ch 9 2 2 2 Pd/Cd or 2　 Carrier Separation Dd kHz 5 10 Spec (8)

　 Bandwidth for Data Channel BWd kHz 45 10 20 20 Nd*DdAdditional Spectrum for System Control SRx kHz 50 0 - - Spec (9)

Voice 　　　　　　　

　 Beam 　　 Global Spot 　

　 Total Voice Traffics per Beam Vb Erl 1.125 0.052 ACb*Va　 hour to Peak Conversion Factor rp n 1.5 Estimate

　 Peak Voice Traffics per Beam Rv Erl 1.52 0.07 Vb*rp　 Call loss Lc n 0.01 Spec (10)

　 Type of Voice Carrier 　　 C21K C8.4K 　

　 AES Carrier Type distribution ratio rv n 0.9 0.1 Estimate

　 Beam 　　 Global Spot Global Spot 　

　 Peak Voice Traffics per Type of Carrier Pv Erl 1.52 0.07 0.17 0.01 Rv*rv

　 Reserved channel per beam Nr ch 1 0 1 0 Emergency use

　 Number of Required Voice channels Nv ch 6 2 3 1 Erlang Table (Pv, Lc)

　 Carrier Separation Dv kHz 17.5 7.5 Spec(8)

　 Bandwidth for Voice Channel BWv kHz 122.5 35 30 7.5 （Nv+Nr)*Dv

　 Required Rough Spectrum SRr KHz 535 870 (SRd+SRv)*Nb*Ns

　 Reuse Factor ru n - 1 Spec　 Band Efficiency be n 0.9 Estimate (11)

　 Required Total Bandwidth SR KHz 594 966 SRr/(be*ru)

NOTE − Some expressions and examples are provided for clarifications.1) ra: Ratio of the AES operating within specified airspace

It is assumed that 10% of AES served by the cluster of 6 spot beams and the remaining 90% served by the global beam airspace.

2) Da: Averaged unit data traffics to be handled by an AES(kbit/hour)Data traffic of 50 kbits per hour for every AES is assumed.

3) Va: Averaged unit voice traffics to be handled by an AES(Erlang/hour)0.01 Erlang of voice traffic per AES is assumed.

4) Ns: Number of satellite if different satellite is covering same beam area simultaneouslyIt is assumed that traffic is split equally between two AMS(R)S satellite serving same airspace.

5) Nb: Number of spot beam in the airspace


- 51 -4C/TEMP/47-E

It is assumed that AMS(R)S satellite is configured with one global beam and 6 spot beams.


- 52 -4C/TEMP/47-E

6) bc: Spot beam peak-to-average ratio (%)As distribution of AES among spot beams will not be equal, it can be assumed that peak to average ratio is (Nb)0.5. In the case of 6 spot beams, bc = 60.5 = 2.4.

7) Cdi: Effective transmission rate (kbit/s)Transmission capacity of the normalized data carriers can be estimated as follows:

Cd = Tr × oh × erwhere:Tr: Bearer rate;oh: Coding efficiency including over head of digital signal, estimated as 60%;er: Signal processing and channelling efficiency, assumed as 30%.

8) Ddi: Carrier separation between data carriers in kHz;

Dvj: Carrier separation of the normalized voice carrier in kHz.

Inmarsat Classic Aero carrier types used for AMS(R)S data and voice communications and their characteristics are shown below:

Signal Carrier type Bearer rate(bit/s)

Carrier separation

(kHz)Data R/T 600 600 5

R/T 10500 10 500 10Voice C 21 21 000 17.5

C 8.4 8 400 7.5

9) SRxi: Additional spectrum requirement for network control, etc.Additional 100 kHz spectrum is assumed for control channels.

10) Lc: acceptable call loss (Lc, %)Call blocking rate requirement of 1 call per 100 calls (1%) is assumed.

11) be: Inefficiency due to carrier arrangements (< 1)90% bandwidth efficiency for the AMS(R)S network is assumed.]


- 53 -4C/TEMP/47-E

APPENDIX D TO ATTACHMENT 1

Appendix D provides a citation reference list.

Citation reference list

(Ref 1) T. Gooble, EUROCONTROL/FAA Future Communications Study Operational Concepts and Requirements Team “Communications Operating Concept and Requirements for the Future Radio System”, COCR Version 2.0, May 28, 2009 http://www.eurocontrol.int/communications/gallery/content/public/documents/COCR%20V2.0.pdf

(Ref 2) H. Boithias, A. Frizon, X. Ibos, A. Martin, EADS , “Classification of the air traffic services and safety related aeronautical operation control communications according to the ITU priority level aeronautical communications panel (ACP)”, Working Group F # 19, Montreal, Canada 15 – 19 September 2008, ACP-WGF 19/IP01, 18/07/08 www.icao.int/anb/panels/acp/wg/f/wgf19/acp-wgf19-ip01_eads.doc

(Ref 3) Eurocontrol/FAA: Future Communications Study (FCS) – Operational Concepts and Requirements Team, “Future Communications Infrastructure- Technology Investigations Evaluation Scenarios” Version 1.0, 3 May 2007.

(Ref 4) Hung, B, 1-3 May 2006, “A Method for Estimating Air/Ground Data Capacity Requirements”, 2006 NASA ICNS Conference and Workshop, Baltimore, MD. http://i-cns.org/media/icns/2006/06_Session_B1/07-Hung.pdf

(Ref 5) ITU–D Study Group 2, Question 16/2, “Handbook TELETRAFFIC ENGINEERING”, Geneva, January 2005, First edition of the Teletraffic Engineering Handbook worked out as a joint venture between the ITU – International Telecommunication Union, and the ITC – International Teletraffic Congress,http://www.ece.mcmaster.ca/faculty/teds/COURSES/731-folder/CLASS-NOTES%20folder/ITU-Teletraffic-Engineering-Handbook-2005.pdf

_______________


http://www.ece.mcmaster.ca/faculty/teds/COURSES/731-folder/CLASS-NOTES%20folder/ITU-Teletraffic-Engineering-Handbook-2005.pdf

http://www.ece.mcmaster.ca/faculty/teds/COURSES/731-folder/CLASS-NOTES%20folder/ITU-Teletraffic-Engineering-Handbook-2005.pdf

http://i-cns.org/media/icns/2006/06_Session_B1/07-Hung.pdf

http://www.icao.int/anb/panels/acp/wg/f/wgf19/acp-wgf19-ip01_eads.doc

http://www.eurocontrol.int/communications/gallery/content/public/documents/COCR%20V2.0.pdf

http://www.eurocontrol.int/communications/gallery/content/public/documents/COCR%20V2.0.pdf