Sonus and the Femtocell backhaul integration with core.

There are as many companies active on the femtocell backhaul integration with IP core as there are Femto cell manufacturers, with Kineto, Sonus and Tatara systems topping the list.

Sonus has recently announced partnerships with three femtocell manufacturers: ip.access, 3way and RadioFrame.

My worry is that some companies in the IP core space are re-inventing the wheel so to speak which threatens the main selling story for femtocells: the low introduction cost and the potential savings to operators. I'm no core expert, but I would guess that the existing framework(s) are sufficient to enable Femtocell integration with core networks without any major investment or development effort.

Femto cell Architecture

The business case for indoor femto cells has gained increasing traction in the last few weeks, and lots of news comments about various femto cell development companies. For example, check here, here and here.

Although the femto cell concept is quickly gaining grounds towards complete and operational products, there is still some misunderstanding on how the overall network architecture will look like. I'll try to address this issue in this post.

A femto cell router is a small device, the size of any Wi-Fi router, which is in effect a miniature base station. The radio is a standard based radio such as UMTS/HSPA which the operator will likely require a license to operate on. The router connects to a DSL line. The idea is to enable the subscriber to make and receive mobile calls indoors, with low signal levels which has a number of benefits to the operator:
- Hopefully accelerate fixed line substitution.
- Reduce the cost of building a full macro layer network.
- Lock subscriber in to the operator and reduce the likelihood of churn.
- Provide a viable medium for content distribution (the ugly walled garden paradigm)

It is not my intention here to argue for or against these benefits. I will dedicate a full post on the business case for the femto cell and the potential cons sometime soon. So let us stay on the technology side and try to investigate how a UMTS based femto cell routers will be integrated with the operator's core network.

Basically, there are a number of ways, the first of which is the conventional hierarchy using an RNC . Just like any node-b is connected back to an RNC which is then in turn is connected to the core network, the femtocell routers can be treated like individual node-bs and connect to RNCs. This may appeal to big manufacturers who already have substantial deployments and many RNC on the ground. The downside to this approach is the limited chances of inter-operable devices if the operators chooses to diversify their suppliers. Although the Iub interface (base station to RNC) is standardised, the reality is most implementations are proprietary. Typically operators don't like to put all their eggs in one basket and would prefer to get solutions from various suppliers. The other downside of this approach is that most available RNC solutions are geared towards Macro/Micro type of deployments. In other words they are built in order to support relatively small number of cells with a huge number of subscribers in each cell. They don't scale very well to support Femto cell deployments with almost as many cells as there are subscribers, and a handful of subscribers per cell.

An alternative approach is to use UMA (or now called GAN). UMA was originally conceived to support dual mode cellular/WiFi-over-Internet type of connectivity. When the mobile is detected indoors within the range of pre-determined WiFi coverage, a UMA concentrator does the core network negotiation on behalf of the mobile, e.g. registering, and updating location ... etc. It is thought that a similar procedure can be used for femto cells. When the mobile is detected within the coverage of a femto cell, UMA kind of hand shaking takes place to ensure that: 1. the mobile is allowed to access the network at this particular femto cell, 2. the traffic between the mobile and the core network is forwarded accordingly. Using this method a UMA concentrator is required, so in a way, the solution is still hierarchical and it is certainly one of the criticisms of this method is that it is not a fully flat architecture. Kineto is one of the companies promoting this approach.

Yet another alternative approach is enabling femto cell connectivity through an IMS service. In this approach, the femto cell router talks SIP over the internet back to an IMS service which acts as a bridge between the femto layer and the rest of the network. Although this is considered the "flattest" approach, it is yet to understand how it will work in practice, the delay in working fully featured IMS platforms is one of the concerns of femto cell development companies.

Incidentally, my current clients are hedging their bets by supporting more than one approach and have developed partnerships with various companies in their respective fields to make the Femto architecture as flexible as possible.

VoIP Episode 5: VoIP over UMTS mouth-to-ear delay

I have received some queries about the delay encountered by VoIP calls. Thanks for the interaction and questions, keep them coming.

In this post I will summarise the various reasons that cause delay of VoIP speech over a UMTS network, or over any network for that matter.
I should mention here that I am not trying to show that VoIP over UMTS is any better or worse than conventional UMTS (I will only do that for a high consultancy fee! ;-) ).

Let us first "dissect" a VoIP call:
Before you start a VoIP call (and during the call) signalling messages are exchanged between the two VoIP terminals and possibly with some other network elements. These are carried using the Session Initiation Protocol (SIP). When you talk into your handset speaker, your analogue voice signal is "encoded" as a string of bits. A number of bits are then packed together in one packet and all the necessary headers are added to it. These packets are then transmitted over the network. They propagate through one or more packet switched networks before they reach their destination. At the destination, the received packets are then reordered and a decoder transforms the digital bits to an audible audio signal.

The sources of delay are numerous:

• First, there is the coding delay, which is the time spent on transforming your speech into a digital stream of bits. This can be minimised by powerful DSP/electronics.
• Then there is the time it takes to compile a packet and add headers to it (packetisation delay). For example, if a packet contains X voice samples, then it has experienced a delay from the instant of the first sample to the instant the packet was complete and ready for transmission. Obviously the bigger the packets are, the longer is the packetisation delay.
• There is also the propagation delay. This is the time the packet takes to traverse the various networks before it reaches its destination. This could be the propagation time over the air interface, or over the various packet core elements. This is essentially determined by the speed of the different physical mediums over which VoIP packets are transmitted: wires, optical cables, radio ...etc
• In addition to this, there is the summation of queuing delays encountered by the packet at each node in the network(s). For example, we have seen in a previous post that a VoIP packet may have to queue for a HSDPA radio resource, or the packet may have to queue at some of the routers and switches before it reaches its destination. The various routers and switches along the route of the packet can be loaded differently, so some packets may be delayed more than others.
• When the packets arrive at the destination, they may not arrive in the right order, because they may traverse different routes before arriving at the destination and because some of them are delayed more than others. Therefore, the receiver has to buffer the packets in order to wait for the slower ones and reorder the packets before submitting them to the decoder. This is called "De-jittering". The de-jittering introduces another delay before the packets are decoded into an audible signal again.
• There is also the delay associated with call signalling. You can not start talking until it rings at the other side and the called party answers. Because of the large SIP messages this delay could also be long. The same issues arises when the call ends, which does not really affect the user perceptions as much as it keeps some network resources tied up for a while.

I hope this answered your questions. I will talk about how some of the advanced 3GPP features will address some of the delay issues in a coming post, so stay tuned!.

© Copyright belongs to the author. Do not cite or quote without the express permission of the author