Home' RTCA Documents for Review : DO-262D Contents Appendix E
© RTCA, 2018
Mobility and Handoff
Handover between all beams within a satellite is supported within the network.
Telephone calls and data connections remain connected.
Handover between satellites is not supported by the network and hence is
implemented by the AES. During satellite handover there is a loss of data and voice
communication between the air and ground. This outage is typically shorter than 1
minute. Data connections are automatically reestablished by the AES. A voice call
should be re-established manually. According to SVGM this should be done by the
party that originally established the call.
Priority, Precedence and Preemption
SBB uses the 3G principles of Quality of Service (QoS) to provide priority and
preemption capability for packet-switched data. QoS is the overall performance of a
network, particularly the performance seen by the users of the network. To
quantitatively measure quality of service, several related aspects of the network
service are often considered, such as error rates, bit rate, throughput, transmission
delay, availability, jitter, etc. – in 3G networks these are called attributes.
For network congestion scenarios on the PS domain, the use of the
Allocation/Retention Priority (ARP) QoS parameter is required for pre-emption of lower
priority users. The ARP level is not negotiated by the mobile terminal, but forms part
of the provisioning of a SB-Safety terminal. Access to the highest priority level is
authorized only for aeronautical mobile terminals supporting cockpit communications
and maritime mobile terminals with distress capabilities – this priority level is not
accessible to users via normal mobile terminal interfaces for commercial traffic.
In the CS domain the enhanced Multi-Level Precedence and Pre-emption (eMLPP)
attribute is used to indicate priority. Admission control and bearer control use eMLPP
to prioritize and if necessary preempt lower priority (or non-priority) users, thus
ensuring that an SBB AES achieves the appropriate performance even in congestion
situations. VoIP calls make use of a priority PDP context.
For the standard PS voice channel, the AES creates PDP contexts to the Inmarsat
safety VoIP APN, which is assigned the appropriate priority level. For enhanced PS
voice service the AES creates PDP contexts to the safety APN shared with the safety
data services. These contexts are also assigned appropriate priority level. In both
cases a PS call to or from a priority AES may therefore preempt calls to or from non-
priority AESs or other BGAN terminals.
In addition when an SBB priority AES requests registration to the Radio Access
Network, the AES is identified as a priority AES and is accepted on to the network with
priority. This is particularly relevant during “registration storms” after, for example,
ground station site switches.
Redundancy Including Fallback to Classic Aero
The AES and the SBB network are designed to allow an AES to automatically and
seamlessly take advantage of additional satellites and ground stations if and when
they become available in the network.
An AES design may offer the capability for two AESs to be installed together on one
aircraft to form a 1+1 hot standby system to improve redundancy.
An AES may be designed to offer automatic reversion to the Classic Aero service for
ACD voice and ACARS services. Reversion for ATN/OSI, ATN/IPS and IP services is
not possible. These AESs and the SBB network are designed for tight interoperability
with the Classic Aero service operating on the I3 and I4 satellites, and an AES with
Classic reversion capability may switch between the three networks. One possible
mode of operation is where services are provided over SBB by default, with the AES
automatically reverting to Classic Aero mode over I4 or I3 when the SBB service or an
I4 satellite is unavailable. Aspects of the fallback mechanism are specified in the SBB
Links Archive Navigation Previous Page Next Page