Small-cells and Satellite

Hi ,

Both of the activities you mention are important for me – the first in the context of the Small Cell Forum and the second in my role developing cell backhaul over satellite.  I am certainly able to provide input to #1 and have already done quite a bit of work on #2, as well as working with a number of partner companies on investigating solutions.

Josep – you need to help me with a bit of nomenclature – “STREP instruments or For-the-benefit-of-SME projects” – needs some explanation please?

Looking in a bit more detail at #2 (my area of specialty)

2.1   Jointly optimizing backhaul resource allocation…  At the present time our satellite system has no signaling interface to any end system for flow control.  We use dynamic bandwidth allocation – the system reviews queue lengths within the QoS system 8 times per second to determine which queues need more or less bandwidth (timeslots) to be allocated.  Allocation is performed locally under most circumstances (without waiting for a round trip to the hub) so is rapid.  This is one of the main reasons why our platform has been successful in the cellular market – base stations do not like to wait while bandwidth ramps up for a new voice or data call.  

The key advantage of this approach is that the lack of any coupling between the satellite remote and base station (or RNC and hub) is that the approach is vendor agnostic – which is a strong part of our culture – we work with any and all vendors.  Some work better than others, but we don’t include code specific to one vendor in our system.  Of course this wouldn’t exclude an architected and standardized interface being developed if it was really necessary.

2.2   Selecting GEO or MEO…  Also interesting as an addition is the ability to select between terrestrial and satellite backhaul under varying conditions.  This is being investigated for a number of scenarios:  back-up via satellite in case of terrestrial link failure (for example China Mobile uses satellite to back-up 1200 critical sites in case of fiber cuts during earthquakes), separation of data traffic on to satellite leaving the voice traffic on terrestrial links after a 2G to 3G upgrade to avoid the extra latency intrinsic in satellite from impacting voice quality, overflow of certain classes of data traffic on to satellite – e.g. streaming video, transmission of multicast video traffic for IPTV service over 3G or 4G.

2.3   Compressing and aggregating traffic from several rural sites…  In general the more traffic that can be aggregated the better thy efficiency achieved when packet header coalescence is used.  Cacheing should also be considered – and the question of where to do it is interesting.  I note that the SCF if considering standardizing cacheing features in small cells and even providing an API.  This also links to the local switching point as the larger the community in general the higher the percentage of local calls.  So being able to locally switch calls across a cluster of sites is more beneficial than local switching on a cell supporting a radius of 200m and 8 voice calls (easier to just shout to your neighbor).

2.4   Shaping traffic through proxy…  I’d need some guidance on what this means and how the benefit is achieved?

2.5   Local Switching…   See 2.3.  The only thing to be wary of is the requirement to make Lawful Intercept (LI) work when local switching is enabled.  I’m aware of some implementations that do support LI and some that don’t – deploying those that don’t can be problematic with regulators.

Dear all,

Thanks for sharing your ideas before the meeting, let me express what we had in mind at UPC. Our targets are

1. Providing 3G-4G economically feasible coverage to rural scenarios
- Identifying several rural representative scenarios
- Drawing usage plans from market constraints
- Defining viable business models over a period of 5 years
these will be reinforced by a more efficient usage of resources driven by technological improvements...

2. Devising more efficient ways of using sat backhaul and smallcells-based access network by:
- Jointly optimising backhaul-access resource allocation, by acting on resource allocation/admision control at the access, the bandwidth and A-TDMA options at the sat link.
- Selecting GEO or MEO backhaul sat dynamically according to the periodic variability of traffic, as an additional degree of freedom and as a means of giving answer to high traffic situations and for enhanced resilience.
- Compressing and aggregating traffic from several rural sites.
- Shaping data traffic through proxy.
- Consider local switching for local calls.

All comments are welcome, of course, let us progress as much as we can before tomorrow's discussion.

Now, regarding the H2020 programme, we can think of either STREP instruments or For-the-benefit-of-SME projects. The requirements, scope and funding are quite different: while the first would be more suitable to prove ground-breaking ideas (also setting up a platform), the second is more oriented to develop highly innovative products.

Best regards



El 04/03/2014 15:48,  ha escrit:

Thanks 

Can I continue the discussion with a bit of clarity on nomenclature?  You referred to LEO & GEO… 

