Femtocells use residential broadband connections for backhaul. In many countries, the broadband link will be the bottleneck in the delivery of voice and data services to mobile handsets in the home.
Therefore it’s important that femtocells make the most efficient use of the bandwidth available on the IP link. In fact, this is much more important than has been widely recognised by the femtocell industry up until now.
Bandwidth required for voice calls
Broadband speeds vary from one country to another, but a “standard” 2 Mbps connection in the UK or USA, for example, delivers uplink bandwidth of around 200-240 kbps. In practice it will often be less than this (e.g. in DSL-connected homes that are located some distance from the local exchange).

ADSL downlink and uplink speeds in the UK
Many operators have stated a requirement for femtocells to support 4 simultaneous voice calls. This level of usage must therefore be possible within the available uplink bandwidth on a standard broadband connection. In practice this could mean significantly less than 200 kbps (not only because some homes will have a slower uplink, but also because the femtocell must share the broadband connection with PCs accessing the internet in the home).

ADSL bandwidth required for multiple voice calls
The IP bandwidth required for multiple voice calls depends on the approach taken to securing the user traffic. The table above compares the bandwidth requirements for multiple simultaneous calls using two different approaches to security: IPsec (assuming a standard Iu interface over the broadband link), and SRTP with multiplexing (muxing). Bandwidth requirements are shown for ADSL links using two widespread encapsulation techniques: PPP over ATM (PPPoA) – commonly used in Europe, and PPP over Ethernet over ATM (PPPoE) – commonly used in North America.
In North America, the Iu / IPsec approach requires more than 250 kbps for the third voice call. By contrast, SRTP with muxing supports 4 calls within only 127 kbps.
IPsec vs. SRTP – how security affects bandwidth
AMR codec samples are small (31 bytes or less), so the overhead from packet headers can be significant. IPsec is not optimised for carrying small packets. Furthermore, IPsec must be wrapped up inside UDP in order to survive Network Address Translation behind firewalls. The necessary headers increase the IPsec packet size to 124 bytes, which results in inefficient use of bandwidth.
By contrast, SRTP is optimised for real-time (latency-sensitive) applications such as voice calls and videoconferencing. Furthermore, by muxing a number of RTP-based voice streams into a single RTP stream, the IP packet overheads can be shared across multiple calls. This makes SRTP very bandwidth efficient.
Use of a standard Iu interface between the femtocell Access Point and the Femto Gateway precludes the possibility of muxing. A modification of the Iu interface that supports SRTP and muxing is therefore desirable because it enables much greater bandwidth efficiency on the IP link.
4 simultaneous calls – doing what it says on the box
It might be argued that more than 2 simultaneous calls on the femtocell will be a rare event, and therefore the likelihood of a bad experience is remote.
For example, assuming an average of 2.5 femtocell users per household, even if the peak hour voice traffic per user is very high (0.1 Erlangs), the probability of 3 or more calls happening at the same time is only 0.2%. So can we ignore the need for bandwidth efficiency?
The main argument against this is that the femtocell must support the advertised features. If it says “4 voice calls” on the box (as required by many operators), then 4 voice calls must be supported on a standard broadband connection. Ignoring the bandwidth requirement because of the low chance of 4 calls is not an option. If the advertised features cannot be supported (and a journalist is sure to check), then the service will quickly get a bad reputation.
Worse still, some households will have insufficient uplink bandwidth even for 2 calls (IPsec requires 170 kbps), so operators will need to restrict the marketing of femtocells only to those subscribers with a fast broadband connection at home. Restricting the market in this way damages the business case for deploying femtocells. It is also quite impractical; especially considering that actual bandwidth delivered by residential broadband services is often a lot less than the maximum speeds advertised, so consumers will not know whether their line meets the minimum standards required for a femtocell. Eligibility tests will add expense and complexity to the sales process, and there will be a high risk of complaints and product returns from customers in the “grey zone” between eligible and non-eligible.
How likely is a bad experience with fewer calls?
But alternatively the femtocell could be advertised as supporting “up to 4 calls depending on broadband speed”. This would set user expectations appropriately and might avoid complaints from customers with slow broadband. In this case, is bandwidth efficiency still an important consideration?
It turns out that bandwidth efficiency is still very important – the main reason being to reduce the probability of a bad experience with only 1 or 2 calls, especially if there is a conflict with PC internet usage in the home. For example, the PC requires uplink bandwidth to upload photos and videos to social networking sites like Facebook and YouTube. Even web browsing requires some uplink bandwidth to acknowledge the downlink packets.
So the probability of a “bad experience” must be defined broadly. On the one hand, phone users might have insufficient uplink bandwidth for voice calls. On the other, PC users might have insufficient uplink capacity for browsing and other internet services if voice calls consume all the uplink capacity.
Probability of 6 or more bad experiences in 18 months
The figure above shows the probability that a North American user will have 6 or more bad experiences within 18 months (which might represent a typical femtocell contract subscription period). Here IPsec does very badly indeed, with 40% chance of more than 6 bad experiences when the average peak hour voice traffic demand is 0.06 Erlangs per user. This number of issues is likely to cause significant churn. By contrast, SRTP performs much better, with a lower than 1.5% chance of 6 bad experiences. (Full details of the analysis can be found in the ip.access femtocell Issue Note, “Why femtocells must be bandwidth efficient”.)
Could things get even worse?
The analysis above may turn out to be quite conservative. Firstly, a poor experience on the femtocell may annoy users more than it does on the macro network because:
- There is an expectation of fixed line quality in the home (especially if FMS is part of the femtocell consumer proposition).
- Immediate call retry is less likely to succeed on a femtocell – the macro network supports more calls so there is a greater chance of another call ending.
Secondly, peak hour usage levels may be at the high end of the scale shown in the figures above. Based on analysis of fixed line usage and Fixed Mobile Substitution, 0.06 Erlangs peak demand per user seems a reasonable starting assumption (see Why femtocells must be bandwidth efficient). However, there are several factors which could increase this:
- Femtocells will appeal to people who want to use their phones a lot.
- Femtocell marketing propositions will encourage high levels of usage (e.g. free calls at home).
- Femtocells will be used in small offices as well as homes; business usage is likely to be higher than residential, and intra-office calls will immediately use up two voice slots on the femtocell.
Thirdly, the analysis assumes an average value for the peak hour voice traffic demand, which may significantly underestimate the probability of a bad experience:
- Some households will contain talkative families, who will need several calls at once far more often than the average.
- There will be periods of much higher than average demand (e.g. Christmas, New Year…), when the probability of more than 2 calls will be much greater than normal.
Finally, the analysis ignores the possibility of mobile data traffic and video calls through the femtocell, which will further reduce the bandwidth available for voice calls and PC internet access.
Conclusion
Bandwidth efficiency is a much more important requirement than has been widely recognised by the femtocell industry up until now. Use of a standard Iu interface with IPsec security over the residential broadband link will cause user experience problems.
A modification to the Iu interface that allows the use of muxing and SRTP for security will lead to a substantial improvement in the end user experience, thereby greatly benefitting the femtocell industry.
Further details: Why femtocells must be bandwidth efficient
Filed under: Femtocell issues | Tagged: bandwidth efficiency, Femtocell, femtocells, IPsec, Iu, muxing, SRTP






