News: LTE in Sky

It’s called convergence. Two different approaches end-up with the same solution. In the nature it can be a bird and a bat (mammal). The both fly using wings although their ways to the result were quite independent.

In technology we can also use the synergism of the convergence. Simply we can reuse a technology which is already in place instead of creating a new one. A good example is the activity of NASA and Verizon to use the LTE eNodeB towers for air traffic control of drones (UAVs). Amazing – just a few years ago there was no LTE and no Drones.

Yesterday Deutsche Telecom (T-Mobile Germany) along with Inmarsat and Lufthansa announced their plans to create a new LTE network which would enable high-speed Internet for aviation passengers in Europe.

The network is called European Aviation Network (EAN). It will consist of the Inmarsat S-band satellite with multi-beam pan-European coverage and approximately 300 LTE sites. Each of the LTE sites will have a range of more than 80 km (comparing to traditional range of 10 km or less) and will be able to transmit data to the planes’ operating altitude. Moreover they should be flexible enough to deal with the speed of a plane. Lufthansa should start with a flight trial program in 2017.

Update: First trials

One wonders (with the coming IoT),  how far we’re from unpiloted flights now?

Aggregation Proxy and Bootstraping

There were three telco engineers.

One was confused.

Second one was unsure.

And the third one also worked with IMS.

The self-confidence is a key for a trainer. And honestly that’s what I lack with IMS. There are so many things, specifications, flows which I’m not sure about. I can read several different specs about one network functionality, each claiming something slightly different but all of them very vague about some particular feature I’m interested in. That’s why I like the wireshark. The problem is that even the traces can differ deployment to deployment, vendor to vendor. But at least that is something I can touch.

When I started with the RCS I’ve seen various callflows which contained some ‘AP’ or ‘AG’ box. This network function is an http or ws API (REST/SOAP/XCAP/any other) gateway into the IMS network. I was a bit confused, because always it was called by a different name and the function was not always the same. It took me some time to sort it out (at least partially ;)).

We’ve already seen one of those boxes – the Authentication Proxy. This time we will discuss the Aggregation and Cross-Network Proxies. The Authentication proxy is standardized by GSMA as VoLTE network function. In contrast to that the Aggregation Proxy is an RCS network element defined by OMA in XML Document Management specs.

Otherwise they are very similar and in practice they can be implemented within the same physical system as both of them are used to allow users to manipulate data over http without the need to go through the SBC.

 

Aggregation Proxy

 

And indeed, when we take a closer look, we can see (as stated in the specification) that for a 3GPP IMS or 3GPP2 MMD realisation, the XDM-3 and XDM-5 reference points correspond to the Ut reference point. In other words Aggregation and Authentication proxy are supposed to work in the same way from the UE perspective (e.g. we’ll use GAA or Http Digest for authentication). We can reuse the BSF and NAF functionality we have implemented for Authentication proxy. So if we know the Authentication Proxy we already know most of the stuff.

How to read tcpdump – Registration

In telco tracing has always been very important. It helps us to understand the flows, the content and – sure – to find bugs. SS7 used to be much more strict and we didn’t need to go in the detail traces that often. The flow and a few fields was usually enough. With SIP and SDP it is a different story. SIP is a very flexible protocol. That means powerful but also complex and sometimes quite confusing.

Let’s take a look on IMS Registration. I’m sure you remember the idea behind from a previous posts about Registration and 3rd party registration and at least the basic flow:

 

IMS Registration

The registration flow is very important – in practice if something goes wrong, it is most probably registration. Once is a subscriber correctly registered,  the other flows (call, sms, fileshare) usually works fine.

There are many documents describing the message flow and important values. For VoLTE I’d recommend to go through VoLTE Service Description and Implementation Guide or A Definitive Guide to Successful Deployments. Would you have any doubts about a particular header please refer to http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml. Now let’s go through the particular messages.