Air New Zealand launched its in-flight Wi-Fi trial in October on three of its fleet of seven Boeing 777-300ER aircraft. The trial has been available to selected customers flying on these aircraft, and flying back from Los Angeles earlier this week I finally had an opportunity to use the service.
Air NZ chose to partner with Inmarsat and use their new GX for Aviation offering, which relies on the Inmarsat Global Xpress Ka band satellite network. This is integrated with the Panasonic in-flight entertainment (IFE) platform that Air New Zealand use on-board their Airbus A320, Boeing 777 and Boeing 787 fleet. Air New Zealand have chosen Aruba for the Wi-Fi access points in the aircraft.
In the commercial passenger space the GX for Aviation product is currently only being used by Air New Zealand and Singapore Airlines. Singapore Airlines have retrofitted it to a small number of aircraft in recent months.
Air New Zealand had originally intended to trial Wi-Fi on its new Airbus A321neo aircraft that were due to arrive in mid 2017, however when the delivery of these aircraft was delayed until 2018 the Boeing 777-300ER became the test aircraft. Air New Zealand have indicated the Wi-Fi roll out will extend to the remainder of its Boeing 777-300ER, Boeing 777-200ER and Boeing 787-9 Dreamliner aircraft into 2018 and 2019.
The launch of in-flight Wi-Fi on domestic and short haul A320 aircraft has also been indicated, but there is no public time frame for a roll out at this stage.
The Wi-Fi network is currently available on flights flown by three aircraft (ZK-OKP, ZK-OKQ and ZK-OKS). Selected customers are given a card with the SSID of the (currently) hidden Wi-Fi network and password. Once connected you'll see a captive portal appear for registration.
Once you're registered you'll be presented with some friendly tips and lastly a page for feedback. The feedback form requests comments on the end user experience and also asked some questions around pricing for the product.
Being a network engineer, my first step was to work out where the data was being downlinked from the satellite to a ground station. It seems that all traffic is currently being downlinked in Europe, meaning that all Internet traffic firstly travels from the plane to a satellite and then down to the ground in Europe before it egresses to the Internet.
Up next was the mandatory speed test. As I had been in Los Angeles the speedtest.net app automatically chose a server in Los Angeles thinking it was the best location. Round trip Latency of the actual satellite connection is around 800ms, the remainder is the round trip latency between Europe and Los Angeles.
I conducted a number of tests both on my phone and on a laptop to a number of different destinations around the world. I was unable to get any more than around 3.5Mbps in any test I conducted.
A number of tests showed significantly slower speeds, with tests to New Zealand speedtest.net servers struggling to get much beyond 1.5Mbps - 2Mbps downstream, and a number of tests to New Zealand servers showing very poor upload rates of around 0.5Mbps.
I know speedtest.net isn't necessarily the best way to measure speed and I'm aware of the limitations of the product, so for some further testing I used Tamosoft Throughput and Mikrotik's btest applications to test speeds to Mikrotik routers in both New Zealand the the USA and a Tamosoft server located in New Zealand. I saw results that pretty much mirrored those of the speedtest.net application.
Testing to New Zealand saw very poor upload TCP performance, which I'm picking is a result of the ~1150ms latency. Upload TCP performance to the USA was significantly better. UDP performance to both New Zealand and the USA delivered speeds of around 1.5Mbps - 2.5Mbps in both directions.
General web browsing worked fine however it became very apparently when looking at content served from NZ that pages with a lot of content that page loads were noticeably sluggish. With all traffic having to travel from the plane to Europe then to New Zealand, back to Europe and then to the plane the latency is the real killer here.
If the site or service you're connecting to is served from a Content Delivery Network (CDN) the location of the site itself becomes largely irrelevant as it will typically be served from the closest global CDN node. However if the site or service you're connecting to isn't hosted on a CDN then location of the server becomes very important as this is where it will be served from.
I conducted some tests of page load times for some sites hosted on a CDN and also some hosted in NZ which were not on a CDN. Unfortunately it appears I forgot to save these so don't have a record of these, but the results of the extra ~350ms of RTT latency between Europe and New Zealand became very apparent on top of the existing 800ms latency from the satellite connection.
Speed however isn't the end-all when it comes to testing the quality of any broadband network. A 100Mbps fibre connection can deliver a worse end user experience than a much slower connection if parts of the network are poorly configured. Ultimately Quality of Experience (QoE) becomes the measurement tool of choice - and the determining factor being whether end user consider their experience to be optimal.
Up next I conducted some VPN testing and found it was not possible to connect to a PPTP VPN over the Wi-Fi. I don't know whether this is intentional (to stop users bypassing DPI or traffic restrictions) or simply a result of the network architecture. Restricting VPN access means customers will not be able to protect their browsing with a layer of security on an open WiFi network once the product goes live, and also means any corporate users still using a PPTP VPN to connect to a corporate network will be unable to do so. OpenVPN connections established OK, however I forgot to test an IPsec VPN.
Next was a network scan. Full Wi-Fi client isolation was not in place on the network allowing me to see other clients which is poor practice from a security viewpoint. The Panasonic API was also exposed on the Panasonic box.
Next up I tested a number of messaging services. iMessage, Facebook Chat, WhatsApp and Skype all worked OK. I was unable to initiate a Facebook Chat voice call, but was able to initiate a Skype call. While voice quality was OK as Skype uses an adaptive bitrate codec, the 1150ms (that's just over 1 second) latency of the connection to a user in New Zealand made it virtually unusable. I tried a few streaming services including YouTube and they delivered a pretty poor experience with lots of buffering even on 480p content.
I encountered a few issues uploading images to Twitter using the Gravity app on my phone, however I'm not sure whether this was caused by the app itself or a combination of the poor upload performance and latency.
The captive portal had session timeouts set low meaning that I had to authenticate myself several times during the flight after a period of not using the Internet. There are no excuses for such poor configuration that makes the service more difficult to use than need be - once a user is authenticated they should stay authenticated for the duration of the flight.
In summary it was Internet, but it was not the great experience I was expecting. I've used Wi-Fi on a number of airlines and experienced both poor and great Wi-Fi experiences. Air New Zealand's offering right now sits somewhere in the middle.
Air New Zealand's delay in offering in-flight Wi-Fi was to ensure that they could launch with a next generation solution that could meet the needs and bandwidth requirements of users. After looking at a number of options they chose the Inmarsat GX offering. With Ka band offerings such as those used by Qantas and Virgin Australia delivering real world speeds of up to 15-20Mbps to end users and new 2Ku offerings being deployed by a number of airlines globally delivering speeds even faster again, it really does have to make you wonder if Air New Zealand have backed the right solution.
Anybody who works in the IT space knows that solutions that may sound great in a Powerpoint pitch by a salesperson doesn't necessarily always result an amazing real wold solution. Considering I was on a plane with only a handful of other users trialling the service, it's safe to say I expected a product that delivered a far better end user experience than the one I received. It's going to be very interesting to see what development occurs on the product before it goes live to paying customers, and more importantly when there are significantly more users online wanting to use the service.
Update: Since this review was published the WiFi trial was suspended while the client isolation issue was resolved. This issue has now been fixed.