For the satellite world LEO satellites are only really relevant for direct user communications – such as Iridium – with direct access from a handset to a satellite based switching system.  I think these are not relevant to our discussions.  They support certain niche applications (military, disaster recovery) but aren’t economic for normal rural usage as you need 10s to 100s of satellites to provide coverage.

The main world of satellites are the GEO systems and these are sub-divided both in terms of bands used (C, X, Ku, Ka etc.) and also in terms of their coverage ranging from ‘hemi beams’ that cover an entire hemisphere of the earth so that three such satellites can cover the entire surface of the earth (except for polar regions), through more concentrated beams that cover a continent or part thereof through to the latest High Throughput Satellites that support many tens of beams each a few hundred kilometers across.  In the business we really just talk of older ‘Broadbeam’ satellites and newer HTS satellites.  

There is a middle ground using MEO satellites and here there is really just one firm that is trying this – O3b.  They plan to operate 8 MEO satellites to provide coverage to 45 degrees north and south of the equator.  The beams will be high powered and will have lower latency than GEO satellites (due to their proximity to the earth) but they will suffer a key disadvantage – they need at minimum two tracking antennas at each site since the satellites do not appear stationary above the equator like a GEO satellite does.  They also need a complex switch that will manage the handover of IP traffic from the setting satellite to the rising satellite.  The cost and complexity of these systems will likely make these links only economic for very large link sizes (hundreds of Megabits) so might be useful for backhauling the traffic from a large isolated town but not from a single site – yet alone a small cell.

So if we consider GEO systems as the main viable mechanism for remote rural sites there is only one key parameter to analyze – the operational cost in terms of cost per Mbit/s per month.  This is in turn dependent on two factors – the efficiency with which a satellite system can transport Mbit/s within the MHz of bandwidth leased from the satellite operator and price per MHz that the satellite operator charges.  The latter is falling due to the development of HTS systems bring much more capacity to market than traditional Broadbeam satellites have been able to deliver.

So – with these constraints when I look at the various 3G systems in the market you essentially have a choice –

1.       Macro cells offering large ranges, needing a lot of power etc., expensive and moderately efficient in terms of backhaul efficiency – suitable for wide geographic coverage

2.       Small cells – low cost and low power requirements, short range (1-2km max),  suitable for coverage of concentrated sites such as small villages, but backhaul efficiency is poor (twice as much bandwidth per voice call as a macro cell)

3.       Optimized small cells – medium price (high in terms of capacity/cost) and suitable for villages etc. and with excellent efficiency – voice four times more efficient than macro cells, data compression, cacheing etc…

Thus the choice of technology is not at all evident.  While small cells are much lower in capital cost than macro cells, this can be rapidly offset by the operational costs due to their relative inefficiency in using backhaul resources.

So the key points for me (in terms both of my Small Cell Forum Rural SIG chairman function, and my iDirect function) are:

1.       To understand the economics of these systems, not just statically but also in terms of the expected market dynamics over the next 5 years.

2.       Identify areas where small cell vendors and/or satellite equipment vendors can modify their systems to actually make rural coverage economic in both capex and opex terms.

3.       Demonstrate to the market that these systems exist and are technically and economically viable.

Sorry that was a bit long winded – I keep meaning to write another book!

Best regards

Hi ,

Following a brief exchange with Richard this morning, I thought I’d share my understanding of the scope of the proposal that we’re discussing on Thursday.  I realise I’m jumping the gun a bit, so I offer this purely for discussion and to help my understanding…

My take on it is that it’s about IP generation related to the intelligence, architectures and economics to steer certain traffic over LEOs for speed and capacity, with other traffic over GEOs for cost, and other satellite options I’m unaware of.  The funding is to exploring the economics of such solutions both in kit/capex and algorithm/opex terms.  There might then be demo phase where we might prototype some stuff.  I didn’t think the point of the exercise is to develop finished product as such, so much as near-term exploitable IP.  In terms of demarcation between ip.access and iDirect, I think there’s a reasonably clean line between access and backhaul, but if we identify a benefit to coupling RRM on the access side to the resource management/satellite+bearer+QoS selection on the backhaul side, then so much the better.  That’s one of the points of these projects, to fund a bit of thinking time to allow these kinds of ideas to develop.

As I say, this is simply some text to stimulate argument and help converge on a real proposal – more than happy that it gets modified, extended, torn up and started again!

Looking forward to the call on Thursday,

Best

N