What’s different about a presenceCell?
The cell itself is optimised to gather data. What we are doing is specifically optimising the device to gather data that can be used for analytics, m-commerce, those kinds of apps. It’s not about providing capacity or coverage. It’s purely set up to gather data. Now, we could combine the functionality into a single piece of hardware but for the time being we’re saying, “That’s a presence cell that does just that.”
So how do you optimise something to gather data – what does that mean?
You allow it to communicate with a handset but just to take the information it needs; to gather your IMSI data then time stamp it and send it back to a central server so you’ve got a record of what was there, when it was there, where it was – job done.
So the device has to attach to the cell in the same way as to a serving cell…
No, there’s no attachment at all. I’m not going to go into too much detail because that’s slightly confidential. There is no attachment to the small cell or macro network, from handset to the device [presenceCell]. The presenceCell recognises the handset, it is an active communication but there’s no attachment, registration or record that it took place.
Simply put, the phone will ask to register, the cell will say, “No you can’t but thanks for talking, goodbye.” But in the meantime it has recorded that information.
Do you need to have an operating license to put one down?
Given the device is active and does operate in licensed spectrum it does need to be used in conjunction with an operator, so the target for the product is an operator.
Does it cost the same to manufacture as a “normal” cell
It’s of the same sort of order of cost. From an operational point of view it’s very simple. It’s not integrated back into the core network, it literally just requires a pipe to signal the data back. We’re aiming for a jiffy bag install – you mail the cells to a site and put them on the wall.
What are the advantages of the presenceCell approach over other methods of accessing presence data to feed the Big Data engines?
There are a number of carriers who are using macro and WiFi technology to explore user analytics, but you have a granularity issue. The cells in those methods are a certain size, but we can control the cell size to give a much more accurate map of where people are – we could say where you are exactly to a few metres. Carriers that have trialled it have recognised that it solves a number of problems that have so far been unsolvable, and we’ve seen significant interest from carriers who are already in this space.
Another issue is, if you are to gather this amount of data and you push all of that back through your MSC you create a signalling and traffic load that is quite disruptive and unsettling for the core network. We feed that back without touching the core network. We are unique in having that capability. The last thing operators want to be doing is loading an expensive MSC with this data. To get the data direct to a simple blade server is very valuable.
And if you compare it to Beacon type or Bluetooth tech, that’s opt-in technology. Ours is universal, it’s not something you opt into. It’s something you have to say no I don’t want to do this.
How are operators making use of this data?
A number of operators are forming relationships with big data customers and using the data they are gathering in an anonymised safe manner for big data purposes. We provide the level of granularity that these guys need. It’s opening up new revenue streams and sets of income beyond the traditional play, and is a substantial line of income. This is not a trivial revenue stream.
More from ip.access on the presenceCell. And here’s what operators and enterprises make of it.
