System Architecture for 3G Wireless Networks in Aircraft


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.

Textfeld:  

Figure 1: The WirelessCabin functional architecture

     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.

 

Textfeld:  
Figure 2: The WirelessCabin architectural block diagram

    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.

Textfeld:  

Figure 3: Message Sequence Chart for Attachment Procedure

    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.

Textfeld:  

Figure 4: End-to-end QoS in WirelessCabin

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.