The project WirelessCabin (wirelesscabin.triagnosys.com) aims at providing
aircraft passengers and crew members with heterogeneous wireless access
solutions for in-flight entertainment, Internet access and mobile/personal
communications.
I.
Services
When wireless access technologies in aircraft cabins are envisaged for
passenger service, the most important standards for future use are considered
to be: GSM, UMTS with UTRAN air
interface, Bluetoothä, and W-LAN IEEE 802.11x. Of course, these
access technologies need to co-exist with each other and wired IP installations,
too. The passenger may use their own personal devices such as UMTS mobile
phones, laptops or Personal Digital Assistants (PDA) or other Personal
Electronic Devices (PED).
For mobile telephony, circuit-switched (CS) or packet-switched (PS)
services are supported. Voice, SMS, MMS, IP data services are expected as
favourite services. For IP services, the typical protocols from business and
home environment are supported, such as TCP, UDP, RTP, uni/multicast. VPNs and
IP mobility of the user equipment is supported as well.
II.
Architecture
The WirelessCabin architecture consists of three segments, the Cabin Segment, the Transport Segment and the Ground
Segment. As depicted in Figure 1, the Cabin Segment consists of a Local Access domain and a Service Integration domain. The Local
Access domain combines the UTRAN/GSM radio access segment, the WLAN access
segment and the Bluetooth access segment. The Service Integration domain hosts
some core network functionalities of the UMTS network and IP protocol functions
for authentication, admission control and accounting, mobility support, Quality
of Service (QoS) support and the interfaces towards the satellite transport
network. The key element of the Service Integration domain is a versatile
router with supporting protocol functions.
The Transport Segment can consist of one or several satellite (or
terrestrial) systems. Circuit or packet-switched bearer services are used for
transport of the WirelessCabin services to a aircom service provider on ground.
Handover between different segments as well as combination of different segment
are supported to increase coverage and capacity.
The ground segment consists of a Service
Provider domain, the Public Network
domain such as the Internet backbone or Public Switched Telephone Networks
(PSTN), including the passengers Home
Network domain for IP and UMTS services.
The Service Provider domain’s key element is another router which is
inter-operating with the cabin service integration domain in client-server
mode. The services are de-integrated and interconnected with terrestrial
networks. Protocol functions in the cabin are served on the provider ground
site.
The architecture is designed to enable the following main goals:
• Airlines can choose different features
depending on aircraft type, e.g., basic communication services for small A/C,
enhanced communication services with onboard content for long range A/C,
wireless and secure crew communications.
• The system is independent of the satellite
transport network; the airlines can choose satellite service operators.
• Several satellite segments can be
supported depending on the flight route.
• The satellite segment can vary upon the
aircraft WirelessCabin capabilities (e.g., required bit rate).
• Aircom service providers can support
several satellite segments.
• The ground segment architecture supports
several roaming principles (aircom provider as roaming provider, terrestrial
network operators as legacy network providers).
• Several charging possibilities and
business chains are supported.
A more detail block diagram of the architecture is given in Figure 2. Here
the functional mapping above explained is still shown but each domain has been
exploded in its main functional entities. It is important to underline that the
architecture as it is represented does not necessary correspond to its physical
implementation but it can be considered a logical architecture that shows the
main functionalities as separate functional blocks. All the architecture is IP
based and all the traffic handling, scheduling and monitoring is performed in a
router.
As for the Local Access Domain it is worth mentioning the UMTS local
access. Figure 2 shows all the UMTS network elements that must be put on board
the aircraft. This configuration that at first glance could seem the most
complicated, actually reveals to be the best approach for convergence purposes
and also for average signalling load over the satellite link. Both CS and PS domains are here shown but for
a pure IP Multimedia architecture the CS domain does not need to be deployed,
which means that the MSC is not necessary anymore as both voice and data are
handled by the PS domain (and therefore by the SGSN and GGSN). The SGSN and MSC
on board the aircraft are a light version of the standard entities; for
instance they do not implement full VLR functionality, as the full profiles of
the users are stored in the Service Provider Domain. Moreover these entities
implement both SIP and RADIUS protocol, acting as server for SIP and client for
RADIUS, which guarantees convergence and therefore having always the same set
of protocols between the Service Integration Domain and the Service Provider
Domain.
The Service Integration Domain interfaces with the Local Access Domain
and the Transport Domain. It is able to handle all the heterogeneous traffic
coming from the Local Access Domain and send it to the satellite as previously
mentioned. The Service Integration Domain has got a proxy AAA server, which is
used for authentication purposes with the Service Provider Domain. If user’s
information is here stored, it is not necessary to request it from the Service
Provider Domain each time it is needed and therefore the satellite link is not
loaded unnecessarily.
Through a DHCP server, the Service Integration Domain is able to assign
private IP addresses to the user independently of the local access envisaged. The
SIP server/MGW allow handling the PSTN satellite connection (when available) so
that the session establishment can take place in the same fashion independently
of the satellite service offered. This means that also in this case the session
establishment takes place through the same set of protocols. Moreover the MGW
can implement a transcoding when necessary. In fact it can happen that the
negotiated end-to-end codec for voice, for instance, is not the best one for
the satellite link and therefore a transcoding could be necessary.
The Service Provider Domain, as before mentioned, is the master in the
communication with the Service Integration Domain and it is able to handle
communication with a number of Service Integration Domains (i.e. aircrafts). It
assigns an IP address to each aircraft so as to route traffic towards the
correct “slave”; moreover it can assign public IP addresses on request.
The Service Provider Domain has got a user’s database, called WirelessCabin
location register where user’s profiles are stored; from a UMTS point of view,
it corresponds to the VLR and it also acts as a centralized unit for temporary
number assignment for incoming calls. The WirelessCabin location register has
got AAA functionalities and together with the proxy AAA server in the Service
Integration Domain, authenticates the users wanting to access the system. A SIP
server/MGW allows interconnection with the PSTN network, while an SS7 gateways
will be used to convert SS7 signalling from 2G/3G home networks into Radius/SIP
messages. This will allow having a standard attachment mechanism, regardless of
the local access envisaged.
The transport network could also provide direct access to PSTN or packed
switched network directly. Here all user traffic is routed via the Service
Integration Domain and the Service Provider Domain. This means that this capability is only used
to provide connectivity between the two domains, and is not used for direct
routing of user traffic towards the public network. This rule is applied to ensure consistent
control signalling mechanisms and accounting of user traffic.
III.
Protocols
The design of signalling protocols for WirelessCabin uses standard IP
protocols such as RADIUS, SIP and RSVP to ensure convergence of different
wireless network technologies. The signalling protocols include messages for
initialization, attachment and session establishment. Essentially, standard
protocols in each local access domain are used. However, several additional
messages have been defined when attachment or registration to the WirelessCabin
Service Provider domain is required for IP address assignment, accounting or
any other purposes. This allows for the definition of a generic attachment
mechanism, regardless of the wireless access network. In addition, signalling
protocols have also been defined for the support of end-to-end QoS, security
and also for inter-satellite system mobility management.
Figure 3 shows a generic attachment procedure for WirelessCabin. In
general, each wireless access network supported in the system will have a
different attachment procedure. However, in all cases, at least two main phases
are performed, namely the local access domain attachment and the service domain
attachment. The local access domain attachment follows the standard procedure
specific to each local access network segment (UMTS, WLAN, Bluetooth). For
UMTS, this is the RRC connection establishment, whereas for W-LAN and Bluetooth,
this is the Association and the Inquiry & Paging procedures, respectively.
In the service domain attachment phase, several other mechanisms are included
such as the authentication/authorisation of users using RADIUS and the
assignment of IP addresses to the UEs in the aircraft via DHCP.
IV.
QoS Support
Generally, two different QoS service classes are identified in
WirelessCabin: real time and non-real time services, based on applications
performance related to QoS characteristics, such as delay and delay variation
(jitter). The main real-time services are time critical, whereas non-real time
services do not have a time factor, and are named as elastic. Furthermore,
real-time services can be divided into tolerant and intolerant services
according to whether they are tolerant or intolerant to the jitter. Tolerant
services, such as various audio and video streaming services, will not be
affected by the jitter. Intolerant services, such as VoIP and multimedia
conferencing services are services which cannot be recoverable if they are
distorted because of the delay and delay variation.
Further classifications are also possible based on the classification
identified by the 3GPP specifications of the UMTS. WirelessCabin distinguishes
four QoS classes according to those defined in UMTS, which also identifies
services classes based on real-time and non-real time services:
·
WirelessCabin
first class (Conversational class: real time/delay intolerant):
·
WirelessCabin
second class (Streaming class: real time/delay tolerant)
·
WirelessCabin
third class (Interactive class: non real time/interactive)
·
WirelessCabin
Fourth class (Background class).
The four classes distinguishing factors are service delay sensitivity
and interactivity. Conversational and streaming classes are mainly intended to
be used to carry real-time traffic flows, while interactive and background
classes provide better error rate. The most delay sensitive services are
classed in the Conversational class. This includes application such as video
telephony, while the least sensitive is the Background class, such as e-mail.
Conversational and Streaming classes are intended for carrying real-time
traffic flows. Interactive and Background classes are intended to carry
non-real-time traffic flows.
QoS has to be provided end-to-end,
which means that every entity or device of the system should support QoS. Like
the strength of a chain is limited by the strength of its weakest link, the
end-to-end QoS is limited by the network’s element that cannot provide sufficient
QoS supports. It means especially that every underlying network should provide
QoS: this is already realized for instance in UMTS, with the separation of
Circuit Switched applications and Packet Switched applications as well as in
the IP network. However, the W-LAN 802.11 standard does not yet support QoS,
although it is envisaged that QoS support will be included in the next version
of the standard (802.11e). The terrestrial networks provide the same QoS
mechanisms, and the satellite systems also support it while enabling several
transmission modes, each one of them corresponding to a special QoS
requirement. An example the end-to-end QoS concept is represented in Figure 4,
with reference to the CS UMTS domain.