ACP WG S-3 WP11
WG82White paper on AeroMACS deployment scenarios and derived requirements
SITA - Aircraft Services
Issue 3
23 April 2019
1.Deployment models
This section defines the preferred deployment models for AeroMACS for aircraft – it is extracted from Draft 10 of Eurocae AeroMACS MASPs.
Deployment models for vehicle and fixed applications are not addressed here.
1.1Assumptions
The following applications have been identified as target by RTCA SC223 and/or Eurocae WG82:
Fixed users (RTCA only) (fix information rate: eg UGS, on separate LANs, or network)
–Airport LAN extensions
Unique equiment (terminals, cameras,…)
Or Multiple equipment behing MS
–ANSP managed equipment
Integration of RNAV systems, radar… into ANSP network
Mobile users
–Airport trucks (catering, maintenance, fuel….)
–Luggage terminals,…..
–Single users (= user terminal) belonging to different networks or LANs (!) (airport, MRO, catering, fuel……)
–Support for VoiP (RTCA only)
Aircraft
–ATC, AOCdirect operational impact and/or safety impact
–AAC applications no direct operational impact
The following entities can be involved in AeroMACS service:
- ANSPs
- Airport telco operator
- Airline
- ACSP =Aeronautical communication service provider (AVICOM, SITA, ARINC, ADCC)
- CSP (Communication - Mobility Service Providers)(new-otherglobal service provider)
Reminder of NAP/V-NSP/H-NSP services and possible actors
Airport telco operator / ANSP / ACSP / CSP / AirlineNAP / x / x / x
V-NSP / x[ACU1][FD2] / x / x
H-NSP / X for vehicles / x / x / x
1.2NAP sharing by multiple NSP
This deployment model should be preferred by NSP and NAP in order to rationalize infrastructure, ease cell planning at a given airport, and minimize interference on legacy systems (e.g. GlobalStar) with probably less Base Stations due to a more efficient use of the spectrum
Figure 14: Single NAP - Multiple NSP
.
Several CSNs might share the same ASN Several ASNs might be connected to a single CSN [ACU3]and vice-versa i.e., several CSNs might share the same ASN. The most[FD4] common deployment expected is one single ASN within the airport and multiple operators (CSNs) connected. Hence, this is the most likely business scenario that could be spotted for AeroMACS.
Airport telecom operatorThe NAP (airport telco operator, ANSP..) [ACU5]deploys and provides servicesthe access network to ARINC, SITA, NAVICOM, etc. playing the role of a H-NSP who manages[FD6] the relationship with airports on behalf of the airlines. Some aAirlines could have contractual agreements to with different H-NSPnand other airlines could keep contracts with other H-NSP. [ACU7][ACU8]
In[FD9] this scenario, ASN-GW will advertise for incoming new MSs on the Access Network that there are different NSPs (see section 3.2.2), enabling the MS to establish data communication to its NSPs through AeroMACS ASN and leading them to reach final airline operator.
1.3Single NSP Providing Access through Multiple NAPs[ACU10]
This deployment model should be foreseen by NSP [FD11]to extend its coverage at regional scale in relying on local NAP (e.g. extension to several airports by one service provider like SITA or ARINC).
Figure 15: Multiple NAP - Single NSP
If one NAP cannot provide full coverage for an NSP in a given area, the NSP can have agreements with multiple APs.
This would be a feasible topology in order to give AeroMACS ATS service support and core integration to the backbone. The cost of integration will be set to the minimum due to the NSP is just a single operator and it’s isolated to each airport domain.
As a hypothesis, all the services would be provided by components inside the airport network managed by a single network/service operator. In consequence, all the sensitive servers needed (mainly AAA and DHCP) would be set and placed locally. Besides, servers to be reached for provisioning data sessions would be found physically within the airport facilities. Therefore, there’s no need to enable VPN end to end connectivity, packet forwarding or relay functions. In addition, there won’t be time delay constraints on the service provisioning since this model behaves as standalone.
As a drawback of this standalone scenario, the routing tables in the network routers must be updated efficiently to reflect the pathway to reach the mobile node from the backbone network to the Access Network.
1.4Greenfield WiMAX NAP+NSP[ACU12]
These deployment models should be foreseen by manufacturers and operator since they let flexibility to NSP to act or not as NAP depending on local issue. [ACU13]
This model is not suitable to ANSPs but rather to ACSPs in areas where they will be allowed to act as NAP.
Figure 16: Greenfield NAP-NSP
Thus is to say, SITA, ARINC, NAVICOM… could be deploying itself on the airport ground network side acting as the same entity for the NAP and NSP on the business model[FD14].[ACU15]
1.5WiMAX Roaming scenarios with Data access via Visited NSP
The following cases are deemed relevant for aviation purposes;
Data access via visited NSP: This deployment model should be foreseen by NSP to let the opportunity for the V-NSP to operate the Home Agent.[ACU16] The benefits of the first approach (local Home agent – see figure 17) to optimize performances and have direct local access to ATM ground network, rather than having all traffic flowing to a central HA located in a remote location (shown in figure 18).
Several technical solutions are under definition to handle Route Optimizatio (‘RO’ with Mobile IP).
One option is the Global HAHA (where local Home agents can be deployed as illustrated in figure 17), the other corresponds to the use of Correspondent routers (CR) operated locally by ANSPs. In all cases, a global home agent must be accessible permanently. In figure 17, the HA shown in the V-NSP can thus be a Correspondent router instead.
Note: SANDRA project concluded that use of CR versus global HAA was more appropriate to AT communications.
Figure 17: Roaming scenario 1
Data access via home NSP
Figure 18: Roaming scenario 2
2.Deployment assumptions proposed
In a number of regions, the AeroMACS license will be acquired by the Aviation Authority and may be granted to ANSPs directly or to Airport telecom entity or subcontracted for operation to a service provider.
In other regions, service providers such as ARINC and SITA could be granted a specific AeroMACS channel for AOC and ATC operations.
The most likely deployment scenarios are illustrated in the table below:
UC N° / Description / NAP / V-NSP / H-NSP / Deployment model / Segregation between types of serviceUse case 1 / No Fixed services
Mobile and Aircraft services on same channels / Airport telco
(only one NAP..) / Airport telco
(for vehicle: H-NSP=V-NSP) / For aircraft:
ACSP
CSP
The airline itself / -NAP sharing by multiple NSPs.
-One NAP
-NSP providing access through multiple NAPs / Segregation between vehicle/aircraft by using different Service flows
Use case 2 / No Fixed services
Mobile services on a specific set of channels / Airport telco for mobile / Airport N/A[ACU17] telco for mobile / N/A[ACU18]Airport telco for mobile / Segregation between vehicle/aircraft by using different channels
Aircraft services on a specific set of channels / ANSP for aircraft (one NAP only for aircraft) / ANSP for aircraft / For aircraft:
ACSP
CSP
The airline itself / -NAP sharing by multiple NSPs
-Several NAPs
Use case 3 / Aircraft services on a specific set of channels / SITA
ARINC
MSP / DSP / For aircraft:
ACSP
CSP
The airline itself / -Greenfield NAP+NSP
-Several NAPs / Segregation between vehicle/aircraft by using different channels
Use case 4
(at airline Hub) / No Fixed services
Mobile and Aircraft services on same channels / Airline?
Or subcontracted / Airline? / Or subcontracted / -Greenfield NAP+NSP
-One NAPs
3.Network concept assumptions:
- Aircraft mobility will be managed by a central Mobility Service Provider (ACSP or CSP) (ARINC, SITA, others) (=aircraft H-NSP)
- The aircraft will be granted a number of IPv6 addresses in the address space allocated to the airline (if address structure concept from SANDRA /similar concept is maintained/accepted).
- The aircraft router will use X509 certificates for EAP-TLS authentication, using as C/N realm possibly the airline name[ACU19], or any PKI provider name[FD20].
- The H-NSP AAA server will receive auth traffic with username realm possibly being the airline – this means that the airport Proxy AAA will need to map the realm value with the H-NSP AAA address, which is not obvious.
4.NAP and NSP selection process
Overview Network entry[FD21]:[ACU22]
- During the scanning process the aircraft needs to be able to determine if it is on a channel / NAP providing aircraft communication services
- If the NAP is providing aircraft communication services, the aircraft can either check that its H-NSP is connected or decide to authenticate directly
- If the authentication is successful, it means that the NAP/V-NSP is able to contact the H-NSP.
- Then the MS can perform NET entry and be allocated a CoA (Care Of Address).
- MS establishes MIP tunnel to H-NSP Home Agent
- MS can then be contacted using its Home IP address through the Home Agent at H-NSP
2
3
4
4.1Overview of WMF description
Please refer to section section 4.1 of WMF-T33-001-R010v05_Network-Stage3-Base3 for a detailed description of NET entry discovery and selection.
If we want to summarize, the NAP is identified by an ‘Operatord Id’ (see paragraph below).
The NSP is identified by an NSP Id (see paragraph below).
Operator Id (NAP)
The most significant 24 bits (MSB 24 bits) of the “Base Station ID” SHALL be used as Operator ID, which is the NAP Identifier. NAP discovery is based on the procedures defined in IEEE Std 802.16 [1] and out of the scope of this specification. Operator ID/NAP ID allocation and administration method are managed by IEEE Registration authority which defines the range for global IDs assigned by IEEE and the range for MCC/MNC IDs which can be also used. The field formatting is defined in IEEE Std 802.16.
NSP Id:
In the NAP+NSP deployment case where there is only one NSP associated with the NAP and where no regulatory or 14 deployment reasons compel separate presentation of an NSP identifier, the NAP SHALL set NSP Identifier Flag to a 15 value of ‘0’. In this case, when the MS detects the identifier of a NAP, the MS knows the identifier of associated NSP. The MS MAY continue NSP discovery to obtain verbose NSP name of the NSP.
NSP ID is formatted as a 24 bit field that follows the format shown in Figure below:
Authentication process: (as described in section 4.1.2.4 of WMF-T33-001-R010v05_Network-Stage3-Base3 – ASN attachment)
The MS shall format the NAI (Network Access Identifier) used as an outer identity during EAP exchanges as follows:
<routing realms<WiMAX decoration<username>@<realm>Where:
routing realms: Optionally used. The use of routing realm is described in [3]. Example: hnsp1.com!
WiMAX decoration: Optionally used to indicate various MS capability/intent. The WiMAX decoration is extensible. The WiMAX decoration consists of one or more attribute value pairs (avp) separated by the ‘|”enclosed within curly braces.
“{“ avp1 “|” avp2 ….“}”
where an avp is formatted as: name“=”value with no spaces before and immediately after the “=”.
The character set used for name and value must be consistent with the character set specified by [3]. The name 18 must be alphanumeric with no spaces.
Example: {fm=1|xm=3}
Currently there is no specific avp defined in this
4.2Additional requirements
The way/the order in which the channels are scanned are implementation-dependent, as well as the way the preferred NAP is selected.
The NAP (operator) selection will possibly rely on the following criteria:
- Preferred operator (if commercial)
- NSP support (especially[ACU23]the ability to support ATC flows and other needed flows, AOC at least)
When an aircraft (MS) lands and scans the AeroMACS band, it has to select a NAP, and then most likely the adequate NSP.
The criteria for NAP selection should be:(in blue possible solutions)
1Select a NAP who is providing Aircraft connectivity
2Select a NAP who is contracted (might not be compulsory for ATC traffic only)
3Select the preferred NAP if several are possible (based on airline preferences)
4Select a NAP who can provide ATC connectivity up to H-NSP
5Select a NAP who can authenticate the aircraft (by relaying the AAA requests to the H-NSP)
By
either by analyzing the Operator Id (that should be encoded in a specific way)
or pre-determine channel values/operator Ids in a local aircraft configuration file
or analyze the NSPIds supported by the NAP and select the NAP depending on the NSP Id.
It is proposed:
- We could define a way to encode the Operator Ids in order to identify ICAO and aircraft-connectivity operators - same proposal for NSP Id – however, it might be difficult to get a range of Ids from IEEE – to be confirmed
- The MS will need any way to have locally
- Allowed operator id values[ACU24][FD25]
- Allowed channels depending on the location
- H-NSP Id and associated realm
- The MS should use the H-NSP realm as <routing realm> in authentication process and the ASN shall use this parameter to route to the proper NSP
These are suggestions for discussion during our next WG-S meeting.
1
[ACU1]Actually, for handling vehicles the airport telco is acting as a H-NSP, not V-NSP without a H-NSP as is the approach here.
[FD2]Agreed if a local vehicle devices flet is managed – we may imagine another solutions but i agree hat this will happen i most cases
However, it ca be considered as the v nsp fo aircraft
[ACU3]This is actually the next scenario (single NSP, multiple NAPs). Suggest to remove it from here
[FD4]Agreed - done
[ACU5]In USA, the ANSP (FAA) could also be owner of the ASN, perhaps operate it too? To be discussed.
[FD6]Yes
[ACU7]Mention the case foreseen in Table 1, where airlines could also at as H-NSP (although I personally see it unlikely due to the contractual obligations required to the H-NSP regarding security).
[ACU8]Should mention that, even if only one H-NSP gives service to the airlines using a particular airport, an additional H-NSP is in any case foreseen for handling vehicles.
[FD9]Yes done at beginning ofsection 1
[ACU10]There are many aspects unclear to me in this option:
-Is this model compatible with the previous one? (i.e. is having multiple NSP with multiple NAP permitted?)
-It is stated that the AAA and data servers are placed locally in the airport. This is inconsistent with the option of “extension to several airports by one service provider”.
-Assuming the NSP is physically located in the airport, is this model only suitable for airport services (handling vehicles and fixed), no aircraft? Or, is the aircraft required to change H-NSP at every airport?
-Are the NAPs all located in the same airport?
[FD11]I must admit that i did noy write this text and i am not sure to agree with it.... for me, we should distinguish if the naps are collocated or not – (same airport)
[ACU12]Question: if a ACSP own the spectrum license to operate as a NAP, and also acts as the NSP, but other NSPs are to be allowed operation in the airport, is this model adequate? Or should we go back to model 1?
[ACU13]Should state that this architecture is only feasible by ACSP entities
[FD14]No they would stay wit one h nsp
[ACU15]As in previous case, does this mean that, if aircraft are serviced, they would need to change H-NSP at every airport?
[ACU16]What are the consequences of doing this regarding the mobile user configuration? Is it necessary to re-enter a new network with a new IP address?
Point out the benefits of this option (lower data latency for ATC/AOC services executed locally).
[ACU17]I would rather say that the airport telco is the H-NSP and there is no V-NSP, than the opposite (there is no roaming or FA for vehicles).
[ACU18]I would rather say that the airport telco is the H-NSP and there is no V-NSP, than the opposite (there is no roaming or FA for vehicles).
[ACU19]Why the airline? The airline is the mobile user. Realm should be the H-NSP contracted (SITA, ARINC, ANSP, etc)
[FD20]Because this is what happens today – the airlines want segregation and might ultimetaly perform the authentication..
[FD21]Yes – can you draft it ? thanks
[ACU22]Should also indicate the network entry process for an airport vehicle (much simpler, no CoA or MIP tunnel)
[ACU23]Unfinished statement
[ACU24]If this local information is available in the MS, operators could be listed in order of preference to solve the NAP selection.
It seems unlikely that the NSPs serviced by a given NAP will change frequently over time. When this happens, the local airport information can be updated in the MS. A way to keep the MS updated needs to be defined, though.
[FD25]Well this might not happen frequently but in any case it will be a burden to update on the aircraft – this is the issue