Open Stack

There are two aspects to this, first being the split architecture of the
functionality between the (Remote)Radio Heads, Distributed Units and
Centralized units for RAN, and second aspects is the CP/DP separation.
In addition, core location (and associated splits) as well as splicing
affect location of functions, and can be service specific - i.e.
location of components for URULL service can be different than location
for same components for eMBB service.

RAN functions themselves have hard real-time requirements constraining
the latencies (e.g. 100us OWD target for L1 stuff in CPRI/eCPRI and
other low level split specs), which limits distance from radio to ~20km.
Since goal of some new services / edge deployments is latency
minimization (including the 1ms target for whole RAN, including both
transmission and processing), that further limits on what can be placed
where.

Pasi


On 01/10/2018 07:10 PM, Ajay Simha wrote:
> In addition to cell sites and V/CRAN aggregation Control and Data Plane seperation efforts in 5G may result in keeping control plane elements anchored at a central or regional core and only have data plane SDN switches or something light on the edge. 
>
> Ajay
>
>> On Jan 9, 2018, at 1:48 PM, Pasi Vaananen <pvaanane at redhat.com> wrote:
>>
>> We should probably focus more on defining the connectivity
>> characteristics between the associated entities between the edge
>> entities to make progress here. We could start discussion of the network
>> connectivity at high level as "black box" representation of the network
>> focusing on the latency, bandwith, drop rates, attachment redundancy,
>> maximum un-availability etc. characteristics in the context of various
>> specific use cases and/or connectivity constraints. These parameters can
>> vary widely depending on the specific deployment scenarios.
>>
>> It is also possible to have connectivity from the e.g. "thick" vCPE edge
>> instance located in customer customer premises that has heterogenous
>> connectivity - to use the "LTE" example below, you can have a box that
>> has a single wired (say ethernet) connectivity that is used normally,
>> and wireless LTE connectivity that is used when the main connection
>> fails, but has dissimilar bandwith, latency etc. characteristics.
>>
>> Also, top level separation should perhaps be at higher level constructs
>> at this early stage, e.g. "mobile" 4G/LTE...5G/eMBB/URULL/...,
>> "wireless" (802 stuff), "satellite", "wireline" (ptp fiber, xPON, Cable,
>> xDSL/g.fast, ...) rather than getting to technology specifics
>> (characteristics of connectivity vary a lot depending on the tech.).
>>
>> So far it seems to me that there is not yet sufficient focus on the
>> cases for "edge" locations that are within the network, such as cell
>> sites, V/CRAN aggregation sites, COs, metro locations etc. - esp. 5G
>> vRAN edge has already three tiers of sites on many plans (i.e. radio
>> sites, distributed aggregation sites w/ low-latency connections to radio
>> sites and central sites, which all should be in the scope of the "edge").
>>
>> Pasi 
>>
>>
>> On 01/05/2018 06:53 PM, lebre.adrien at free.fr wrote:
>>> Hi, 
>>>
>>> Following the LTE discussion, I'm wondering whether we should not try to classify the edge-site scenarios by level of the complexity (i.e., features/capabilities each scenario implies/requires).
>>>
>>> A possible classification can start with: 
>>> a) An edge infrastructure composed of several edge sites operated by a same organisation with WAN wired connections. 
>>> b) The same infrastructure but with LTE connections
>>> c) Scenario a) but where the edge infrastructure is spread over several edge sites belonging to different organisations/operators
>>> d) scenario c) but with LTE
>>> e) ..
>>>
>>> In parallel, we can try to identify w.r.t these scenarios what are the expected features/services from the administrator viewpoint and then from the developers viewpoint.
>>>
>>> I have the feeling that we all have relevant scenarios with specifics according to our targets. Having a classification can allow us to move forward by just focusing on classes instead of each particular scenario independently. 
>>>
>>> My two cents, 
>>> ad_ri3n_
>>>
>>> _______________________________________________
>>> Edge-computing mailing list
>>> Edge-computing at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing
>>
>> _______________________________________________
>> Edge-computing mailing list
>> Edge-computing at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing