One of the suggestions included in a recent press announcement caught my eye. It made the connection between caching website content locally on femtocells and the idea that users may want the same content in the same place. It’s an interesting concept and worth considering further.
What announcement was that then?
Ubiquisys have made a couple of recent announcements where they’ve linked up with big names to build more capability for the future. Texas Instruments will supply their chipsets suitable for “macro sized” dual 3G/4G basestations while Intel offer their chipsets for the centralised core network elements that will run “in the cloud”. You can’t fault Ubi for a lack of pioneering innovation here. We’ll dig into this one more fully in a separate article.
The concept of local caching in femtocells
Within what was a quite a long list of new ideas, one that particularly struck me as quite unusual was the idea to store (cache) data commonly accessed within the femtocells themselves. This is quite close to my heart because I’ve been looking at some of the technical aspects of improving ThinkFemtocell.com performance – one option being to serve images more locally to visitors through what’s called a CDN – Content Delivery Network. This holds a copy of specified image files at major internet hubs, allowing them to be accessed more quickly and easily than from the central server.
In many cases, and especially for popular websites, you’ll almost certainly be viewing internet pages and images held in caches in a CDN or more locally at your ISP, in your corporate office or by your mobile phone company.
Broadly speaking, the fewer, smaller and more directly accessible the files to serve a webpage are, the faster and more responsive it will be.
Would this work differently for femtocells?
Some web content is very location specific. A good example is Google maps, where map pages for the local area are most likely to be downloaded from local femtocells. Local information about entertainment venues, office hours, local businesses etc. are commonly accessed when on the move and in specific local areas.
How would this work in practice?
Internet data is normally “tunnelled” through the network, packaged up in various packet protocols that are unwrapped only at the edge of the network – typically the GGSN (Gateway GPRS Serving Node). This makes it more secure and also handles transmission errors, packet loss and other technical problems.
In order to cache the data, the femtocell would either have to include all of the core network functionality (including the GGSN), or (more likely) cleverly disassemble the raw internet data feed and insert the cache function transparently. I suspect the second option is most likely, because that could be done without an external change to the network or standard interfaces.
A much faster end user experience – the webpages most frequently accessed would tend to be served more quickly. It’s not just because some files are sent quickly from the local cache, but because this also frees up transmission capacity for the remaining webpage (such as the dynamic bits that have to be resent every time).
This reduced wireline transmission load between the femtocell and the core network would also free up capacity for other users.
There’s no need for the operator to predict (or know) which files or what content is being cached. This would occur naturally and automatically. Cached files are marked with a lifetime, so the system will automatically refresh older files which may have changed. As the cache fills up, those which are not reused are replaced by newer ones that are.
It shouldn't have some of the lawful intercept (i.e. phone tapping) concerns associated with local breakout techniques that completely bypass the operators network. All of the traffic will have passed through the core network at some stage, so where lawful interception has to be switched on, it won't miss any of the traffic and the customer being intercepted won't notice any difference.
For those operators who continue to charge for data usage through femtocells as part of the customers standard tariff package, cached data would not be counted. But perhaps that could be positioned as a benefit to the end user – at least there would be some small tariff benefit for them.
It wouldn’t work for encrypted data traffic, such as SSL traffic for HTTPS websites (e.g. your bank), email or corporate VPNs. But it would work for many popular content sites and applications such as Google Maps.
This seems like quite a good idea to me, but further investigation would be needed to determine how much data is likely to be cached and the likely benefits. The cost of including this feature in a femtocell may become quite low – it’s a one-off software development cost with minimal additional memory required in hardware.
It won't be top priority on every femtocell vendor's development roadmap perhaps, but might start to appear as a differentiator for more mature products.
One final thought is whether this feature need to be communicated to the customer? Probably not, perhaps they’ll just think their smartphone works really well with a femtocell…