Andy – a comprehensive and clearly thought out article. I’ve listed a few technical points below which mitigate some of your arguments, but in the end it will rely on the end-to-end voice performance perceived by the user which determines this aspect of femtocell success.
1. Mobile phones don’t transmit (much) when the user isn’t talking, so there is scope for overbooking on the basis that not all 4 simultaneous calls would be talking at the same time. Not ideal, but reduces the percentage of clashes.
2. The North American market seems very attractive for femtocells – many poor coverage areas in the exburbs but plenty of wired broadband connectivity. However, there’s more Cable broadband than DSL where uplink rates may be less of an issue.
3. I’ve found the uplink rate of my DSL service to be fixed by my package rather than for individual technical performance issues. Even with 2Mbit DSL service, I always had 250k upstream. Although my service is around 4-6Mbit (3 miles from the exchange), uplink is 400k for my standard package and 800kbit for premium service at 10 pounds/month more.
4. The DSL modem (whether or not it incorporates the femtocell itself) can prioritise the VoIP traffic over and above data from connected PCs. This is quite common in office environments, where the PC ethernet cable is connected/relayed through the desktop IP phone before forwarding to the network.
5. ADSL2+ is becoming available with extremely high data rates (20Mbit/s or more). However these are only available within close range of the telephone exchange. Rural consumers, for whom the poor coverage business case is particularly relevant, would typically not benefit from ADSL2+ due to being too far away from the exchange.
6. IPTV takeup may transform the available capacity of DSL networks in the next year or two. This affects both the link from the house to the central office/DSLAM as well as further upstream. Prioritising this traffic to avoid congestion of femtocell voice calls will be important, and perhaps that is where a more efficient scheme will be helpful.
Seems like the IPSec overhead you have in the table assumes a tunnel per voice call. In fact, voice calls can share the same tunnel in Iu deployment models. sharing a common tunnel for all four calls is a better comparison. do you not agree?
AJ – yes, your point is well taken.
My comparison is between a “standard” Iu interface with IPsec and a modified Iu interface which uses multiplexing and SRTP. You can also do multiplexing with IPsec, but the key point is that this mandates a departure from the standard Iu interface.
SRTP is still inherently more bandwidth efficient than IPsec, but the difference is less if multiplexing is used in both cases.
Hope this helps.
Some further clarification:
An IPsec tunnel picks up a whole packet (i.e. a voice sample payload plus an IP/UDP/RTP header) and puts it into the payload of another packet (along with some crypto overheads and another UDP layer to get through NATs).
So whether it’s one IPsec tunnel per call or one IPsec tunnel per femtocell makes no difference to the bandwidth required.
“Muxing” puts several voice samples into the same inner IP packet, thereby reducing the number of packets and greatly reducing the “overheads” as all the voice samples are sharing a single IP/UDP/RTP header.