Open Stack

Hi,



I agree with you when we classify edge-site scenarios.   Also we need to
understand applicability of edge computing use case (not NFV use case we
already know) at each type of edge-site.

According to the following 5G Automotive Association’s WP(p11),  “A typical
challenge in IoV is the big data processing and storage resulting from a
huge and growing number of sensors in smart/connected vehicles and roads.
This, in turn, requires new services platforms with powerful processing and
computing resources, low cost and trusted storage, and real-time
communication capabilities. MEC appears as a promising opportunity to
migrate Cloud resources closer to the vehicles and the data sources and
hence save network resources and reduce the latency. “

http://5gaa.org/news/toward-fully-connected-vehicles-edge-computing-for-advanced-automotive-communications/



How can OpenStack Edge Computing help Automotive industry?


-Hyde


2018-01-10 3:48 GMT+09:00 Pasi Vaananen <pvaanane at redhat.com>:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/edge-computing/attachments/20180110/11227841/attachment-0001.html>