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
